A working AI demo cannot prove a sale will happen. A buyer pays when the product enters a painful, recurring workflow with a clear owner, not when it produces an impressive answer on a screen.
At 4:40 on a Friday in Osu, Ama had the demo open on her laptop and three browser tabs ready in case the connection slipped. Her AI tool took a customer request, pulled out the missing details, drafted a response and placed the work in the right queue. The prospects watched the output appear. One leaned forward. Another asked whether it could handle a longer message.
Ama left the call with the familiar relief of a founder whose product had behaved exactly as planned.
By Monday afternoon, none of the three prospects had agreed to a pilot.
The workflow begins before the software
The follow-up calls changed the picture.
The first prospect said customer requests arrived through WhatsApp, often as voice notes forwarded between team members. By the time anyone opened the tool, a supervisor had already listened, called the customer back and written the key detail in a notebook.
The second had a shared inbox, but the actual decision happened in a short conversation near the dispatch desk. The person using the software could prepare the response. They could not approve the exception that mattered.
The third prospect had no problem with Ama’s output. They could not explain who would notice when the AI had made the wrong call, or who would be responsible for fixing it before a customer got a promise the team could not keep.
Each prospect described a workflow that began somewhere else and ended somewhere else. The demo occupied the clean middle.
That gap can be fatal on limited runway. A founder can keep improving the part people see on screen while the real work continues through calls, forwarded messages, paper notes and the judgment of one person who has been doing the job for years.
The sale stalled because the buyer could not place it
Ama had assumed the next step was a smaller version of the same demonstration. More examples. A faster response. Better prompts.
Instead, she asked each prospect to replay the last request that had caused a problem. She wanted the untidy version: who received it first, what information was missing, who made the decision and what happened when the usual person was unavailable.
The answers made the product boundary visible.
One prospect needed a way to capture voice-note requests before they disappeared into a manager’s phone. Another needed a record of exceptions and approvals, because the AI draft was useful only after someone accountable had reviewed it. The third did not need more automation at all. They needed a simple handoff between the person speaking to the customer and the person who could act.
Ama had a harder decision than improving a demo. She could keep selling the broad promise of AI-assisted customer operations, or narrow the product around one workflow where a team could name the owner, the trigger and the moment an answer became risky.
She chose the narrower path. It meant abandoning a few attractive use cases that looked good in a sales call. It also meant the product had a place to live after the call ended.
This is the same discipline behind Esi’s lesson from a customer’s real workflow: product value becomes clearer when the team follows the work as it is actually done.
A pilot needs a real handoff, not an enthusiastic audience
A useful pilot starts with one concrete event. A request arrives. Someone has to decide something. The current process has a known failure point. The product changes that moment without requiring the whole company to behave differently on day one.
Ama returned to the second prospect with a smaller proposal. The tool would prepare a draft from incoming requests, flag the missing details and send exceptions to the person already responsible for approval. It would not claim to run the entire support operation. It would sit inside the point where replies were delayed because information and authority were separated.
There was still risk. The prospect could decide the current process was good enough, or conclude that the handoff was too informal to support software. That was a more useful risk than another polished demo, because it exposed whether there was a paid problem underneath the interest.
The buyer agreed to map a week of requests before discussing a rollout.
Build around the work people protect
On the next Friday, Ama’s laptop was still open in the same café. This time, the most useful thing on her screen was not the AI response. It was a rough map of who touched a request before it became a decision.
She had three questions written beside it: What starts the work? Who owns the outcome? What happens when the usual person is unavailable?
Those questions made the product smaller. They also gave it a chance to be used.
Comments
No comments yet.