Understanding the Concept of Contact in Service Reporting

Updated 

3 days ago

Contact ID helps us understand and improve how your support request is handled. Each Contact ID represents a single unit of work performed during the life of your case, giving us a consistent way to track activity as requests move across queues and agents. While it appears in queue‑based reports, Contact ID connects insights across queues, agents, and cases, enabling accurate workload measurement, demand forecasting, capacity and staffing planning, and visibility into agent productivity. These insights help ensure support resources are aligned with customer needs and that your requests are handled efficiently and consistently. The following reports help us see the complete picture of how customer requests move through our support teams across different channels:

Use Cases of Queue Reports

  • Accurate workload measurement: Understand exactly how much work is being generated as customer requests move through support queues, helping ensure every interaction is counted and nothing is overlooked.

  • Workload forecasting: Identify patterns in incoming requests over time so future demand can be predicted more accurately and support teams are better prepared.

  • Workforce and capacity management at the queue level: Ensure the right number of agents are available in each queue to reduce wait times and improve response speed.

  • Agent productivity and performance analysis: Measure how effectively agents are supporting customers, such as the number of requests each agent handles, to support coaching, planning, and service improvement.

What Is a Contact?

A Contact is created every time a case or interaction enters a support work queue. Each entry into a queue is treated as a new and independent contact, even if it’s the same case entering the same queue again at a later stage.

Put simply, each queue entry equals one contact. Every contact is assigned a unique Contact ID, which represents a single, clearly defined unit of queue‑level work within the overall case journey. If a case enters the same queue multiple times, each occurrence is counted separately and tracked with its own Contact ID.

All performance metrics and KPIs are measured at the contact level, rather than the case level. This ensures accurate visibility into queue workload and handling activity:

  • Each Contact ID reflects one specific queue workload instance

  • Metrics remain consistent across reporting, but are calculated per contact

  • Every contact follows a clear lifecycle:

    • Start: When a case, interaction, or conversation enters a queue.

    • End: When it exits the queue.

When Is a New Contact Created?

A new contact is created whenever a case enters a work queue, including the following situations:

  • Initial routing of a case into a queue

  • Transfer from one queue to another

  • Warm transfer to another queue or agent

  • Manual assignment directly to an agent

  • Reassignment to the same queue due to routing logic

  • Any case that exits and later re-enters the same queue

This approach ensures that every unit of queue work is tracked independently, allowing for accurate workload measurement, performance reporting, and service optimization.

Examples for Voice and Digital Queue Flows

Enlisted are few examples to explain the complete journey.

​

The flow of this scenario is explained below:

When you contact the support team, you get one case that tracks your issue from start to finish. Within that case, every time your case moves into the queue is a new contact ID for us to calculate or to measure the performance.

Think of it like this:

Your case would be your issue.

A new Contact ID is generated every time a contact enters the queue. This occurs, for example, during transfers or manual assignments, etc.

Contact ID 1 – First Time Through the Queue.The range spans from A to H.

A — Work Queue 1 Entry

  • The interaction first enters the digital system

  • It is put into Work Queue 1

No agent owns it yet. The system is deciding who should handle it. Queue Time starts here.

Transition: A → B

The interaction is picked up from the queue (by routing logic).

B — Bot Engagement / Routing

A bot or automated logic interacts with or evaluates the request.

  • System attempts self‑service or categorization.

  • Interaction is still not owned by a human agent.

Transition: B → C

  • Bot could not resolve the issue.

  • The interaction must go to a human agent.

C — Agent 1 Assigned

Agent 1 is assigned to the interaction

  • Ownership begins.

  • The agent is now responsible.

Agent Response Time starts. Handle Time will start once the agent acts.

Transition: C → D

Agent 1 prepares to respond.

D — Agent 1 First Response

Agent 1 sends the first reply to the customer.

  • First Response SLA is met.

Transition: D → E

Conversation continues

E, F, G — Ongoing Agent–Customer Conversation

These represent message exchanges.

C1, C2, C3 = Customer replies

  • Active handling.

  • Handle Time continues to accumulate.

Transition: G → H

  • Agent has replied.

  • Now waiting on the customer.

H — Awaiting Customer Response

  • The agent has responded.

  • The customer is expected to reply.

  • Agent is waiting. Case is still owned by Agent 1.

  • Customer Follow‑up Response Time starts.

Transition: H → I

Customer does NOT reply within allowed time.

I — Agent 1 Unassignment

  • Agent 1 is unassigned

  • Interaction is not closed

  • The system frees the agent

  • The interaction must be re‑queued

Contact ID 1 ends here

Contact ID 2 – Second Queue Attempt (This section covers J → L).

Same customer issue enters Work Queue 2 (This is a continuation, not a new problem)

  • Queue Time starts again

Transition: J → K

Routing assigns a new agent

K — Agent 2 Assignment

  • Agent 2 is assigned.

  • Ownership shifts to Agent 2.

  • Agent Response Time starts again.

Transition: K → L

  • Customer does not engage / no activity.

L — Agent 2 Unassignment (No Response)

  • No successful engagement.

  • Agent 2 is unassigned.

Contact ID 2 ends.

Contact ID 3 – Third Attempt

This section covers M → N.

M — Work Queue 3 Entry

  • Issue enters Work Queue 3.

  • Another retry to find the right agent.

Transition: M → N

Agent assigned

N — Agent 3 Assignment

Agent 3 gets the interaction

Transition: N → O

Agent 3 does not resolve and releases ownership.

Contact ID 3 ends.

Contact ID 4 – Final Handling (This section covers O → P).

O — Agent 4 Assignment

  • Interaction is assigned to Agent 4

Transition: O → P

  • Agent 4 responds

P — Agent 4 First Response

  • First response from Agent 4.

  • Customer engages successfully.

  • Issue is resolved.

  • Interaction closes.

Journey ends.

The letters (A–P) mark every state change of a single customer interaction as it repeatedly enters queues, gets assigned to agents, waits for responses, gets unassigned, and is retried, until one agent successfully completes it.

The flow of this scenario is explained below:

When you call the support team, a single case is created to track your issue from beginning to end. Even if your call is transferred, placed on hold, or handled by multiple agents, everything remains connected to that same case.

Within this case, your call experience is organized into conversations and contacts, each representing a clear stage of your interaction with us. Within one Conversation ID there can be multiple Contact IDs. Summarising it below:

  • The Case Number represents your entire journey with the support team for that call. It covers everything from the moment you call until your issue is resolved and the call ends.

  • Conversation IDs represent each separate call connection that happens during your journey. For example, if your call is transferred or routed again, a new conversation is created—but it still belongs to the same case.

  • Contact IDs are created every time your call enters a support queue. This helps us understand how long you waited and how your call was handled at each stage.

High Level Structure

  • Conversation ID 1

    • Contact ID 1 (initial call handling)

  • Conversation ID 2

    • Contact ID 2

    • Contact ID 3

    • Contact ID 4

A single customer call can generate multiple Contact IDs as it is transferred, re‑queued, or re‑assigned.

Conversation ID 1 begins

Contact ID 1 – Initial Inbound Call (A → H)

A — IVR Entry

  • Customer dials in.

  • Call enters the IVR.

No queue yet, no agent yet, call is being classified (language, intent, skill).

A → B

  • IVR completes routing.

  • Call is sent to a queue.

B — Work Queue 1 Entry

  • Call enters Work Queue 1.

  • Queue Time starts.

B → C

  • Routing logic selects an agent.

C — Agent 1 Assignment

  • Call is assigned to Agent 1.

  • Agent Ring Time starts.

  • Agent Handle Time will start once accepted.

C → D

  • Agent accepts the call

D — Agent 1 Accepted

  • Agent 1 answers the call

  • Live conversation begins.

D → E

  • Agent places the caller on hold.

E — Agent 1 Hold Start

  • Caller is on hold.

  • Hold Time starts

E → F

  • Hold ends / call returns to agent

F — Agent 1 Hold Stop

  • Agent resumes conversation.

F → G

  • Call is ending or agent is wrapping up.

G — Agent 1 Wrap

  • After-call work.

  • Notes, disposition, wrap codes.

G → H

  • Call ends or agent disconnects

H — Call End / Agent Disconnect

  • Contact ID 1 ends.

  • Call may still continue through transfer.

Conversation ID 2 begins

Contact ID 2 – Blind Transfer to New Queue (I → L)

I — IVR Re‑Entry (Post‑Transfer)

  • Call re-enters IVR due to blind transfer.

I → J

  • IVR routes call again.

J — Work Queue 2 Entry

  • Call enters Work Queue 2.

  • New Queue Time starts

J → K

  • Agent 2 selected.

K — Agent 2 Assignment

  • Call is assigned to Agent 2.

K → L

  • Blind transfer / agent release.

L — Agent 2 Blind Transfer / Unassignment

  • Agent 2 does not handle the call.

  • Call continues forward.

Contact ID 2 ends

Contact ID 3 – Third Handling Attempt (M → P)

M — Work Queue 3 Entry

  • Call enters Work Queue 3.

M → N

  • Agent 3 selected.

N — Agent 3 Assignment

  • Call assigned to Agent 3.

N → O

  • Agent 3 accepts.

O — Agent 3 Accepted

  • Live conversation with Agent 3.

O → P

  • Direct transfer or unassignment.

P — Agent 3 Direct Transfer / Unassignment

  • Call transferred again.

  • Agent 3 releases ownership.

Contact ID 4 – Final Agent & Call End (Q → R)

Q — Agent 4 Accepted

  • Call assigned and accepted by Agent 4.

Q → R

  • Call completes normally.

R — Call End / Agent 4 Disconnect

  • Customer disconnects or agent ends call.

  • Final wrap is completed.

Journey ends.

This diagram shows a single inbound voice call moving through IVR, multiple queues, multiple agents, holds, wraps, blind transfers, and re‑queues, with each letter (A–R) marking a precise state change in the call lifecycle until final disconnect.

​

The flow of this scenario is explained below:

When you call the support team, your call is tracked as part of a single conversation so we can support you smoothly from start to finish, even if your call is briefly transferred or rerouted. The definition is explained below:

  • Case Number: Covers your entire journey from start to finish and remains the same throughout the call, even if a transfer is attempted.

  • Conversation ID: Represents the single, continuous call and does not change in this scenario because the warm transfer was cancelled.

  • Contact IDs: Contact ID 1 tracks your main interaction with Agent 1, while Contact ID 2 is briefly created when the warm transfer to another queue starts, solely to capture queue‑level timing and workload.

This diagram shows what happens when an agent starts a warm transfer (bringing another team in to help you) but then cancels that transfer and continues helping you themselves.

High‑Level Structure

Conversation ID 1

  • Contact ID 1 → original inbound call.

  • Contact ID 2 → temporary contact created during warm transfer.

Only one conversation exists, but the warm transfer creates a second contact that is later cancelled.

Conversation ID 1 begins

A — IVR Entry

  • Customer dials the number.

  • Call enters IVR.

Call intent is identified. Language, menu choices, or routing logic applied.

A → B

  • IVR completes routing.

  • Call is passed to a work queue.

B — Work Queue 1 Entry

  • Call enters Work Queue 1.

  • WQ1 Queue Time starts.

  • Queue‑level metrics begin.

B → C

  • Routing logic selects an agent.

C — Agent 1 Assignment / Ringing

  • Call is assigned to Agent 1.

  • Phone rings for the agent.

  • Agent Ring Time starts.

C → D

  • Agent answers the call.

D — Agent 1 Accepted

  • Live conversation begins.

  • Agent Handle Time starts.

Contact ID 2

Warm Transfer Attempt (Contact ID 2 Created)

At this point, Agent 1 decides to warm‑transfer the call.

D → E

  • Agent initiates warm transfer.

  • Secondary queue is involved.

E — Work Queue 2 Entry (Contact ID 2)

  • A new contact (Contact ID 2) is created.

  • Call is placed into Work Queue 2.

  • Customer may be on hold.

  • Original agent still maintains control.

  • Agent 1 is still connected.

Warm Transfer Cancelled

E → F

  • Agent 1 cancels the warm transfer.

F — Agent 1 Cancels Transfer & Continues Call

  • Transfer does NOT complete.

  • Work Queue 2 contact is abandoned.

  • Agent 1 fully resumes the call.

Contact ID 2 ends here

Call End and Wrap‑Up (Back to Contact ID 1)

F → G

  • Call concludes from customer side

G — Customer Disconnects

  • Customer hangs up.

  • Active talk time ends.

G → End

  • Agent performs after‑call work.

Agent 1 After‑Call Work (Final State)

  • Agent fills ACW (After Call Work).

  • Agent is unassigned from the case.

  • Contact ID 1 is closed.

This journey shows an inbound voice call where Agent 1 initiates a warm transfer, cancels it before completion, resumes the call, and completes after‑call work following customer disconnect, with each letter (A–G) marking a specific state change.

Was this article helpful?

Related Articles

Loading...