Your AI support replies fast. Measure which conversations stay stuck.

A support reply can arrive in ten seconds and still leave the customer waiting for three days.

That is the awkward gap in many AI customer service projects. The team measures first response time, AI answers and conversations that appear resolved. Meanwhile, cases can be parked, reopened or left waiting for an internal decision without showing up in the polished headline metric.

On July 21, Intercom released two measures for this exact problem: the average length of a single snooze and the total time a conversation has spent snoozed. The measures belong to Intercom, but the question exists in every automated support inbox. How quickly does the reply leave the system, and how long does the customer's question remain unfinished?

Source: See how much time conversations spend snoozed.

Snooze is a waiting state, not an outcome

In a support inbox, snoozing temporarily removes a conversation from the active queue and brings it back later. That can be exactly right. The customer may need to provide an order number. A delivery is due on Friday. A specialist needs to investigate a fault. Trouble starts when the waiting state has no clear reason, owner or next review time.

Intercom recommends leading with the median when reviewing snooze time. A few conversations parked for several days can pull up the average and distort the normal workflow. The outliers should not be hidden, though. They are often the best examples to open and read after the median has established the baseline.

Several measures are easy to confuse:

• First response time shows how quickly the customer received an initial reaction.
• Handling time shows how long the team actively worked on the conversation and excludes snoozed time, among other states.
• Total snoozed time shows how long the conversation stayed parked across all snooze periods.
• A pending AI conversation can mean that the AI agent asked a follow-up question and is waiting for the customer, or that negative feedback did not trigger an escalation.

Intercom's metric catalogue therefore separates AI answers, confirmed or assumed resolutions, pending Fin AI Agent conversations, human handling time and snoozed time. An AI reply, a helped customer and a properly finished case are not the same event.

Source: Reporting metrics & attributes.

Fast replies can hide three different queues

For a compact support team, one inbox often contains several queues.

The first is visible: open questions waiting for a response. The second is human: notes, follow-ups and checks that must happen after a conversation. The third is hidden: conversations that were snoozed, left in a pending AI state or assigned to someone who is offline when the case wakes up.

On July 17, Intercom extended protected wrap-up time to chat and email. When a teammate closes or hands off a conversation, the freed slot can be held for a configured period. That gives the person time to finish notes and follow-up work before receiving another case. High occupancy does not automatically produce healthy throughput. If every free second is filled with a new conversation, documentation, and follow-up move elsewhere, often after hours or not at all.

Source: Give teammates time to wrap up on chat and email.

Capacity also needs to reflect the channel. An email about a proposal can remain open while someone gathers information. Three simultaneous live chats demand immediate attention. Intercom's new separate assignment limits for email and Messenger make that distinction measurable instead of treating every conversation as equally heavy.

Source: Balance teammate workloads across email and Messenger.

Run a 45-minute stuck-support review

You do not need another tool to begin. Use a report from your support platform, a spreadsheet and the AI assistant your team has already approved. Find where waiting accumulates and choose one change to test next week.

1. Choose a completed working week

Pick a week that resembles normal operations. Do not mix an ordinary week with a campaign launch, start of term or service outage unless that event is what you want to study. Begin with one channel that has at least a few dozen conversations. Email or web chat is usually enough for a compact team.

Write down three things before opening the report:

• What response time do you promise the customer?
• When may a conversation be snoozed?
• Who owns the review when it wakes up?

If colleagues give different answers, the review has already found something useful.

2. Export only the fields you need

Include conversation ID, channel, responsible role or team, start time, first response time, status, number of snoozes, total snoozed time, next wake-up time, number of reopenings and whether AI was involved. Include the waiting reason or expected next actor if your platform provides it.

You rarely need the customer's name or full message for the first analysis. Use pseudonymous IDs or redacted excerpts when content must be reviewed. A recurring integration can fetch the report through a scoped, read-only API key. Store the credential in a secret manager or environment variable, log each run and require approval before changing queue behavior.

3. Calculate the median, then open the outliers

Start with the median total snoozed time. Compare it by channel and waiting type. Then look at the upper quartile and open the ten longest parked conversations.

Do not begin with "who is slow?" Ask what the conversation was waiting for. A case waiting for the customer's measurements is not the same problem as one waiting for an internal pricing decision. They need different rules.

4. Sort waiting into five practical reasons

Use five categories:

1. The customer needs to provide information.
2. The team is waiting for an internal person or decision.
3. An external event has a fixed date, such as a delivery or booking.
4. The case should have been escalated or handed over.
5. The reason is unclear and the case appears merely parked.

Add a sixth category if your organization has one recurring special case. More than that makes the first review cumbersome.

5. Run this analysis prompt

Copy the prompt and paste the table or attach the redacted export.

You are reviewing an export from our support inbox. The goal is to find waiting that the customer experiences but first response time does not reveal.

Use only the attached data. Do not guess missing values.

Do the following:
1. Check which columns are present and flag what is missing.
2. Calculate median total snoozed time for the full period and by channel. Also show the upper quartile.
3. List the ten conversations with the longest total snoozed time. Show ID, channel, owner/team, snooze count, total snoozed time, reopenings and current status.
4. Classify each listed conversation as:
   - waiting for customer
   - waiting internally
   - waiting until a fixed date
   - should be escalated or handed over
   - unclear parking
5. If the data does not support a classification, write UNCLEAR instead of assuming.
6. Compare conversations involving AI with the rest. Do not claim that AI caused a difference; describe only what the data shows.
7. Propose no more than three process changes. For each one, state the responsible role, trigger, next review time and metric to follow next week.
8. End with a short review list of the conversations a person should open first.

Do not show customer names or message text in the summary.

The prompt is deliberately careful about cause and effect. If AI conversations have longer waiting times, the reason could be that the AI receives the easiest questions, the hardest questions or a different mix of channels. The first run should find reviewable patterns, not declare a winner.

6. Change one rule and name its owner

Choose one change that can be tested next week. You might require every snooze to have a reason and wake-up time, return cases that wake up under an offline owner to the team queue, or give live chat a lower concurrency limit than email.

Write the rule as an executable work instruction:

• When this happens, this role takes the following action.
• The action is due by this time.
• On Friday, check this metric.

Avoid changing five things at once. You will not know which one affected the result.

Measure whether the customer moved forward

Run the same comparison next week. Start with median snoozed time, the share of conversations with an unclear waiting reason and the number of reopened conversations. Add a qualitative sample: read five fast and five slow cases. A fast case may have been closed incorrectly. A slow case may be well managed if the customer clearly knows what will happen and when the next update is due.

For AI support, also track pending AI conversations and how often negative feedback reaches a person. A high number of AI answers is interesting, but it does not show whether the right customer questions were resolved.

After the same review has worked for two or three weeks, turn it into a recurring workflow. Let a read-only integration collect the report, redact sensitive fields and produce a weekly summary. Keep approval gates for routing changes, closure, and customer contact. In Tool Forge, the work would focus on that support flow: showing where cases stop before adding more automation.