A client gets work, or a question — never your JSON

Imagine hiring a bookkeeper, waiting a week, and receiving an envelope containing a printout of their internal notes. Not a report. Their working scratchpad, with your name at the top and a form asking you to approve it.

That is what a lot of AI products send customers, and almost nobody does it on purpose.

Three honest outcomes

When a piece of work finishes, there are exactly three things that should be able to happen:

• Deliver. Here is the work.
• Ask. We need something from you before we can carry on.
• Hold. Something came out, but it is not fit to send. A person should look.

There is a fourth, and nobody chooses it deliberately. It arrives as a shortcut: if we have a customer-friendly summary, send that — otherwise send whatever came out.

A backup plan that can leak is not a backup plan. It is your default, and it defaults to the one thing a customer must never see.

It stays hidden because it only fires when something else went slightly wrong. Everything works in testing. Then one job skips the summary, and a customer opens their portal to something that looks like a database error with a button under it.

Make it a decision, not a shortcut

The fix is boring and it works: replace "or else send whatever" with something that has to pick one of the three, and say why.

Only "deliver" produces something a customer can open. The other two are perfectly good outcomes — they just are not deliveries.

The mistake we made first

Our first version tried to be clever. If the work said it still needed something from the client and it sounded like an apology, treat it as a question rather than a delivery.

That is backwards, and it took a real customer's report to see it.

A well-written explanation — plain English, no jargon, clear about what it needs — passes every "does this sound like an apology" check and sails through as finished work. The better the explanation, the more likely it gets mistaken for a deliverable.

So now, if the work says it still needs something, that settles it. However nicely it was written.

Watch your vocabulary, but not too hard

We do check for internal jargon leaking into customer messages. The tempting list is long — endpoint, API, database, pipeline, workflow.

Every one of those is wrong to ban, because they are also the customer's words. A security company answers forty questions about API security for a living. Every business has a sales pipeline and a customer database. "We documented your onboarding workflow" is the deliverable, not a mistake.

So the banned list is tiny, and only contains words that belong to us and nobody else. A check that blocks real work gets switched off within a week — and then the actual problems come back with it.

Why holding is the safe choice

The two mistakes are not the same size.

Holding something back costs the business owner one glance at a job that did not produce customer-ready work. That is information they wanted anyway.

Sending it costs them their client's belief that there is a competent professional on the other end. And unlike a late report, that does not come back.

The entire promise is that a small business looks like it has a real back office. One page of machine output in a customer portal destroys that more completely than a week of silence.

The question to ask

If you are building anything where AI output reaches a customer, the question is not "how do we make the output good." It is: what happens when it isn't?

If the answer is "we send it anyway", you will find out from a customer.