Start here · How to use this

The agent that handles support

Fill the six fields a one-paragraph support-agent brief leaves blank, decide which gap fails first, and count what it costs in week one.

critiquemediumExercise · 4 min · 4 of 75

On this page

A brief that names a task and a tool but none of the six fields describes an outcome nobody can check. This one is about to be signed, and it comes with publish rights on 40 client websites.

The situation

The agency also hosts and maintains the websites of its 40 clients. Their support email arrives in one shared inbox: about 600 messages a month, 30 a working day. Roughly 45% ask for a content change ("swap the photo on the team page"), 30% are how-to questions, 15% are about billing, and 10% report a site that is down or broken. A developer works the inbox today at about 8 minutes a message: 80 hours a month, $2,400 at an assumed $30 an hour.

The founder's brief, in full: "Build an agent that handles support. It reads the support inbox, answers clients, makes small changes on their sites through the CMS, and keeps everyone happy. Give it whatever access it needs." The proposed tools are the inbox (read and send), publish rights in the CMS for all 40 sites, and the billing system. Assume the agent gets 1 content change in 25 wrong, and that a client is worth $2,500 a month in fees. The lesson this practises is the virtual employee frame.

The question

Fill in the six fields this brief leaves blank, then decide which gap fails first and what it costs in the first week.

A strong answer · Rubric · Where answers go wrong

Write your answer first, then open

A strong answer

The brief fills one field, loosely: inputs. "Keeps everyone happy" cannot be checked for one message, and "whatever access it needs" is the absence of an output limit.

Inputs: the support inbox, about 30 messages a working day.
Outputs: replies to how-to and billing questions; content changes saved as CMS drafts, never published; billing read only.
Done: within 2 working hours, each message has a reply sent or sits in a named person's queue with a reason.
Manager: the developer who works the inbox today, approving every publish and reading one reply in ten.
Escalation: a site-down report goes to the on-call developer within 15 minutes and is never answered by the agent; a billing dispute reaches the operations manager the same day.
Budget: a 10-turn cap per message, a monthly spend cap with an alarm on the daily rate, and the developer's minutes counted against today's 80 hours.

Escalation fails first. Site-down reports are 10% of 30, three a day, so the first arrives on the first morning. The agent has nothing that can restart a server and no path to a person, so it replies "we are looking into it" and the outage waits behind a reply that sounds handled. Week one: 15 outages with nobody paged, each a $2,500-a-month client at risk.

The manager gap comes second. Content changes are 13.5 a day, 67.5 a week; at 1 in 25, about 2.7 wrong edits a week go live on client sites, the first likely by day two.

Fix the escalation path and remove publish rights before building anything. If outages reached the developer through uptime monitoring instead of the inbox, the manager gap would fail first.

Rubric

fills all six fields with something checkable: a volume on inputs, a limit on outputs, done as a per-message state with a time
replaces "whatever access it needs" with drafts instead of publishing and read-only billing
picks the first failure by arrival rate, with the arithmetic: 10% of 30 is three site-down reports a day, so day one
sends site-down reports to a named person with a clock, outside the agent
estimates the week-one wrong edits from the stated 1 in 25, about 2.7 of 67.5, and ties them to the missing manager
names the condition under which the order of failures would change

Where answers go wrong

"The budget fails first, because agents run up bills." The gap is real, but it fails slowly: at 30 messages a day the overspend shows on the month's invoice, and the first site-down email arrives on the first morning. A reviewer scores the order in which failures arrive, and that comes from arrival rates, not from which failure is most talked about.

"Put a person on every reply before it sends." That fills the manager field and leaves escalation blank: the outage report still waits, now as a draft in a queue with no clock. It also spends 30 approvals at 3 minutes, 90 minutes of the developer's day, before a single outage is routed.

"Done is customer satisfaction above 90%." A monthly survey score cannot be checked for one message, and it arrives weeks after the wrong edit went live.