Reports - Service Time Metrics

When to Use

• You need to monitor ticket waiting time in queue (TME)

• You want to track response time when the ticket is assigned to an agent (TMA)

• You want to know the total time from creation to resolution of the ticket (TMR)

• You want to differentiate "clock time" from "within business hours" time

• You want to compare service time metrics across your teams and agents

Prerequisites

• Be logged in as supervisor, CX Engineer, or administrator

Overview

Every conversation in Cloud Chat goes through three moments in order:

1. Waiting — in the queue, without an responsible.

2. Attending — assigned to an agent (human or AI).

3. Resolved — finished.

For each resolved conversation, the system calculates three metrics:

Elapsed Time vs. Business Hours Time

Each of the three metrics has two versions:

• Elapsed Time — clock, 24/7.

• Business Hours Time — only counts time spent inside the conversation’s designated operating hours. The operating hours are configured in this section of Cloud Chat

Practical Example

A conversation started Friday at 5 pm and resolved Monday at 10 am, with an inbox that operates Mon–Fri from 9 am to 6 pm:

• Elapsed time: ~65 hours (including the full weekend)

• Business hours time: ~1 hour (1h on Friday before closing + 1h on Monday after opening)

When to use each

• Elapsed Time → shows the customer’s real experience. They waited through the entire weekend.

• Business Hours Time → indicates operational performance. The team only had 1 hour of effective response time.

Use business hours time for targets and SLAs. Use elapsed time to understand the customer perception.

TME — Waiting Time

What it is

Total time the conversation was in the queue without an responsible.

When the clock starts

• When the conversation is created (enters the queue), OR

• When the conversation loses responsible after being assigned to an agent (unassigned).

When it stops

As soon as someone (human or AI) is assigned.

Conversation with multiple waiting periods

If the conversation went through multiple cycles (created → agent A picked → agent A unassigned → back in queue → agent B picked), all waiting periods are summed.

Why is my conversation’s waiting time = 0?

Indicates that no one waited — the conversation was assigned immediately at creation. In cases where the conversation was resolved solely by AI, for example, there’s no waiting time because AI does not keep the conversation in the queue.

TMA — Response Time

What it is

Total time the conversation was under an agent’s responsibility (human or AI).

When the clock starts

When the conversation switches from "without responsible" to "with responsible".

When it stops

• When the agent resolves the conversation, OR

• When the conversation loses responsible (returns to the queue).

Conversation handled by more than one agent

If the conversation moved from agent A to agent B, both periods are summed into the response time.

Which agent is considered in report filters?

The final agent — the responsible agent at the moment of resolution. Previous agents do not appear there. This means that if a conversation passed through multiple agents, the response time is assigned to the final one.

The agent type column indicates whether this final agent was AI or Human.

TMR — Resolution Time

What it is

Total time between creation of the conversation and final resolution.

→ TMR = resolution moment − creation moment

Relationship with TME and TMA

In simple conversations:

→ Resolution time ≈ Waiting time + Response time

What if the conversation was reopened?

The system considers the last resolution. If the conversation was:

• Created at 10 am

• Resolved at 11 am (1h)

• Reopened at 2 pm

• Resolved again at 4 pm

The resolution time will be 6 hours (10 am → 4 pm), not just 1 hour.

Numeric Example for Illustration

To clarify everything, let’s review an end-to-end conversation.

Scenario

• Inbox: operates from Monday to Friday, 9 am to 6 pm (closed on weekends)

Timeline of the conversation

What happens to each metric

Viewing through the Inbox clock (which operates 9 am to 6 pm, Mon–Fri):

Thursday:

• 5 pm → 5:15 pm → waiting in queue (within business hours)

• 5:15 pm → 6 pm → in attending with Ana (within business hours)

• 6 pm → 12 am → continues assigned to Ana, but outside business hours

Friday:

• 12 am → 9 am → still assigned to Ana, outside business hours

• 9 am → 2:30 pm → attending with Ana (within business hours)

• 2:30 pm → Ana resolves

Calculation of the three times

TME — Waiting Time

• Single waiting period: 5 pm → 5:15 pm Thursday (15 minutes)

• Whole within business hours.

TMA — Response Time

• Single attending period: 5:15 pm Thursday → 2:30 pm Friday

• Thursday 5:15 pm → midnight = 6h45

• Friday 12 am → 2:30 pm = 14h30

• Total: 21h15 ≈ 1,275 minutes

Business hours:

• Thursday 5:15 pm → 6 pm = 45 min

• Friday 9 am → 2:30 pm = 5h30

• Period from 6 pm Thursday to 9 am Friday is discarded (outside business hours)

• Total: 6h15 ≈ 375 minutes

TMR — Resolution Time

• Creation at 5 pm Thursday → resolution at 2:30 pm Friday.

Elapsed:

• Thursday 5 pm → midnight = 7h

• Friday 12 am → 2:30 pm = 14h30

• Total: 21h30 ≈ 1,290 minutes

Business hours:

• Thursday 5 pm → 6 pm = 1h

• Friday 9 am → 2:30 pm = 5h30

• Total: 6h30 ≈ 390 minutes

Does the sum check out?

→ TME + TMA = TMR

• Elapsed: 15 + 1,275 = 1,290 ✓

• Business hours: 15 + 375 = 390 ✓

In this example, the sum matches because the conversation had only one waiting and one attending period. In cases with transfers or returns to the queue, small gaps between events may cause the total TMR to differ slightly from TME + TMA.

What does this example teach you?

1. Outside business hours "disappear" in business hours metrics but not in elapsed time. Thus, business hours numbers are usually smaller.

2. "Delaying" and "mark as pending" do not improve response time — the clock keeps running. To stop the clock, the conversation must change responsible (return to the queue or transfer).

3. The agent recorded in the conversation is the final responsible agent — in this case, Ana, who handled and resolved it. If Ana had transferred it back, and Bruno finished it, the line would show Bruno as responsible, even though Ana worked on it.

Frequently Asked Questions

Why do some conversations have empty time fields or are not considered in calculations?

Because the conversation has not yet been resolved. Times are only calculated at a final closing.

Why is the business hours time less than elapsed time?

Because business hours exclude:

• Early mornings

• Weekends (if the Inbox doesn’t operate then)

• Public holidays set as closed

• Any moments outside the operating window

If the entire conversation occurred within business hours, both values are equal.

Can I have business hours time = 0 and elapsed time > 0?

Yes. It means the conversation was completely handled outside business hours — for example, by AI overnight. The elapsed time exists, but no minutes fall within the useful window of the Inbox.

Which agents or teams are considered in filters?

In all filters — Agent, Team, Inbox — the system considers only the current state of the conversation after resolution. If a conversation involved multiple agents or teams, only the last appears in the filters. This applies to TME, TMA, and TMR.

What timezone does the system use?

The timezone of the Inbox that received the conversation — not the customer’s or agent’s timezone.

Do AI-resolved conversations appear in the same reports?

Yes. Metrics work the same for AI or human agents. The agent type column identifies the final responsible agent, allowing for segmentation.

Why did the time of a conversation change from one day to another?

Likely because the conversation was reopened and resolved again. The system always considers the last resolution — if a conversation closed today, reopened tomorrow, and closed again after tomorrow, the resolution time reflects this longer interval.

Why are past metrics changing?

Because only resolved conversations are considered. If a conversation was created earlier, lasted several days, and was only resolved today, its time is calculated based on the most recent resolution date — retroactively updating previous metrics.

Older tickets tend to have fewer reopenings, but data can still change as history updates.

In short: report data is not static — it can change as conversations are reopened or closed.

Is the time spent in "Delayed" or "Pending" status counted in response time?

Yes. These statuses do not remove the responsible agent — the agent remains assigned, so TMA continues to accumulate.

Notes

• For real-time overview (not historical): How to manage operations in real-time with the Dashboard report and Advanced Monitoring

• To configure SLA policies based on these times: How to set up SLA and response time metrics

• For batch data extraction via API: How to extract data in bulk via API (Data Extract API)