- Home
- Case studies
- Customer support case study
Case study
Customer support case study: ticket triage, reply drafts and call summaries for a broadband provider
ResultTriage, call summaries, reply drafts and quality-review support were integrated into the help desk, with agents sending every customer reply.
- Client
- A US regional broadband provider (anonymised)
- Industry
- Telecommunications (broadband)
- Service
- Contact center automation: the count, triage and summaries, drafted replies, QA scoring and knowledge gaps
- Type
- Triage, drafted replies, call summaries and QA scoring inside the provider's help desk
- Status
- Delivered
We built support automation inside a broadband provider's existing help desk. The system routes incoming tickets, prepares call summaries and drafts replies from approved material. It also supports quality review and identifies knowledge gaps. Agents retain control of every public reply and all account or financial actions.
The starting point
The support team handled calls, chats and emails in a help desk while call recordings lived in a separate platform. Team members sorted tickets and wrote call notes themselves, leaving less time for customers who needed personal support. Some macros needed updating, and quality reviewers could review only a limited sample of conversations.
What we delivered
We connected ticket history, account context, approved macros, knowledge articles and call transcripts. Incoming tickets are classified for intent and urgency and routed under the provider's rules. Summaries record the issue, actions and commitments as internal notes. Reply drafts appear for agent review, and structured QA checks flag conversations for reviewers.
Rollout and handover
Triage and internal summaries were introduced before reply drafting. We compared QA outputs with reviewer decisions and used agent edits to identify macros needing maintenance. The weekly knowledge-gap workflow produces draft articles for approval. Support operations received the runbook, alert routing and controls for stopping the automation.
Where people remain in control
| Work | What the automation does |
|---|---|
| A ticket arriving | Reads intent, urgency, language and account tier, then sets the queue, priority and tags |
| A call or chat ending | Writes the summary and disposition into the ticket as an internal note |
| The reply to the customer | Drafts it from an approved macro for an agent to edit and send, with no permission to post a public reply |
| Scoring the conversation | Scores it against the rubric, with reviewers scoring a weekly sample alongside |
| Outage credits, refunds and policy exceptions | Leaves these decisions to agents, within the approval limits they already have |
| Complaints, and customers who say they'll cancel | Flags them on arrival and sends them to a senior agent; a cancellation also alerts the retention lead in the team's chat |
| Legal, safety and vulnerability signals | Escalates at once to a named lead, with the conversation attached: a lawyer's letter, a cable down in the street, or a customer whose medical alarm runs over the line |
| A question no article answers | Groups it with others each week, with a draft article that stays unpublished until the team reviews it |
Project outcome
The project put supporting context and draft work in the help desk where agents already operate. Supervisors received a structured route to review quality flags and missing content. The automation has no permission to publish a customer reply or execute financial changes, so those decisions remain with the support team.
How performance is evaluated
| Measure | How it is measured | Comparison point |
|---|---|---|
| Time to assign | From the moment a ticket lands to the moment it reaches the agent who resolves it | The same measure before automation |
| Time to first response | From arrival until the customer gets the first reply, by queue and priority | The same measure before automation |
| After-call work | Minutes from the end of a call until the agent can take another | The same measure before automation |
| Draft edit rate | How much of each draft an agent changes before sending, by macro | From the first day of drafting |
| QA coverage | Conversations scored against the rubric in a month, as a share of all of them | The share included in the reviewers' pre-project sample |
| Reopen rate | Solved tickets reopened within seven days | The same measure before automation |
| Unanswered questions | Questions asked again and again that no article or macro covers | The same measure before automation |
Technologies and tools
- The help desk's API: internal notes, tags, priority, group, assignee and drafts
- Call recordings and transcripts from the contact centre platform, read only
- A language model for triage, summaries, drafts and QA scoring
- Transcription for calls, with recordings deleted on the provider's schedule
- The knowledge base, read, with draft articles left unpublished
- The CRM, read only: account tier, plan and open installs
- Alerts in the team's chat tool
- The provider's own cloud account and region
More case studies
All case studies- Case studyPreparing motor and property claim files for a regional insurerClaim information, policy details and supporting documents were assembled for adjusters, who retain authority over coverage, reserves and settlement.
- Case studyInvoice processing across two ERPs for a wholesale distributorOne shared queue gives the AP team the invoice, purchase order and warehouse receipt together, with clear reasons for anything that needs review.
Bring us the support workload taking time from customers
Tell us which help desk you use, your weekly ticket and call volume, and which supporting tasks take the most time. An engineer replies within two business days with which routine steps could run automatically and which conversations and decisions should stay with your team.