First Contact Resolution or Mean Time to Resolve?

Write Down What Each Measure Counts

For your report, define first contact resolution as the share of eligible incidents resolved during the initial interaction, without a callback or escalation. Write the calculation beside the chart: qualifying initial-contact resolutions divided by eligible incidents. Explain which channels and ticket types qualify so the denominator stays visible.

An email ticket needs an explicit rule for what counts as that initial interaction. Don't quietly count a sequence of follow-up messages as one contact because the ticket stayed with the same technician. Keep phone and email results separate while you check whether the underlying records support a useful comparison.

For mean time to resolve, add the elapsed durations of the resolved incidents in the report and divide by their count. State the start and end events. Say whether you use calendar time or business hours, and whether any status pauses the clock.

Use the full name on the report. An MTTR field may be configured around restoration, repair, or resolution, and a ticket's resolved timestamp may differ from its administrative closure. Have the PSA administrator demonstrate your actual calculation on a ticket before the service manager uses it to judge the desk.

Keep Labor Minutes Out of the Elapsed-Time Promise

The model assumes 30 minutes of labor for a ticket resolved at Tier 1. That is a capacity input. It doesn't say the user gets a working system within 30 elapsed minutes, and it doesn't set your contractual response or resolution promise.

HDI's contact-handle-time article makes the same distinction between work time and elapsed resolution time. A ticket that needs another contact can remain open longer than the labor spent handling it. Use that distinction when a report appears to show fast technical work alongside slow resolution.

The model also assumes 65% of tickets are resolved at Tier 1. That is a tier allocation, not a first-contact resolution target. A first-line technician could resolve a ticket after a callback; the work would still belong to Tier 1 while failing the initial-contact definition above.

Don't multiply 350 tickets by 65% and label the result successful first contacts. You haven't measured the contacts. Staffing from ticket volumes and labor minutes is sensible; replacing those inputs with an unrelated success percentage isn't.

Choose the Decision Before Choosing the Headline Number

Pick the measure that tests the problem you're trying to change this quarter. Keep the other one available as a check, because a narrower headline doesn't make the rest of the service disappear. Use actual ticket histories to decide which problem deserves the attention.

Erick Simpson describes questioning a proposed senior-technician hire when work intended for the first line kept escalating. In his account, he investigated how the work was assigned and what the first line needed to complete it. His recommendation addressed that reported constraint rather than assuming pressure in the senior queue specified the next hire.

That account gives you an investigation to try, not a diagnosis of your MSP. Read the failed contacts for the reason the next person became necessary. If the first line lacks approved access, provide the right access through your controls; if the issue requires specialist authority, route it there rather than holding it to protect a percentage.

Make the Waiting Visible

Elapsed resolution time needs the story between the timestamps. Have the dispatcher identify the next action on waiting work and who can perform it. Distinguish a ticket awaiting a vendor from one awaiting a technician so the service manager can act on the difference.

Averages are very good at hiding an awkward ticket in a crowd. Read the still-open work alongside the resolved-ticket average. Closing easy work can improve that average while the oldest unresolved jobs remain untouched.

Check what happens when a technician marks work resolved and the client hasn't confirmed it. Nick Clift recommends agreeing with each client who can confirm resolution and through which channel. He describes adjusting a hospital's closure-response window to allow for part-time staff, rather than treating silence as a universal answer.

Keep the distinction in your own workflow. Someone waiting for an affected user should know the agreed follow-up route. Someone waiting for internal work should have an internal owner, rather than a customer-waiting status used to stop a clock.

Give Each Check an Owner

Skip the service-optimization jargon. Name the waiting work and the person who can move it. I'd put these checks beside the report so a change in the number has an explanation the team can inspect.

• The PSA administrator owns the calculation: document eligible records, channel rules, clock behavior, and the timestamps used.
• The service desk lead owns the contact review: check unsuccessful initial contacts and record the reason another interaction was needed.
• The dispatcher owns waiting work: identify the next action, its owner, and the dependency keeping it open.
• The service manager owns the decision: choose the constraint to address and check both the result and any change in ticket mix.
• The account owner owns client agreement: confirm who can verify resolution and the agreed follow-up route.

Keep the measurement rules fixed while you examine the change. If you correct a rule, label the break in the series instead of presenting the new number as a service improvement. Check reopen records and actual user outcomes before deciding faster closure means better delivery.

Start with the tickets behind the complaint you want to solve. Choose first-contact resolution for avoidable repeat interactions or elapsed resolution time for delay, then write down the decision and its owner. Review whether that action changed the work, with the same counting rules still in place.