The Take-Home Brief
Analyze Meridian Telecom’s customer brief by separating supplied facts, customer requests, and unresolved questions. Map the current human workflow across phone, chat, account records, policy guidance, and ticket dispositions. Clarify what 70% automation means, which contacts are eligible, and how resolution differs from deflection, responses, and handling time. Interpret the small contact review without inferring repeat-contact causes or production rates. Draft an engagement brief with proposed outputs, exclusions, integration and permission questions, and unconfirmed owners. Recommend discovery before selecting a first release, promising an automation percentage, or setting launch criteria. Keep proposed commitments clearly labeled.
We'll cover the following...
The take-home case in an FDE loop usually arrives as a short customer brief: a company, a workflow, a request, and a handful of numbers. Your first job isn’t to design anything. It’s to read the brief the way the customer’s own engineers would, separating what the customer knows from what they hope for. This chapter works one case from start to finish: the brief, the first release, the design, and the presentation. It starts with a telecom company that wants agents to take over much of its customer support.
How does Meridian’s support work today?
Meridian Telecom receives 12,000 support contacts a month: 7,200 by phone and 4,800 by chat. Every contact is handled by a person today, and no agent system exists yet. A contact moves through five steps:
A customer reaches Meridian by phone or chat.
A support representative looks up the account in the account console.
The representative reads the relevant policy in the knowledge base.
The representative handles the request or routes it to a specialist.
The representative records a disposition in the ticket system.
The diagram shows the same flow across Meridian’s three systems.
Those three systems, the account console, the policy knowledge base, and the ticket system, tell you where representatives work. They don’t tell you what an automated system would be allowed to read or change, and that is one of the first things you’ll need to ask.
Meridian’s operations report gives an eight-minute median handling time across both channels for the month. A median tells you how long a typical contact takes. It says nothing about whether the customer’s problem was solved.
Contacts fall into four categories: billing questions, service interruptions, plan changes, and account access. The brief doesn’t give their proportions, how often customers contact Meridian again, or how good the outcomes are. A category name alone can’t tell you how much work it represents or whether customers want it automated.
How should you read the brief?
Before you write anything, sort each line of the brief into one of three buckets:
Facts: Numbers and processes the customer supplied, such as the 12,000 contacts, the channel split, the eight-minute ...