Case Study: Support Agents for Meridian Telecom
Explore how to approach a real-world AI system design case study for Meridian Telecom's support agents. Learn to analyze assignment briefs, prioritize workflows, propose piloted automation under realistic constraints, and prepare clear presentations. Understand the importance of discovery, defining metrics, handling pilot tests, and revising plans based on feedback and changing requirements.
We'll cover the following...
- How do we read the brief?
- Which questions change the plan?
- Which workflow goes first?
- How do we define success with Meridian?
- What does the design look like?
- What did the replay show?
- How do we present it?
- How do we handle pushback and a changed requirement?
- What did this case stress?
- Try it yourself
- What’s next?
This case study focuses on the take-home assignment and presentation stages. Approach it as a real assessment: review the brief, make your own decisions before checking the example responses, and rehearse your presentation aloud at the end.
On Monday, you receive the following assignment brief:
Meridian Telecom receives 12,000 support contacts a month: 7,200 by phone and 4,800 by chat. A person handles every contact today, and the median handling time across both channels is eight minutes. Representatives look up the account in the account console, read the relevant policy in the knowledge base, handle or route the request, and record a disposition in the ticket system. Contacts fall into four categories: billing questions, service interruptions, plan changes, and account access. Meridian’s support leader wants an agent system that automates 70% of contacts and reduces handling time. Propose a first release and present it.
The 70% target is the first thing most candidates build around. It is also the first thing that falls apart under questioning.
How do we read the brief?
Before designing anything, we sort every line of the brief into three buckets.
Sort the lines yourself first, then check your answers against the table.
Here’s the sorted brief to check your answers against:
Bucket | Meridian’s Brief |
Facts | 12,000 contacts a month, the 7,200/4,800 channel split, the eight-minute median, the five-step workflow, three systems |
Asks | 70% automation, shorter handling time |
Gaps | Category volumes, outcome quality, what a service may read or change, identity verification, who would run the system |
A plan that treats an assumption as a verified fact is difficult to defend when questioned. The eight-minute median measures handling time across all contacts. It does not establish whether those contacts were resolved or how an AI agent would perform.
The target to "automate 70%" could refer to three different outcomes.
Deflected: The customer completes the interaction without reaching a human agent. This may reduce human-handled contacts, but it does not establish that the customer's issue was resolved.
Answered: The system provides a response. That response may be incomplete or incorrect, and the customer may still need further assistance.
Resolved: The customer's issue meets agreed resolution criteria, including any required follow-up period. Meridian has not yet defined those criteria.
Each metric requires a clearly defined denominator, eligibility criteria, and baseline. Until Meridian defines the target metric and agrees on eligible contact types, the 70% goal should guide discovery rather than serve as a launch acceptance criterion.
The brief also includes a review of 30 closed contacts. Eight contacts were marked as resolved. In three of those eight cases, the same customer contacted support again within seven days.
These follow-up contacts show that a resolved status alone is insufficient to confirm that the original issue remained resolved. The review does not ...