An unfinished human-support off-ramp is safer than another missed launch only when the founder can bound the harm, see failures quickly, and stop new usage immediately. If a failed handoff could trap a customer in a payment, account, or irreversible action, delay the affected path and ship a narrower version.
At 4:47 on a Friday afternoon in Lagos, Tunde had thirteen minutes before the release window his team had promised for the third time. He was standing beside a whiteboard with a cold takeaway container in one hand, watching the final test fail again.
Tunde is an invented composite, but the decision is familiar. His four-person company had built an AI assistant that helped small businesses sort incoming customer requests. The assistant could answer routine questions and send uncertain cases to a human. The AI worked. The handoff did not always carry the full conversation history.
If he shipped, a support agent might receive an urgent request without the detail needed to act. If he delayed, the pilot company could cancel on Monday after two missed dates. Nobody in the room knew which failure would cost more.
Separate an incomplete experience from an unsafe one
The team had been treating every failed handoff as one category: broken.
That hid the decision.
In one test, the agent received the customer’s name and request but had to open the original conversation for context. Annoying, slower, recoverable.
In another, the handoff appeared successful to the customer but never entered the agent’s queue. The customer could wait for help that was not coming. That failure was silent, which made it harder to detect and more dangerous to ship.
This distinction matters when runway is short. A rough experience can produce useful evidence. A silent failure can produce false confidence while customers absorb the cost.
I use three questions when a launch reaches this point:
- Can the customer tell that the automated path has failed?
- Can the team see the failure without waiting for a complaint?
- Can the action be reversed or completed manually?
A “no” on all three is a reason to block that path. A mixed answer may support a limited release with someone watching it closely.
The same reasoning appears in the unreliable final step at 8:12. Reliability at the last step carries more weight because that is where the user has already committed time, information, or trust.
Make the launch smaller than the risk
At 4:53, Tunde stopped asking whether the product was ready. He asked what version could fail without leaving anyone stranded.
The team removed two request categories from the release. Those cases involved changes that a customer would expect to happen promptly, so an invisible handoff failure carried too much risk. The assistant would state that it could not complete those requests and direct the customer to the existing support channel.
For the remaining categories, they changed the confirmation message. It no longer implied that a human had received the case. It told the customer that the request had been recorded and showed the fallback contact method.
They also limited the release to the pilot company’s internal support staff. One team member would monitor every transfer during the first session. If a handoff disappeared, they could pause the assistant before another person reached the same point.
That was the turn. They had spent the afternoon trying to finish the off-ramp. With minutes left, they reduced the area where the off-ramp mattered.
A narrow launch often looks less impressive in a demo. It can reveal more because the team knows which failures it has accepted, who can encounter them, and how to stop them.
Write the stop rule before pressing release
At 4:58, one question remained: how many failed handoffs were acceptable?
“Let us watch it” was too vague. Under pressure, founders reinterpret weak signals because they want the launch to survive.
Tunde wrote the stop rule on the whiteboard. Any silent handoff failure would pause the release. A visible handoff missing context could be handled manually and logged for the next build. The rule separated inconvenience from concealed abandonment.
This is where human support earns its place in an early AI product. A manual path can protect the customer while the team learns, but only when the customer can reach it and the team has the capacity to respond. A support button that leads to an unmonitored inbox merely changes the shape of the failure.
The choice also resembles the decision in what to automate when onboarding fails with six weeks of runway: preserve human judgment around the uncertain step, then automate after the pattern becomes clear.
Ship evidence, not unresolved exposure
At 5:00, Tunde approved the limited release.
The team still had unfinished work. They also had a defined audience, visible fallback, live monitoring, reversible actions, and a written condition for stopping. Those controls made Friday’s release a test rather than a transfer of unknown risk to customers.
On Monday morning, Tunde would have something more useful than another internal estimate of readiness. He would see where people asked for human help, which context agents actually needed, and which request categories should remain blocked.
The whiteboard stayed beside his desk. At the bottom, beneath the stop rule, he added the first task for Monday: make every failed handoff visible before adding another automated path.
Comments
No comments yet.