The AI Platform They Were Already Paying For

A platform scoped from a feeling

The business case described a document intelligence platform handling every inbound document type across the practice. It was thorough, well written, and built on an estimate of document volume that came from asking staff how much time they spent on paperwork.

That is a reasonable way to discover you have a problem. It is a poor way to scope a build, because it tells you the total pain without telling you where it is concentrated. Everything looks equally urgent when you measure it by how it feels in March.

We asked for a random sample of four thousand documents received over the previous two seasons, along with the time-tracking records for the staff processing them.

The distribution nobody had looked at

Three form types accounted for roughly seventy-one percent of all documents received. They were highly structured, arrived in predictable formats, and were being keyed by hand into the practice management system by junior staff.

The remaining twenty-nine percent was a long tail of nearly ninety distinct document types, many appearing a handful of times a year. Several were genuinely unstructured client correspondence that no extraction system would handle reliably, and where an error would be expensive and hard to detect.

The original scope treated all of this as one problem. Building for the long tail meant an accuracy target the technology could not honestly hit on those documents, an open-ended review burden, and a system that would be blamed for every mistake it made on a document it should never have been pointed at.

The feature already on the invoice

Partway through the systems review we found that the firm practice management platform included a structured-document ingestion module. It was on the licence. It had been enabled during the original rollout, never configured, and had been quietly renewed for three years.

It did not solve everything, and we were careful not to oversell it. It handled one of the three high-volume form types competently and a portion of a second. But it existed, it was paid for, and configuring it was days of work rather than a build.

This is the least glamorous finding in an assessment and often the most common. Firms rarely use everything they license, and nobody audits it because the renewal is smaller than the build being proposed.

Scoping to the volume instead of the anxiety

The recommendation was narrow extraction built properly for the three high-volume form types, with a confidence threshold that routed anything uncertain to a person instead of guessing. Configure the licensed module for what it genuinely covered. Leave the long tail manual, deliberately and on the record.

That last point mattered most to the partners and took the longest conversation. Choosing not to automate something feels like an incomplete project. We put it in writing as a decision with reasoning attached, so it could be revisited when volume changed rather than relitigated every season.

Total cost landed at roughly a third of the platform scope, and the accuracy target for what was built was one we could actually commit to, because it applied to documents that could support it.

What we told them not to build

The assessment recommended against automating client correspondence entirely. The volume was low, the variation was extreme, and the cost of a confident wrong answer on a client instruction is not a rounding error in this profession.

That section was the shortest in the document and the one most referenced afterwards, because it settled an argument the firm had been having internally for over a year.