Document and voice intelligence, answered in full.

Two to four weeks for a working proof of concept against one document type and one real workflow. On a live engagement in the London insurance market, Tenhaw delivered a working proof of concept extracting information from PDFs into business intelligence on Azure in two weeks, ground the business had been circling for roughly a year. Productionising it is a separate phase, scoped at four to six weeks with a dedicated team.

Usually for one of four reasons: accuracy on a curated sample does not survive the long tail and no exception path was designed; nobody established what a correct answer is, so every accuracy discussion becomes an argument about the benchmark; the extraction works but the BI layer has no semantic layer or governance, so the business gets confident answers from the wrong table; or human review was built as a queue rather than routed by confidence and consequence, so expert time becomes the bottleneck.

Start by working out which of the three gaps you are actually in, because they need different money and different people. If accuracy collapsed on the long tail, the missing piece is exception routing rather than a better model. If nobody can agree what a correct answer is, the next piece of work is a ground-truth set built with the people who own the decision, and it is a fortnight rather than a phase. If the extraction is fine and the numbers are not trusted, you are waiting on a semantic layer and lineage, which is a data programme with a different sponsor and a different budget line. A proof of concept that never shipped is rarely blocked on the model, and the diagnosis is cheap to do before anyone commits to a rebuild.

There is no universal number, and quoting one is a warning sign. The right question is what the exception path costs. A process that tolerates review can run at accuracy that would be unacceptable for straight-through processing. Design the routing first, by extraction confidence and business consequence, and the accuracy target falls out of it rather than being asserted up front.

Not before a proof of concept, and yes before production. A proof of concept establishes whether the extraction is viable at all, which is the cheaper question to answer first. But structured output with no semantic layer, agreed definitions or lineage produces confident answers from the wrong table, so data foundations belong in the productionisation scope rather than being discovered during it.