Maximum First Response Time: Reference Table by Reason and Criticality

This is the step almost no team takes: defining in advance how long each type of message can wait before the delay starts costing you. Without that definition, the inbox is handled in order of arrival and the urgent complaint ends up behind the question about opening hours. The table below assigns a maximum first-response time to each reason according to its criticality. It is not an average or a marketing goal: it is the ceiling the team sets for itself and then measures against.

Watch out for a distinction that always gets lost. The maximum first-response time is not the same as the resolution time. Here we are only defining when there has to be a human response that acknowledges the message and says what is going to happen. Resolving can take hours or days. Responding cannot.

How to read the table

Each row has a contact reason, a criticality level and a maximum first-response time. Criticality does not measure how hard the team works: it measures what happens if the response is delayed. A high-criticality message is not the hardest one to resolve, it is the one that ages the worst. A paid order that did not arrive does not become less serious over time; a question about opening hours does.

• Critical: if there is no response within the deadline, the business loses money, fails to comply with something or leaves someone without attention at a sensitive moment.
• Urgent: there is a purchase decision or an ongoing operational problem. The delay cools the conversation or makes the problem worse.
• Normal: the person expects a response, but can wait without consequences.
• Deferrable: there is no person waiting in real time or the matter is better resolved with information that is already written.

How to adapt the table to your operation

The table is a starting point. For it to be useful, it must be translated into the real hours of the business. A maximum time of 15 minutes means nothing if the team works from 9:00 to 18:00 and the message came in at 17:55. The rule is simple: the clock runs only within business hours, except for critical priority reasons, where it is advisable to define an on-call guard.

1. 1List the real contact reasons from the last 30 days. Not the ones you imagine: the ones that actually came in.
2. 2Assign each reason to one of the four priority levels. If you hesitate between two, choose the higher one and review it after a month.
3. 3Set the maximum time in minutes or hours, not in ranges. 'Between 1 and 4 hours' cannot be measured.
4. 4Define what 'first response' means in your operation: it must be a human message that acknowledges the case, not an automatic greeting.
5. 5Write the first step for each critical reason. If the team does not know who to escalate to, the deadline will not be met.
6. 6Load the times into the customer service tool so the inbox displays them. If measured manually, it will be abandoned in two weeks.
7. 7Review breaches once a week and adjust deadlines that cannot be sustained. An SLA that is always breached is not an SLA, it is an aspiration.

What to do when the deadline cannot be met

A maximum time is only useful if there is a consequence when it is exceeded. The consequence is not scolding anyone: it is a predefined action. These are the signs that you need to escalate and what to do in each case.

How long it takes to resolve each of these cases depends on each operation and cannot be promised in advance. What can be done is to have the action written before it happens, to avoid improvising while the customer waits.

The mistake of measuring with the wrong clock

There is a mistake that ruins any time table: measuring the first response counting from when the message was saved in the system instead of from when the person sent it. If the history was migrated all at once, almost all messages will appear to have been sent on the same day and at the same time, and any deadline analysis will give a false result. The valid timestamp is the one set by the messaging platform, not the one from insertion into the database.

Before publishing a compliance table, review where the data comes from. If the schedule distribution shows a strange peak in the mid-afternoon concentrated on a few days, you are looking at the upload date, not the send date.

Common mistakes when building this SLA

• Setting the same deadline for all reasons. If everything is urgent, nothing is urgent, and the team learns to ignore the alert.
• Defining the deadline in days when the reason is resolved in minutes. A '24 hours' for a billing complaint is an elegant way of not having an SLA.
• Counting the automatic greeting as the first response. The customer does not feel attended to until someone reads what they wrote.
• Not defining the schedule during which the clock runs. A deadline without a schedule is a decorative number.
• Measuring the average instead of the percentage within deadline. A low average can hide that 20% of critical cases went unanswered.
• Not reviewing the table. Contact reasons change with the season and with the business.

Examples by industry

The same table reads differently depending on the business. In food service, an order already paid for that did not arrive is critical and the clock runs in minutes, because the customer is waiting for the food now. In aesthetics, a complaint about a wrongly assigned appointment is critical, but a price inquiry can be normal. In a real estate agency, a property availability inquiry with a moving date looming is urgent; an inquiry from someone who is just starting to look is deferrable.

In healthcare, urgency within an ongoing service does not allow for a queue: the first response is an immediate referral to the person responsible. In academies, an enrollment inquiry with a close start date is urgent, and an inquiry about programs for the following year is normal. In stores and e-commerce, a billing problem and an order that did not arrive are critical; following up on a quote is normal.

The underlying rule does not change: the reason matters more than the industry. What changes is how long the delay takes to hurt. In a business with same-day deliveries, an hour of delay on a paid order is a lot; in a service booked weeks in advance, an hour weighs less. That is why the table is adapted and not copied.

How to know if the table is working

The table is useful if it changes decisions. Three signs that it is working: the team knows by heart which reasons are critical, expiration alerts are used to reassign rather than to scold, and deadlines are adjusted at least once per quarter with data from the last 30 days.

If the team cannot say which is the most urgent reason without looking at the table, the problem is not the table: it is that it was never communicated. An internal SLA is sustained by two things, an owner per critical reason and a short weekly review of non-compliances.

Tools like Wando show conversations in an inbox with AI suggestions and allow contacts to be tagged, which helps critical reasons to be identified faster. But the table and the deadlines are defined by the business: no tool can guess how long a collection claim can wait.