Analysing a document-heavy business workflow with Claude.

Applied Claude method

Most people meet this task as a single instruction: upload a folder and ask Claude what is going wrong. The output reads well and cannot be checked, because nothing connects a sentence in the summary to a line in a document. Splitting the work into stages fixes that, and each stage leaves behind an artefact the next person can inspect.

How should I use Claude to analyse a document-heavy business workflow?

Treat the analysis as a method with five stages rather than one long prompt. Each stage produces an artefact: a scoped question, a prepared document set, a per-document extraction table, a reviewed findings list and a handoff record. The artefacts make the result checkable by someone else.

The method applies to any workflow where people read a repeating set of documents and reach a decision: invoice exceptions, claims intake, contract renewals, supplier onboarding, grant assessment, incident reports, benefit eligibility. Every example on this page uses a fictional company and fictional documents.

Stage 1: Choose the workflow and write its scope statement

A workflow suits this method when four things hold. People repeat it on a known trigger. The inputs are documents rather than conversations. The output supports a defined decision. And the rule behind the decision is written somewhere. When the rule lives only in one experienced person's head, writing it down is the first task, because an analysis with no stated rule has nothing to test findings against.

Scope tightly. "Review our contracts" is a project. A workflow names a trigger, a fixed document set, a decision, and the person who owns that decision. Anything the analysis will not cover goes in the scope statement as an explicit exclusion, so a reader later knows a gap was a choice rather than an oversight.

That scope statement carries through the rest of the method. Stage 4 tests completeness against it, and stage 5 hands it to whoever inherits the work.

Stage 2: Prepare the inputs before Claude sees them

Redaction comes first, and the way you redact decides whether the analysis is possible at all. Remove personal names, contact details, account identifiers and commercially sensitive terms, then replace each one with a stable token that is reused across every document in the case. If the purchase order says SUPPLIER-A, the delivery note and the invoice say SUPPLIER-A too. Consistent tokens preserve the joins the analysis depends on; blanking fields destroys them, and a document set with the links removed produces confident findings about nothing.

Number every file. Each document gets an exhibit ID such as C07-INV, and the analysis is required to cite that ID for every field it reports. Exhibit numbering is what turns a summary into something a reviewer can check in seconds instead of hunting through a folder.

Sample deliberately. Take a spread across months and across outcomes, including the cases that experienced staff call hard, rather than the first twenty files in the folder. A sample drawn from one quiet month produces a picture of that month. Include the awkward categories on purpose, because those are where the workflow actually breaks.

Check the text quality. Scanned pages, photographed delivery notes and handwritten annotations are the weakest link in any document analysis, and a misread digit propagates silently into a conclusion. Mark low-confidence documents in the register so stage 4 knows where to look first.

Meridian assembles 24 exception cases at four documents each, giving 96 numbered exhibits. Six cases are tagged as known-hard: partial deliveries, credit notes and two invoices that arrived as phone photographs. One case runs end to end before the batch, which is how the team discovers that delivery notes carry two different date fields.

Stage 3: Run the analysis pass in two parts

A single prompt that asks "what is going wrong in these cases" mixes reading and reasoning in one step. When the reading is wrong, the reasoning is still fluent, and the error reaches the conclusion with no visible seam. Splitting the pass in two exposes the reading on its own, where it can be checked.

The extraction pass runs per case against a fixed schema. Claude fills the same fields for every case, one row per case, and returns "not stated" where a document does not contain the field. Every field carries its exhibit ID and the quoted line it came from. Forbidding inference at this stage is the point: a blank that should be blank is a finding, and an inferred value is a fabricated one.

The synthesis pass runs over the extraction table. The raw documents remain available for review but do not become synthesis input. Ask for the cases grouped by failure condition, the count in each group, the case IDs inside each group, and the cases where the evidence is ambiguous. Instructing Claude to list ambiguity rather than force a category is what keeps the awkward six cases visible instead of quietly absorbed into the largest group.

Record the prompts, the model used and the date alongside the output. A finding without that record cannot be reproduced, and reproducibility is the whole reason for the exercise. Once the two passes are stable and someone wants them to run on a schedule rather than by hand, the mechanics move into a tool loop, covered in building a production Claude tool loop.

Meridian's synthesis groups the 24 cases into five conditions. Seven concern a delivery note filed after the invoice arrived, and six concern partial delivery missing from the order record. Five show a quantity mismatch, four lack explicit approval in the email thread, and two repeat a purchase-order reference. Three cases are flagged ambiguous, all from photographed invoices.

Stage 4: Review the reading before you trust the reasoning

The reviewer must be someone who does the workflow. A reviewer who reads only for tone will approve a table that is internally consistent and factually wrong, because the errors that matter here look like ordinary numbers. Three tests catch them.

Traceability. Every high-impact field is opened against its exhibit and its quoted line. Check 100% of the fields that drive the grouping, 100% of fields marked "not stated", and a fixed sample of the rest. A blank that is really a missed page is the most expensive error in this method, because it manufactures a failure condition that does not exist.

Consistency. Recheck arithmetic, units and dates against the source. Quantities in cases and quantities in boxes are a common trap, and two date fields on one document defeat any comparison that does not name which field it used.

Completeness. Compare the findings against the scope statement from stage 1. The Meridian question asked which conditions cause exceptions to sit unresolved beyond five working days, so a grouping that reports conditions without days-to-resolution has not answered it, however accurate each row is.

Record every correction in a log so the change stays visible. At Meridian the reviewer finds two errors, both in photographed delivery notes where a quantity was misread. Both cases move from "quantity mismatch" into "partial delivery not recorded", so the corrected counts read 7, 8, 3, 4 and 2 across the same 24 cases. The synthesis is then rerun on the corrected table, because a conclusion drawn from a table that has changed is no longer supported by it. The claim-by-claim discipline behind this stage is set out in validating Claude output for professional work.

Stage 5: Hand off a record someone else can rerun

The analysis is finished when a colleague can repeat it without asking you anything. The handoff starts with the scope statement, document register, exhibit IDs, redaction tokens, prompts, model and date. It also carries the extraction table, corrections log, findings with case IDs, open questions and the named owner of each decision.

Keep the boundary clear in the write-up. The analysis names conditions and counts them. Changing the purchase order template, the delivery note filing rule or the approval step is a management decision, made by the decision owner named in stage 1, with the analysis as evidence. Writing a recommendation as though it were a finding is the fastest way to lose the trust that the exhibit numbering earned.

The handoff also has a second life. A redacted analysis record with its scope statement, extraction schema and corrections log intact becomes concrete applied evidence. The guide to building Claude portfolio work samples explains how to present it to a hiring manager.

The document-workflow analysis template

Copy this table into your own working document and fill the last column before you start. Every row names the artefact that leaves the stage, so an unfinished row is visible rather than assumed.

Where this method fails

• The document set was sampled from one period, so the findings describe that period rather than the workflow.
• Redaction removed the identifiers that linked the documents, and the analysis reported patterns it could not have seen.
• The extraction pass inferred a value the document never stated, and the inference became a counted condition.
• The reviewer checked the prose and never opened an exhibit.
• The synthesis was rerun in the reader's head after corrections, so the published counts belong to the uncorrected table.
• The write-up promoted a recommendation to a finding, and the decision owner lost the ability to weigh it.

Scoping a task, controlling inputs, checking output against evidence and documenting what you did are the habits this method builds, and they are the habits professional Claude work rewards. The study topics page lists what each exam covers, certifications sets out the four tracks and the official Anthropic exam fees of $99, $125 and $175, and the questions page answers how access and booking work.

Related Timo Labs guides

• Validating Claude output for professional work
• The enterprise Claude safety stack
• Building a production Claude tool loop
• Judging your certification readiness
• Building an applied AI career with Claude
• Claude portfolio work samples
• Employer sponsorship and study cohorts

Common questions about document-workflow analysis