A polished AI workflow proves very little until a buyer uploads the spreadsheet they already use. Merged cells, duplicate records and missing IDs reveal whether the product can handle real work or only controlled demonstrations.
In October 2020, Public Health England discovered that 15,841 positive COVID-19 test results had been left out of its daily reporting. The laboratory data had exceeded the row limit of an old Excel file format. The records existed, but part of the spreadsheet never entered the reporting system.
The BBC documented the failure while Health Secretary Matt Hancock faced questions in the House of Commons. Public Health England resolved the immediate problem by splitting the data into smaller files. By then, thousands of cases had entered the system late, delaying contact tracing.
The software had processed the file it received. The operational system had still failed.
The spreadsheet was part of the product
I have seen AI demonstrations built around data prepared by the founder. The column names are consistent. Every customer has an ID. Dates follow one format. Duplicate rows disappeared before anyone opened the meeting link.
Under those conditions, the workflow looks finished.
Then a prospective buyer in Kigali uploads the workbook their team uses every week. One heading spans three columns. A customer appears twice because two employees entered the name differently. Several records have no identifier. Dates move between formats. Notes sit beside values the model is expected to classify.
The first run fails.
This moment can feel embarrassing because the founder believed the meeting was about model quality. The buyer was testing something broader: can this product survive contact with the way our company actually operates?
The spreadsheet is not an annoying exception around the product. It is an input to the product, which makes its disorder part of the product problem.
Public Health England’s Excel failure had much higher stakes, but the mechanism is familiar. A system designed around an assumed input reached real data with different limits. Everything downstream inherited the mistake.
A successful demo can hide the wrong achievement
Founders working with limited runway need demonstrations. A demo can win attention, uncover objections and move a buyer toward a paid pilot. The danger comes when the team treats one successful path as evidence that the workflow is ready.
The model may be accurate on the founder’s sample while the import layer remains brittle. The dashboard may look clear while duplicate records distort every total. The automation may route ninety test rows correctly, then fail when one missing ID breaks the relationship between two tables.
None of those failures require a better model. They require decisions about the operating boundary.
What file types will the product accept? Which columns must exist? How will it detect duplicates? Should it reject incomplete rows, flag them for review or make a reversible assumption? Who sees the errors, and can that person correct them without calling the founder?
These questions sound less impressive than discussing agents, retrieval or model choice. They often determine whether the buyer can use the product on Monday.
That is also why a pilot should include customer-owned data early. The point is not to prove that the founder can make the workflow run. The point is to learn where the buyer’s reality breaks it while the scope is still small enough to change. A paid pilot can change the roadmap before a larger build consumes the runway.
The failure needs to become visible
When the Kigali workbook fails, the weakest response is to repair it privately, rerun the demo and continue as if nothing happened. That restores the presentation while hiding the product decision.
A stronger response starts by showing what the system found.
The upload contained duplicate records. Some rows lacked the identifier required to match them. Merged cells changed how the headings were read. The workflow stopped rather than writing uncertain output into the buyer’s records.
That explanation gives the buyer something useful: a clear boundary. It also gives the founder a choice between three honest next steps.
The team can narrow the accepted input format and provide a template. It can build validation that catches common problems before processing begins. Or it can include a paid data-cleaning step in the pilot because the customer’s source files vary too much for automatic handling.
Each choice carries a cost. A strict template reduces engineering work but asks the buyer to change behaviour. More validation makes onboarding easier but consumes runway. Manual preparation can get the pilot moving, although it may hide work that will become expensive at ten customers.
The decision should be explicit. Otherwise, the founder quietly becomes the import system.
This is close to the problem in Ama’s failed signup: the visible failure happens at one step, but the commercial risk comes from an assumption nobody tested.
Test the ugly file before the important meeting
Before the next buyer demonstration, ask for a representative export with sensitive fields removed or replaced under an agreed process. Do not request a founder-cleaned sample. Ask for the kind of file an employee would normally send.
Run it through a preflight check before the AI touches it. Confirm the required columns, identifier coverage, duplicate rate, date formats and any merged cells. Produce an error report the buyer can understand. Keep the original file unchanged, and make every correction traceable.
Then decide which failures should stop processing. Missing IDs may require a hard stop. Duplicate records may need review. A slightly different heading may be safe to map after confirmation. The product should distinguish those cases instead of treating every imperfect row as equally acceptable or equally fatal.
Public Health England fixed its immediate Excel problem by splitting the files, but the lasting lesson sits earlier in the chain: input limits belong in system design. A file that looks ordinary to the buyer can expose the assumption holding the whole workflow together.
The next demo should begin with that file.
Comments
No comments yet.