Services / AI / Team copilots

Your team starts from a good first draft, never a blank page

The hard part of a report is rarely the thinking. It is the ninety minutes of assembling, formatting and phrasing that stands between the thinking and a finished document. That is the part a copilot takes, and the reason people notice their week getting shorter.

Start the conversation →See the technology

Why it matters

The cost is the wait

Ask anyone in your organisation which part of their week they would hand over tomorrow and the answers come back the same: writing up the meeting, turning notes into a report, drafting the same email for the fortieth time, reformatting a document into the house template. It is skilled people doing unskilled work, and it is where a surprising share of your payroll goes.

A copilot is not a general chatbot parked in the corner of the screen, and it is not a replacement for the person. It is a narrow tool built for one job that one team does often (with your templates, your house style, your terminology and your real data behind it), producing a first draft good enough that reviewing it is genuinely faster than writing it. If it is not faster, people quietly stop using it, and we would much rather discover that during a pilot than after a rollout.

We build them into the tools people already have open (Outlook, Word, Slack, Teams, Google Docs, your CRM) because a copilot that lives on a separate website is a copilot nobody opens after the second week. And the review step is designed in rather than bolted on: a person's name goes on the output, so a person reads it before it goes anywhere.

What you actually get

Built to be trusted

A copilot earns its place by beating the alternative on one real task. These are the things that decide whether it does.

Built around one job, not everything

A bid-response copilot, a meeting-notes copilot, a case-summary copilot. Narrow tools with your structure already baked in beat a general assistant on the specific task that is actually costing you hours.

It writes in your house style

Your templates, your terminology, the phrases your sector requires and the ones your legal team has banned. Built from your own approved documents, so the draft arrives looking like your organisation wrote it rather than like a generic assistant did.

It knows your material

Drafts are assembled from your real content (the last twenty proposals, the client's file, the meeting transcript, the policy that applies) not from whatever the model happens to remember. Sources are listed so the reviewer can check the facts quickly instead of re-researching them.

It works where people already work

In Outlook, Word, Slack, Teams, Google Docs or your CRM. Anything requiring people to open a separate tool and paste things in and out gets used enthusiastically for a fortnight and then not at all. We have watched it happen.

Review is part of the design

Drafts arrive marked as drafts, with the uncertain parts flagged and the sources listed, so a reviewer knows where to look hardest. Nothing is sent, filed or published without a person deciding it should be.

You can see whether it is working

Adoption per team, time from draft to sent, how much of each draft survives editing. Real numbers, so the copilots that earn their keep get invested in and the ones nobody opens get switched off rather than quietly maintained forever.

Where it earns its keep

Same pattern, different desks

Three teams, three kinds of writing, one complaint in common, the document takes considerably longer than the thinking behind it.

01 · Sales & bid teams

The tender response that starts at seventy percent

The problem: A tender lands with ninety questions, most of which you have answered before in slightly different words across a dozen past submissions. The best people in the business lose a fortnight to it, the deadline forces a rushed final pass, and the answers that get reused are whichever ones somebody happened to remember.
What we build: A copilot with every past bid, case study, policy and accreditation indexed behind it. Each question gets a drafted answer assembled from your strongest previous material, with the sources listed and the genuine gaps, the things you have never actually answered, flagged for a human to write properly.
What changes: Bid teams spend their time on the answers that win the work and on tailoring the response to the buyer, rather than hunting through old submissions for a paragraph they are certain exists somewhere.

02 · Schools & colleges

Reports that still sound like the teacher who wrote them

The problem: Report season means hundreds of comments written in evenings and weekends, under pressure to be personal, accurate and consistent with the school's standards. The result is either exhausted staff or comments that read as though they came from a template, and frequently both at once.
What we build: A copilot that turns a teacher's own notes, marks and observations into a first-draft comment in the school's agreed structure and tone, with the school's rules on wording enforced automatically. The teacher edits and approves every single one; nothing is written about a pupil that a person has not read and signed off.
What changes: The evenings come back, comments stay specific to the individual pupil because they start from that teacher's own observations, and language stays consistent across a department without anyone policing it by hand.

03 · Engineering & surveying consultancies

From site notes to a formatted report

The problem: A surveyor spends the morning on site and the afternoon turning voice notes, photographs and measurements into a formal report in the practice's template. The billable work was the inspection; the report is overhead, and it is what creates the backlog everybody is apologising for.
What we build: Voice notes and photographs captured on site are transcribed, matched to the right sections of the report template, and assembled into a draft with observations, images and standard clauses already in place. The surveyor reviews, corrects and signs, with the professional judgement, and the liability, staying firmly with them.
What changes: Reports go out in a fraction of the time, formatting is consistent across every surveyor in the practice, and site notes stop going cold while they wait for a free afternoon.

The technology

The tools behind it, named

Copilots are mostly an integration and evaluation problem. The model matters, but the difference between one people use daily and one they abandon is where it lives and how carefully it has been tuned to the actual task.

6 layers · 29 technologies

The models

Chosen per task against your own examples, a strong model for a bid answer where the words carry money, a fast cheap one for a meeting summary.

Anthropic Claude
OpenAI
Google Gemini
Mistral
Meta Llama
Ollama

Meetings, calls and voice notes

Accurate transcription with speakers identified is the foundation of every summarising copilot, and often the fastest measurable saving available, because it removes note-taking without changing how anyone works.

Deepgram
OpenAI Whisper
ElevenLabs

Where the copilot lives

Inside the applications already open on your team's screens, not on a website they have to remember to visit.

Microsoft 365
Slack
Gmail
Google Drive
Notion
HubSpot

Grounding the drafts

Your past documents indexed so a draft is assembled from material your organisation has already approved, with the sources shown.

LlamaIndex
LangChain
Qdrant
Elasticsearch
PostgreSQL

Managing the instructions

The prompts steering a copilot are treated as source code (versioned, reviewed and tested) so improving one case cannot quietly break ten others nobody thought to check.

Langfuse
GitHub Actions
Python
TypeScript

Governance and hosting

Who used what, on which document, with which model: recorded, because a tool writing on your organisation's behalf has to be auditable. Deployed wherever your policy requires, including entirely in-house.

Microsoft Azure
AWS
Docker
Grafana
Sentry

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Four to eight weeks per copilot, and we deliberately start with one team and one task rather than a company-wide rollout nobody asked for.

We find where the hours actually are

A short study of how a team's week is really spent, looking for a task that is frequent, text-heavy and already reviewed by a person. That combination is where copilots pay for themselves; the rare, high-stakes, one-off document is where they do not.

We collect your best examples

Twenty or thirty documents your organisation is proud of: the bids that won, the reports that read well, the replies you would want copied. These define the target, and they are worth considerably more to the result than any amount of clever prompting.

We build one narrow tool

A single task, your template, your language, grounded in your material, sitting inside the application the team already uses. Deliberately narrow, because a general assistant is impressive in a demonstration and unhelpful on a Tuesday afternoon.

We measure it against the real thing

The same tasks done both ways: how long a draft takes to review against how long it took to write from scratch, and how much of the draft survives editing. If reviewing is not meaningfully faster, the tool is wrong and we will say so rather than tune it forever.

One team, then the next

A pilot team uses it for real work while we tune the phrasing, the structure and the things it keeps getting wrong. It only goes wider once that team would genuinely object to having it taken away.

Then it is maintained

Approved outputs become new examples, changes to your house style get folded in, and usage is reviewed regularly so copilots nobody opens are retired instead of lingering on the invoice.

Before you commit

The questions worth asking

Is there a risk people just accept whatever it writes?

Yes, and it is the failure mode we design hardest against, people rubber-stamp a fluent draft in a way they never would a colleague's rough one. We counter it by flagging the uncertain parts instead of presenting a uniformly confident document, by showing sources so checking is quick, and by refusing to build copilots for outputs nobody will read before they go out. It is worth being blunt: this risk is managed rather than eliminated, and any supplier telling you otherwise has not run one of these in a real organisation.

Will it write things that are simply wrong?

It can. Grounding drafts in your own documents removes most invention, but a draft assembled from your material can still misread a figure or apply last year's version of a clause. That is exactly why the review step is designed in rather than optional, and why we scope copilots to work that a person was always going to check.

Our staff are worried this is about replacing them.

That concern deserves a straight answer rather than reassurance. These tools are built around a person reviewing and signing the output, so the role remains and its worst hours go. What we have seen consistently is that the projects that work are the ones where the team helped design the tool and were free to say it was not helping, and the ones that fail are the ones handed down to people who were never consulted.

Does our confidential material end up training somebody's model?

No. We use the enterprise arrangements where your inputs are contractually excluded from training, we document exactly who processes what, and where your policy or a client's contract demands it we run models entirely inside your own infrastructure. You get a written data-flow map you can hand straight to a security reviewer.

How do we stop it producing bland, identical text?

By building it on your own approved documents rather than a generic prompt, and by keeping the person's own material at the centre: the teacher's observations, the surveyor's notes, the bid team's angle on why you should win. A copilot given nothing specific produces something generic, and that is a design failure rather than a limit of the technology. We test for it with real reviewers, who are usually delighted to tell us the drafts sound like nobody.

How will we know it saved us anything?

We measure the boring things: drafting time before and after, how much of each draft gets edited, and how many people are still using it in month three. Adoption is the honest measure. A copilot that saves an hour and gets opened twice has saved nothing, and we would rather report that than a flattering number.

Which afternoon would your team like back?

Tell us the document your people dread writing. We will tell you whether a copilot would genuinely be faster than writing it from scratch, and whether it is worth building at all.

Start the conversation →

Explore more

The rest of AI & Automation

Assistants & chatbots Document intelligence Knowledge search Workflow automation Custom AI features ← All of AI