Start the SLA Clock When Customers Ask for a Person

A customer writes, “Please connect me with a person.” The AI asks another question, offers another article, and eventually hands the conversation to support. The inbox starts its human-response timer at handoff.

The dashboard measures the queue’s wait. The customer experiences the whole wait. Those are different intervals, and treating them as the same hides the delay we need to fix.

We should start the human-response SLA clock when the customer asks for a person. Escalation is an internal workflow event, not the beginning of the customer’s request.

Define the event that starts the clock

The trigger should be a recognizable request for human assistance: “Can someone help me?”, “I need an agent,” or a click on a contact-support control. A customer should not need to use an exact phrase to start the clock.

We also need to distinguish an actual request from a general question. “Do you offer live support?” asks about availability. “Please put me through to support” asks us to act. Give whoever maintains the routing rules examples of both.

When intent is ambiguous, clarification can help. When it is explicit, another attempt at automated resolution should not postpone the timestamp.

For each handoff episode, preserve the earliest clear request. If the customer repeats it, that repetition does not create a fresh waiting period.

Separate the customer clock from internal timestamps

A useful conversation record distinguishes the request for a person, the handoff into the human queue, and the first meaningful human reply. Each event answers a different operational question.

The request-to-reply interval measures the customer-facing commitment. Request-to-handoff exposes delay inside the automated workflow. Handoff-to-reply shows how quickly the human queue responds once it receives the work.

We need all of those views. If we measure only queue time, a slow handoff can make an overloaded experience look healthy. If we measure only total waiting time, we cannot tell whether to change the AI flow or adjust human coverage.

Treat the original request timestamp as durable conversation data. Routing to billing, changing priority, or assigning a different teammate must not reset it. A queue transfer is our administrative work, not a new request from the customer.

Keep helping without holding the handoff hostage

Starting the clock does not require the AI to go silent. It can acknowledge the request, explain availability, and offer relevant information while the customer waits.

The boundary is whether that assistance delays access to a person. Asking for an account email can help an agent find the right workspace. Requiring the customer to try another troubleshooting path before entering the queue makes automated compliance a condition of human help.

We should collect useful context in parallel with routing wherever the workflow allows it. If a detail is genuinely required to reach the correct team, make that requirement explicit and review whether it belongs in the handoff path.

The acknowledgment should describe the actual state. “Your request is in the support queue” means something different from “I’m collecting details before sending this to support.” Neither message counts as a human response.

Apply coverage hours without erasing the request

An after-hours request still happened when it happened. Preserve its actual timestamp, then calculate the SLA against the coverage schedule we have published.

If the commitment is based on business hours, count eligible time from that request using the relevant support calendar. Tell the customer when the team is available instead of implying that an agent is already reviewing the conversation.

Keep elapsed waiting time visible alongside SLA time. A conversation can be within a business-hours commitment while still feeling slow to someone who has waited through a closure.

Priority rules should also be explicit. An account-access incident may follow a different response target from a feature question. Changing the target should not rewrite when the customer first asked for help.

Stop the clock on a meaningful human response

An automated receipt is not a human response. Neither is an internal assignment, an agent opening the conversation, or a status change.

We should stop the clock when a person sends a reply that engages with the request. That could be an answer, a necessary diagnostic question, or a specific next step with clear ownership.

A generic “we’re looking into it” sent only to clear a deadline does not tell the customer what happens next. Review borderline replies with the team so the metric rewards useful engagement rather than placeholder messages.

Response and resolution remain separate commitments. A human can respond promptly while a fix still requires engineering work; the response should explain that dependency rather than imply completion.

Make the policy usable in the inbox

Agents need the original request time and the remaining response window where they triage work. If the inbox calculates deadlines only from queue arrival, preserve the request timestamp separately and use reporting that includes the earlier wait. Do not label queue-only timing as the full customer wait.

In Chattering.ai, handoffs carry the conversation context to humans in the shared inbox. That context helps the receiving teammate continue the conversation without asking the customer to repeat it. The SLA policy still needs to define which event starts the clock and what qualifies as a response.

We can audit the workflow by comparing the first request for a person, queue arrival, and the first substantive human reply. Review conversations where customers repeat their request or abandon the exchange before handoff.

The operating rule is simple: preserve the customer’s starting point. Then use internal timestamps to find and remove the delays between that request and useful human help.