AI case studies: what actually changed, and how we knew
AI features are easy to demo and hard to evaluate. This page covers what we have shipped, the patterns we build most often, and the metric we would use to tell whether each one is working.
Every AI feature we ship
your systems
documents
requests
agent
human review
ship
Every AI-assisted change passes a person, a test suite, and a security gate before it ships.
A metric agreed before we start
An eval set from your real cases
A person in front of every action
Shipped
AI summaries in a multi-campus school ERP
admissions · fees · attendanceeach campus keeps its own books
north
central
west
group
ai summarywhat changed across campuses, for the group head each morning
campuses stay independent; the roll-up is automatic
A head of school starts the day needing to know what happened across a campus — attendance, new enquiries, admissions, care logs, anything unusual. That information already existed in the system; reading it meant opening six screens.
The AI Summaries module condenses campus activity into something scannable in under a minute. The design constraint we set was deliberate: it summarises and surfaces, it does not take administrative actions on its own. Summarisation is a low-risk place for AI to be wrong — an incorrect action is not.
Summaries generated over live campus data, per branch
Read-only by design — no autonomous administrative actions
Sits alongside the underlying records, never replacing them
These are capability patterns rather than named client projects. Each one lists the metric we would agree with you before starting, because that is the part most AI projects skip.
Document extraction into a system of record
Problem
Invoices, forms, and scanned records arriving as files, with someone reading each one and retyping its contents into another system.
Approach
A pipeline that extracts structured fields, matches them against existing records, and posts clean data — with a confidence threshold below which the case goes to a person instead of being guessed.
How we measure it
Share of documents handled without human touch, plus extraction accuracy measured on a held-out sample of your real documents.
Policies, SOPs, and past tickets spread across systems, so staff either ask a colleague or guess.
Approach
Retrieval over your own corpus with permission-aware search and citations on every answer, so a user can verify the source rather than trust the output.
How we measure it
Answer accuracy and citation correctness against a curated evaluation set, plus how often the system correctly says it does not know.
01Why do these not have percentage improvements attached?
Because we would be making them up. Improvement figures depend entirely on your baseline, your data quality, and your process — and quoting a number from someone else's project tells you nothing about yours. What we do instead is define the metric during a pilot and measure it on your own data.
02How do you prove an AI feature is working?
With an evaluation set built from your real cases, scored automatically on every change, and production tracing so any individual bad output can be reconstructed. Without that, quality claims about an AI feature are opinion.
03What does a first AI project usually look like?
One narrow, high-volume, low-risk workflow, delivered in roughly four to eight weeks. It proves the value, exposes where your data actually lives, and gives you something concrete before committing to anything larger.
04Will you tell us if AI is the wrong answer?
Yes. A meaningful share of what gets brought to us is better solved with a well-designed form, a scheduled job, or a fixed integration. Saying so costs us a project and saves you one.
Next step
Want to know if AI would help you?
Tell us the workflow that costs your team the most time. We will tell you whether AI is the right tool for it, and what we would measure to find out.
