Why should you ask an AI vendor to show you a failure?

A demo is a win reel. That is not a criticism, it is what a demo is for.

A demo shows the product working when everything it needs is present. The enquiry has a port pair, a weight, dimensions and an Incoterm. The rate is in the system. Nothing in your week looks like that.

Failure is where the edges of a product sit. It is the only place you find out what the software does when the weight is in pounds, the port is one of four with the same name, and the enquiry arrived as a photograph of a screen.

There is a second reason, and it is not about the software. Volume produces failure. A vendor who has processed a few hundred thousand enquiries has a ranked list of things that went wrong, with fixes against most of them. A vendor who has processed four hundred has anecdotes. When somebody tells you nothing has ever gone wrong, the useful reading is not that the product is unusually good. It is that they have not run enough work to find out.

A3 is really two questions joined together. “Show me one it got wrong” asks for a case. “Tell me what happened next” asks whether they have a process. The second half does the work, and only if you ask it in the same breath.

A vendor who has a case ready reaches for it in about two seconds. A vendor who is constructing one takes longer, and you will hear it.

It is specific, slightly uncomfortable, and it ends with a change rather than an apology.

A strong answer has six parts. Few vendors give all six unprompted. Ask for the missing ones by name.

That last row is the one most buyers never ask about, and it is the most revealing. Teams that take failure seriously write the trigger down in advance. The Google SRE book, in its chapter on postmortem culture, lists triggers such as data loss of any kind, a resolution time above some threshold and a monitoring failure. A team which has thought about failure can tell you where their line sits without inventing one on the spot.

Two things a good answer will not do. It will not name the customer, because a vendor who discusses one customer’s bad week with you will discuss yours with somebody else. And it will not indict a person. The same chapter makes the standard explicit: a review is blameless when it focuses on the contributing causes “without indicting any individual or team”.

Ask the question knowing what an honest answer looks like, or you cannot tell a real one from a plausible one.

These are the shapes failure takes in this particular job. None of them is pinned on any product. They are what a forwarder’s own enquiry inbox does to software.

• The wrong place with the right name. Valencia in Spain and Valencia in Venezuela. Santiago in Chile, Cuba, Panama and Spain. Portsmouth twice. The enquiry says one word and the software picks a side.
• Units read as the wrong units. Dimensions in inches read as centimetres, or the other way. Gross weight taken as chargeable weight. Volume weight computed on a divisor that belongs to a different mode.
• The number that was never a number. A customer purchase order treated as a container number. A date written 03/09 in a market that reads it the other way round.
• The rate that had already gone. A rate applied after its validity ended, or a spot rate quoted as if it were contracted, or a surcharge from the previous month carried into this month’s quote.
• The thing nobody read. The rate that was inside a photograph of a spreadsheet in the third attachment. The condition in the last line of the agent’s email, under the signature.
• Two enquiries wearing one coat. A forwarded WhatsApp message containing two shipments, quoted as one. A reply-all thread where the shipper changed the destination in the eleventh message.
• The right answer to the wrong sender. A quote drafted for the customer’s competitor because both are on the thread.

Handling these afterwards is not a courtesy. NIST’s AI Risk Management Framework, which is intended for voluntary use, names manage alongside govern, map and measure as one of its four functions. A vendor who can describe what happens after something goes wrong is describing a function of a public framework, not doing you a favour.

Notice how many of these are not really software failures at all. They are the mistakes a tired coordinator makes at four on a Friday. You are not looking for a product that never errs. You are looking for one whose errors are the ordinary ones, caught in the ordinary places.

The answer will sound fine in the room. These four are why it can still mean nothing afterwards.

Trap one. A bug is not a failure

“We had an outage in March and fixed it in two hours” is an availability story. It tells you nothing about what the software does to an enquiry. Push it back: “I mean a quote. One that went out wrong, or should not have gone out at all.”

Trap two. Caught at the gate is a save, not a failure

Most vendors will reach for an example where the software got something wrong and the approving person spotted it. That is the gate working, and it is good news. It is also not what you asked. The checklist follow-up exists for exactly this: what is the worst thing that has ever reached one of your customers? Ask it every time.

Trap three. The failure is from the pilot

A story from an early trial two years ago, before the product was really the product, costs the vendor nothing to tell. Anchor it: “What is the most recent one? Say, in the last three months.”

Trap four. The data gets the blame

“The enquiry was badly formed” is true and irrelevant. Your enquiries are badly formed. That is the job. The version worth accepting names the badly formed input and then says what the product now does about it, which is usually to ask a question rather than guess.

The third answer is only fatal when the vendor also claims heavy usage, because both cannot be true.

Write it the same day, in the vendor’s own words, in one line. Write the failure down while it is in front of you. By next week the tone of the room is all that will be left.

One line per vendor with three columns is enough:

Carry the same standard into the trial. If you run a pilot, agree at the start what you will both do when something goes wrong in it, because something will. A written note, who writes it, and how quickly. The SRE chapter puts the reason plainly: unless there is some formalised process of learning from incidents, they may recur indefinitely. A vendor who already has that process will agree in a sentence. A vendor who does not will want to talk about it later.

One last use for this question. Ask it of the system you already run. What went wrong on your own quotes last quarter, who noticed, what changed. If nobody can answer that either, the problem you are shopping for is not entirely a software problem.

Then the question changes shape, and it is fair to let it.

A company with six live forwarders has not had the chance to fail in the ways a company with six hundred has. Holding that against them turns a good question into a way of choosing the largest supplier.

What to accept from a young vendor: a failure from a trial rather than a paying customer, or one found in their own testing and described with the same specificity. What matters is whether they treat it as information or as an embarrassment.

What not to accept from anybody, at any size, is the claim that it has never happened. A vendor with six customers who says “we have had three things go wrong and here they are” is more credible than a vendor with sixty who says nothing has. A3 and D3 hold each other honest. If the failure list is empty and the live-customer count is large, one of the two is wrong, and you should ask which.