Seven departments is not the
same tool bought seven timesOne foundation — and new work just needs an Agent configured for it
Departments
Finance · People · Eng · Sales · E-com · Design · Stores
Delivery includes
Prompt library + time alongside
Adding a role
Configure an Agent for it
Pricing
Scoped by department
Where this stalls
The pilot worked, and then it stopped moving
Each department buys its own
Finance bought receipt scanning, people bought CV screening, e-commerce runs somebody else's support bot. Each is fine alone. Together they are seven sets of numbers that don't reconcile and seven per-seat bills — and the handover between them, the expensive part, belongs to nobody.
The pilot doesn't travel
One department succeeds and the second doesn't accept it: different data, different rules, different people. So every department is negotiated from scratch, and by the third the budget's patience is gone.
Engineering is booked until next year
A business team thinks of something that would save half a day, and it joins the same queue as everything else. By the time it's built, the way that work is done has changed. The bottleneck isn't capacity, it's that every small thing shares one queue.
All three point at the same thing: what's missing isn't a tool for one department, it's a layer every department shares and the business itself can build on.
Seven departments
What each one hands over, and what it keeps
Finance
- Invoices, receipts and statements extracted into tables
- Two sets of records reconciled automatically; only the lines that don't match reach a person
- Expense pre-checks: over-policy, missing receipt, duplicate claim, flagged on the spot
- Ageing and collection reminders by customer tier
- Month-end aggregation and a first draft of the reports
Stays with people: Payment and credit approvals, tax treatment, and deciding whether a discrepancy is a typo or something real.
People
- CV screening and structuring, ranked against the role
- Interview scheduling and candidate status kept in sync
- Joiner and leaver checklists dispatched, each department receiving only its own line
- Attendance and leave anomalies surfaced
- Policy questions: leave, expenses, contributions
Stays with people: Hiring, pay bands, performance, the difficult conversations — and every exception involving a person.
Engineering
- Requests and field feedback condensed into tickets: classified, de-duplicated, linked to a module
- Interface and configuration docs updated alongside the code
- First drafts of code and config, test cases, migration scripts
- Incident logs clustered, with similar past cases and their fixes surfaced
- Release notes and changelogs drafted
Stays with people: Architecture, technology choices, what ships first, and calling an incident. Review time doesn't shrink by a minute.
Sales
- Leads de-duplicated, scored and assigned
- Customer background assembled into a single page
- Personalised first contact rather than a broadcast template
- Follow-up cadence, escalated to a manager when it slips
- Quotes and contract documents drafted
Stays with people: The negotiation, the concession, the relationship — and the version of the quote that actually goes out.
E-commerce
- Product launch pipeline: copy → imagery → listing, with humans only on final review
- Content and terminology kept in sync across languages
- First-response support, escalating what it can't answer
- Order anomalies and storefront health flagged automatically
- Storefront and ad data collected into one board
Stays with people: Pricing, promotions, channel strategy, and the complaints that need a concession.
Design and production
- Product imagery re-rendered at volume: background, scene, consistent lighting
- Hero, detail and social sizes exported in one pass
- Scene renders and short-form video source material at volume
- Style held to the brand standard so a batch doesn't drift
- Assets filed and searchable by attribute instead of by folder
Stays with people: Setting the visual standard, selecting from each batch, and physical photography.
Store management
- Daily trading summaries with anomalies flagged: footfall, conversion, returns
- Walk-in records structured, follow-up assigned to a named person
- Sample and stock count lists, inter-store transfer requests routed
- Inspection photos and remediation items filed, overdue items chased
- Product knowledge and talk tracks staff can ask for, answers with sources
Stays with people: Serving the customer in front of them, rotas, merchandising decisions, complaints on the floor.
You don't need all seven. Most engagements start with one or two — the foundation is built once, so department two is noticeably lighter— and which department is third gets decided by the first one's run log, not now.
What makes this line different
New work appears — give it an Agent
Talk through what the role does each day
No form to fill in — plain words are enough: when it starts, what it needs to look at, the rules it follows, who receives the result, and which step needs a person. If that comes out smoothly, the Agent stands up. If it doesn't, that usually means the work itself hasn't settled yet, which is worth a conversation rather than a rush to automate.
Configure it on the platform
Trigger, data sources, rules, outputs and the human checkpoint, each picked in the interface — no code. The business data was connected at delivery, so a new Agent reuses the same connections and your own people can set it up.
Let it run alongside for a while
A newly configured Agent produces suggestions and touches nothing real by default. Give it a few days, see how sound its judgement is and what it hasn't accounted for, then open up write access. That default is deliberate — look first, let go after. It's easier on everyone.
Ship it, and keep the record
Who configured it, when, how many revisions, what each run did — all in the log. If an Agent's judgement is off you can trace it and pause it while it's adjusted. Knowing where you stand matters more than configuring one quickly.
What you'll configure yourself, and what's worth a look together
Straightforward to configure yourself
Work with a clear trigger, rules that can be described, and a clear output — looking up, comparing, organising, drafting, reminding, routing by rule. In most departments that is what the day is actually made of, and setting one up usually takes an hour or two.
Worth looking at together
Connecting an external system we haven't connected before, or a capability the platform doesn't have yet. Not that it can't be done — it simply sits outside what configuration covers, so we work out the least expensive way to do it, with scope and pricing agreed before anything starts.
And one default we'd suggest leaving on: a newly configured Agent gives suggestions and writes nothing real until its judgement has settled. Look first, let go after — when the people using it know where they stand, this actually spreads.
Prompt work
You get the output, and the way to adjust it
A prompt library, by role
Organised by department and by role: where each one is used, what it needs to be given, what the output looks like, and when not to use it. Delivered into your own repository alongside the source.
What's taught is how to edit, not what to memorise
We want your people to see why a line is written the way it is — which part is the role, which part is the rule, which part shouldn't be touched. Once that's clear, day-to-day adjustments happen on their own; where something is genuinely uncertain, we look at it together.
We stay alongside for a while — remotely is enough
One session per department, using the work those people actually had that day — written, run and adjusted until it's usable. A shared screen covers it; nobody has to arrange travel for this. Where the work involves a warehouse or a shop floor we can come in person. After that first round we stay with it for a while, and step back once each department is running on its own.
A convention they can maintain
Naming, versions, who may edit, who reviews. With that layer in place a prompt still makes sense six months later; without it they tend to drift — the slow problem we see most often.
This can be priced separately or folded into the project. Scope, number of sessions and how long we stay alongside are settled during the diagnostic — one session per department, small groups, because every session writes against real work. A shared screen covers all of it; where the work involves a warehouse or a shop floor we can come in person. After that first round we stay with it a while longer, and step back once each department is genuinely running on its own.
Stated first
What this line does not include
Replacing your existing systems ERP, approvals, people and warehouse systems stay the owners of their data; this sits on top.
Writing your policies or processes The rules are yours. Where a department's process still changes weekly, we'll say leave it alone.
Hosting it for you It runs on your own servers, with the source and the data in your hands. When you want us to help, you grant access and close it again afterwards.
Promising headcount reduction This hands over actions, not people. We also advise against writing a headcount target into the project.
Legal or compliance review What goes into the knowledge base, and anything published, is your counsel's call.
24/7 cover or an SLA tier Not part of standard delivery. Scope and pricing for cover are discussed separately during the diagnostic.
What you get
The delivery list
Working department Agents
Producing from the day they land, not a half-built thing waiting on debugging. The first department doesn't wait for the rest.
One knowledge base and permission model
Policies, talk tracks, product material and business data collected into one place: answers cite sources, permissions follow the org chart. It's the foundation of this line, included in delivery rather than priced apart.
The platform and all source
We wrote the platform layer, and the source, schema and documentation go into your repository. The foundation is standard tooling you can hire for.
Prompt library + time alongside
A library per department, a session with each of them, and the stretch afterwards — we step back once each department is running on its own.
Run records and an ops manual
Every trigger and every human confirmation logged, queryable and exportable; the manual is written from what we got wrong.
On pricing: scoped by department, with no list price — the same “finance piece” is three times the work when the data can only be reached by export. The diagnostic ends with a deployment list built around your situation: which department first, how many systems to connect, and which tier each falls in.
Questions
What the person pushing this usually asks
Seven departments — isn't that a lot to take on at once?+
It is, which is why we don't suggest it and rarely see it done. It usually starts with one department — the one where the volume is highest and a mistake is reversible, most often reconciliation in finance or product launches in e-commerce. Once that one is running you have two useful things: a real log, and colleagues willing to vouch for it. The second department goes far more easily on those two than on a proposal document. The foundation is built once, so later departments are lighter. How much lighter is something the first department's log will tell you — we'd rather not put a number on it now.
We already have an ERP, an approvals tool and a people system. Will this clash with them?+
No — it sits on top: reads from them, writes results back, and takes over the stretch in between that a person was carrying by hand. Those systems stay the owners of their data and we don't touch that. Staff don't get another place to log into either; when a decision is needed it reaches them in the tool they already have open. The one thing to look at properly beforehand is interfaces — which systems expose one and which can only be reached by file export. That gets checked item by item during the diagnostic, before anything is quoted.
Will anyone actually configure these role Agents?+
That's the usual ending for this kind of platform, so we treat it as part of delivery rather than handing over an interface and calling it done. First, a newly configured Agent gives suggestions and touches nothing real, so trying costs nothing and people will actually try. Second, at delivery we sit with your people and configure two or three real ones, using work from their own department. Somebody who has configured one rarely needs teaching again. And it doesn't stop there: the day-to-day is yours to do, and anything you're unsure about, we'll look at it with you.
If we want to add something later, does that mean a new project every time?+
Not for the everyday things. Configuring a role Agent, changing a rule, adjusting wording, adding to the knowledge base — those are yours to do, and we'd rather they were: if every small addition waits on a queue, half the point of this is gone. What we would sit down about is the other kind — connecting an external system we haven't connected before, or a capability the platform doesn't have yet. We work out the least expensive way to do it, with scope and pricing agreed before anything starts, rather than after you run into it.
Can't you just send a document for the prompt work?+
You get the document either way, but on its own it only goes so far — we've tried. Where business staff get stuck is rarely “I don't understand the template”; it's “how do I write the thing in front of me as one of these”. So each session uses work those people actually had that day: written, run and adjusted until it's usable, together. A shared screen covers it — nobody has to arrange travel. Once somebody has turned their own three-times-a-day task into a working prompt, the rest follows. After that first round we stay with it for a while and step back once each department is running on its own — this is arranged as time alongside you, not a session we deliver and leave.
Does data leave our network?+
The system runs on your own servers or your own cloud account. Business data, the knowledge base and the run records all stay inside your boundary and pass through none of our facilities. The model layer is a choice: an external API, or an open model deployed on hardware you control — with the latter, inference stays on your own servers too. Where compliance requires it, that's the route; switching is mostly configuration work, but not a single switch: the same test set gets re-run to confirm quality holds, and prompts usually need another pass. Finance and people are the two departments that raise this most often, so we settle it during the diagnostic rather than close to launch.
Next