The discovery week

Every engagement starts with a week where we build nothing. Clients sometimes push back on this — they have a clear idea of what they want and would rather we started on it. We hold the line, because the failure mode we are avoiding is expensive and quiet: a working agent that automates a workflow nobody actually runs.

What people describe when you ask them how the business works is the tidy version. The real one has exceptions in it. The discovery week is how we find the exceptions before they find us.

Day one and two: watch the real day

We shadow. On a call, on site, or over a shared screen — whatever gets us close to the actual work. The point is to see the day as it happens, not as it is summarised afterwards.

What we are looking for is where the work leaves the system. Someone answers the phone and writes on a pad. A quote gets amended in a text message and never makes it back into the CRM. Two people have a rule about which jobs go to which van, and that rule lives in one of their heads.

We also count. Roughly how many calls, how many quotes, how many follow-ups, how long each takes, when they cluster. Not a time-and-motion study — enough to know whether we are talking about a task that happens six times a day or twice a month, because that decides whether it is worth automating at all.

The most useful question of the week is boring: and then what happens? Asked five times in a row, it surfaces every hop the tidy version left out.

Day three: the step list

Then we write it down. One document, one workflow per page, and each step gets four things:

• Trigger. What starts this, precisely. “A customer calls” is not a trigger. “An inbound call outside 8am–5pm” is.
• Inputs. What has to be known before the step can happen, and where that lives today.
• Decision. What actually gets decided, and by whom. Most steps that look like data entry have a judgement buried in them.
• Output. What changes in the world — a calendar entry, a message sent, a field updated, a person told.

The list is written in the client’s vocabulary, not ours. If they say “callout” we write callout. Renaming their business to fit our model is how you end up with an agent that nobody on the team can reason about.

Nearly always, writing this out produces one surprise: a step everyone assumed someone else was doing, or a rule with three exceptions that has never been stated out loud. That surprise is the week paying for itself.

Day four: the boundary

Now we draw the line. Which steps the agent takes, which it prepares for a person, which it never touches.

We argue about this openly, and we argue against automating things more often than for it. A step that happens twice a month, has real judgement in it, and would be embarrassing to get wrong is not a good first candidate. A step that happens forty times a week and is the same every time is.

The same session produces the stop conditions — the situations where the agent must fetch a human — and the escalation route: where a handoff lands and who owns it. That is the part of the agreement that protects the client’s reputation, so it gets written with as much care as the happy path.

We also name what success looks like in terms the owner would use anyway. Calls answered outside hours. Quotes that got a second nudge. Invoices paid inside terms. Numbers they can already see in their own tools, so nobody has to trust our dashboard.

Day five: the agreement

The output of the week is a short document: the workflows in scope, the step list, the boundary, the stop conditions, the tools we will connect and with what access, what we need from the client, and what we will have running by when.

It is written to be argued with. The client reads it, marks the bits that are wrong — there are always bits that are wrong — and we fix them on paper, where fixing is free.

Then it becomes the spec we build against, and it stays in the repo as the thing the code is accountable to. When we hand over, it is also the document that explains to a future engineer why the agent behaves the way it does.

Why a week, and not longer

A week is enough to see the shape of a real business and short enough that nobody is paying for discovery theatre. The remaining unknowns get answered faster by a working agent in front of a real customer than by another week of interviews.

Build too early and you automate the tidy version. Discover too long and you never ship. One week, one document, then code.