Reframing the ask

Most customers arrive with a solution already chosen. Sometimes it is exactly right. Often it is a sensible guess made by someone a long way from the work. Your job is to take the request seriously enough to check it.

The request is a best guess#

When a sponsor asks for "an agent" or "a chatbot", they are telling you three useful things: something hurts, they believe technology can help, and they have probably promised someone a result. They are not telling you what the problem is. That is your job to find out.

Building the literal request is rarely neutral. If the real cause is somewhere else, you have spent the budget, the sponsor still has the problem, and now they also have a tool that does not work. Reframing is not arrogance. It is the most useful thing an outsider can do.

Six requests and what is often underneath#

These patterns recur often enough to be worth knowing by heart. They are not rules. Each is a hypothesis to test.

Testing a diagnosis#

A reframe is a claim, and claims need evidence. Before you take one to a sponsor, try to prove yourself wrong.

1. 1

   Sample real cases

   Pull the last 50 or 100 items of work: tickets, claims, documents. Categorise them by hand. Twenty minutes with a spreadsheet beats a week of opinions.
2. 2

   Find the dominant failure

   Usually one or two categories account for most of the pain. Name them, with counts.
3. 3

   Ask what would falsify your story

   If you believe misrouting causes the delay, check whether correctly routed cases are actually fast. If they aren't, your story is wrong.
4. 4

   Price the alternatives

   Fixing the data, changing the process, a rule, a small model, a large model. Put a rough cost and timeline next to each.
5. 5

   Find the smallest test

   What could you change in a week that would show whether the diagnosis is right? Run that before proposing anything big.

The cheapest experiment that could prove you wrong is the most valuable thing you can propose.

Four replies#

Once you have looked at real cases, every request gets one of four replies. Say which one out loud. The costly outcome is not disagreement; it is a quiet yes from someone who doesn't believe in what they are building.

• Yes. The request holds up. Build it, and enjoy the rare simple engagement.
• Yes, smaller. Right idea, too much at once. Start with one team, one document type or one region, and earn the rest.
• Something else first. The real cause sits elsewhere, or a prerequisite is missing: nobody owns the data, the rule isn't written down, access hasn't been granted. Fix that, then revisit the request.
• No. It won't pay off, or can't be done safely. Uncommon, and worth a great deal to a customer when said early.

Saying it without making anyone wrong#

The sponsor made a reasonable call from where they sit. Frame what you found as the project already succeeding: their initiative uncovered the real problem, faster and cheaper than building the wrong thing would have. Lead with the cases, not your opinion. Twenty real examples sorted on a slide persuade more than any argument, because the sponsor reaches the conclusion themselves.

Change minds with a test, not a debate#

Sometimes the sponsor still prefers their original idea. Don't try to win the argument. Propose the smallest test that would settle it, and agree up front what result would change whose mind.

1. 1

   State both views as predictions

   "If you're right, a chatbot will resolve most contacts. If I'm right, a status text will remove half of them by itself."
2. 2

   Pick a test that takes days, not months

   Send status texts in one region for two weeks; compare contact volume with a similar region that didn't get them.
3. 3

   Agree the decision in advance

   "If volume drops by a third or more, we do the texts everywhere and scope a smaller assistant. If not, we build the chatbot."
4. 4

   Report it straight

   Whatever happens. Being proved wrong on a cheap test costs you nothing and earns a great deal of trust.