02.01
Document and email understanding
Pulling structured information out of unstructured text — contracts, invoices, tickets, correspondence.
Index What we do S/02
AI where it earns its place.
S/02 / Scope
What this covers.
02.02
Classification and routing
Incoming work sorted and sent to the right queue or person, with a confidence threshold and a human path for the rest.
02.03
Drafting and summarisation
First drafts and summaries generated inside the tool where the work happens, not in a separate tab.
02.04
Search over your own content
Retrieval across your documents and records, answering with citations to the source rather than a confident guess.
02.05
Customer-facing assistants
Where the use case is well-bounded and the failure modes are understood.
02.06
Evaluation and guardrails
A test set, a measured accuracy figure, and defined behaviour for when the model is uncertain.
Signals
Where this usually starts.
01
Staff spend hours reading and sorting text that arrives in high volume.
02
Information exists somewhere in your systems but nobody can find it quickly.
03
You ran a pilot that impressed everyone in the demo and never shipped.
04
You're being asked what your AI strategy is and want a real answer rather than a slide.
05
A manual review step is the bottleneck in an otherwise fast process.
Deliverables
What you get.
A defined use case with a success measure
Written down before anything is built, so "is this working?" has an answer.
A working implementation
Inside your existing systems and workflow, not as a separate product your team has to remember to open.
An evaluation set
Real examples with known correct answers, so accuracy is a number rather than an impression.
A cost and latency budget
What each run costs, what it costs at ten times the volume, and how fast it responds.
An escalation path
What happens when the model is unsure — because it will be, and that case needs a design.
Every engagement follows the same four stages — understand, design, build, improve. Scope and price are agreed before anything is built.
How we workQuestions
Asked often enough to answer here.
Which models do you use?
Whichever fits the task, the budget, and your data constraints. That decision belongs in the design stage, not before it. We build so the model can be swapped without rewriting the surrounding system, because this part of the field moves quickly.
Will our data be used to train someone's model?
That depends entirely on the provider and the plan, and it's one of the first things we establish. Where the data is sensitive or contractually restricted, we scope to providers with no-training guarantees, or to models you run in your own environment.
How do you know the output is accurate?
We build an evaluation set from your real examples with known correct answers, and measure against it. If accuracy isn't good enough for the use case, that's a finding worth having early rather than after launch.
What does it cost to run?
Ongoing cost depends on volume and model choice, and we give you the figure per run and at projected volume before you commit. For many document and classification tasks it's a fraction of the labour it replaces; for some use cases it isn't, and we'll say so.
Have a project in mind?
Tell us what you're working on and what you need help with. We answer every message ourselves, usually within two business days.