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 in, because they need different money and different people. Tenhaw does that diagnosis before scoping a build. 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 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, 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.

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. Whether the extraction is viable at all is the cheaper question to answer first, so run it against the estate as it stands. Tenhaw did exactly that for a London insurance market business, taking PDFs to business intelligence on Azure in a two-week proof of concept, ahead of any data platform work. 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. That scope usually sits with a different sponsor and a different budget line, which is where programmes with working extraction and untrusted numbers get stuck.

Intelligent document processing, or IDP, also called document intelligence, turns unstructured source material such as PDFs, scans, email and forms into structured data that lands in a warehouse and drives business intelligence. It is where most enterprises meet agentic AI first, because the source material already exists, nothing is customer-facing, and the value is easy to describe to a board. It is also the pattern most likely to stall between a convincing extraction demo and a number the business will actually act on, which is why exception handling, ground truth and the BI layer matter as much as the model.

Build a ground-truth set with the people who own the decision, before anyone argues about models. Two experienced underwriters will disagree about what a document says, so if the decision owners have not agreed what a correct answer is, every accuracy conversation becomes an argument about the benchmark rather than the system. Done properly it is a fortnight of work rather than a phase, built from real documents, including the long tail of scanned faxes, amended schedules and important numbers buried in footnotes, with the experts' disagreements resolved into agreed answers. Skip it and the pilot never fails a test, it simply never gets one, which is how document programmes sit unresolved for quarters.

Separable stages, in a deliberate order. First use a language model to turn each document into a markdown representation of itself, so the extraction is inspectable by a human and re-runnable when the field list changes, then narrow to the fields that matter. Normalise those fields into consistent formats, enrich them against third-party APIs, then add semantic enhancement, context and thematic grouping, so downstream logic works with meaning rather than strings. Finally apply business logic and surface the result in a dashboard, not just a populated table. Keeping the stages separable matters because enrichment and semantics are where accuracy problems are usually diagnosable.

Route work by confidence and consequence instead of building a first-in, first-out queue. Every serious implementation keeps humans in the loop, but most implement it as a queue worked in order, which spends scarce expert time uniformly across easy and hard cases until review becomes the bottleneck and the business case shows a saving the operation cannot feel. Score confidence using the provenance of the data, which enrichment source it came from, alongside model certainty and a search-based cross-check, because a model's own confidence is a weak signal on its own. Then send experts only the cases where low confidence meets real consequence.

Less than the vendors suggest. Tenhaw has delivered this pattern end to end on Azure, including Azure OpenAI. A London specialty insurance proof of concept took PDFs to business intelligence in two weeks, ground the business had circled for roughly a year, with month three productionising it against the client's security standards. The parts where programmes actually fail, ground truth, exception design, human routing, the semantic layer and lineage, are provider-independent and transfer intact. What genuinely differs is the document-understanding service and how it handles layout and tables, how permissions propagate from the source repository through to the warehouse, and the residency position. On AWS or Google Cloud those service choices are scoped with your own platform engineers and priced into the engagement.

Everything that happens after the text comes off the page. Optical character recognition and template extraction solve the easy half, which is getting the characters out. Tenhaw builds the other half. Document intelligence carries those fields on: normalised into consistent formats, enriched against third-party sources, grouped semantically so downstream logic works with meaning rather than strings, then interpreted by business logic and surfaced somewhere people actually decide with. That last step is what separates document intelligence from document extraction, and it is the one most often descoped when a programme runs late, which is how organisations end up with a populated table nobody uses. If your current tool reads a stable template accurately and somebody already acts on the output, keep it.

In two pieces, and it is the second one budgets tend to miss. Tenhaw's Agentic Proof of Concept against one document type and one real workflow is a fixed £20,000 to £55,000 over two to four weeks, set by the complexity of the workflow and the state of the data underneath it. Productionising it is a separate phase, four to six weeks with a dedicated team, and an Agentic Build Team is £70,000 to £85,000 a month. Then there are the data foundations. A governed semantic layer, agreed definitions and lineage back to the source document usually sit with a different sponsor and a different budget line, and programmes that meet that late stall with the extraction working and the numbers untrusted.

One document type, one real workflow, and a workflow whose output somebody actually decides with. Document work is usually where an organisation meets agentic AI first because the source material already exists, nothing is customer-facing, and the value is easy to describe to a board, so the temptation is to pick the tidiest document type in the building. Resist it. Accuracy on a curated sample tells you almost nothing about the scanned fax, the amended schedule, or the important number sitting in a footnote. Choose something with real exceptions and a named destination for the data, or the proof of concept proves the wrong thing.

Four groups, and missing any one of them is the usual cause of a stall. The people who own the decision, because ground truth has to be agreed with them and two experienced experts will disagree about what a document says. Your own engineers, because Tenhaw pairs with them throughout the build and the point is that your team can run it afterwards. Whoever owns the warehouse and the semantic layer, since agreed definitions and lineage are usually a different sponsor with a different budget line. And the operations people whose review time you are about to route by confidence and consequence instead of a first-come queue.

Layout and table handling is one of the genuinely provider-specific decisions in this pattern, so test it on your own documents rather than taking a vendor demo on trust. The pipeline shape helps, and Tenhaw ran this one on Azure for a London insurance market client. Each source document is first turned into a markdown representation of itself, which keeps what the model read inspectable by a human, and only then is it narrowed to the fields that matter. When a layout defeats it, you want that arriving as low confidence and routing to a person rather than as a confident wrong value in a dashboard. Design that exception path before anyone argues about which document-understanding service wins.

Less than you would fear, if the pipeline was built in separable stages. Each document is first turned into a markdown representation of itself and only then narrowed to the fields that matter, so extraction stays inspectable by a human and re-runnable when the field list changes rather than being a black box from PDF to database column. A shape the pipeline has not seen before tends to arrive as low confidence, which is exactly what routing by confidence and consequence exists for. Validating a system like this is only feasible during operation, the published engineering literature says, and its robustness evolves rather than being designed in at the start.

Not if the pipeline is deployed the way Tenhaw deploys it, on your infrastructure and under your policies. The delivered version ran end to end on Azure inside a London insurance market client's own regulated estate, with UK data residency the default and the EU available where that is the requirement. The residency question worth settling early is narrower than most people expect, coming down to which region the document-understanding service processes a file in and how identity and permissions propagate from the source repository through to the warehouse. Both are genuinely provider-specific, and both are far cheaper to answer before any documents move.

Design for it, because a sceptical reviewer asks for it first and it is not free. Three mechanisms do the work. Extracting each document into a readable markdown form before narrowing to fields keeps the extraction inspectable by a human rather than a black box. Confidence is scored using the provenance of the data, meaning which third-party enrichment source a value came from, alongside model certainty and a search-based cross-check, so you can say why a number was trusted. And lineage back to the source document belongs in the build alongside the semantic layer, because without it the programme has delivered extraction and not intelligence.