Seven departments,
one foundationA retailer running physical stores alongside its own storefront
Departments
Seven
Where it runs
The client's own servers
New roles
Built by them, on the platform
Figures on this page
None — see below
Before
Not an absence of systems — facts breaking between departments
Head office waits for the facts
Every store kept its own records and filed its own summary, so head office saw a version that had been through somebody's hands a day or a week later. Who adjusted what along the way was not recoverable afterwards.
Answering “which store had the most returns yesterday” started with asking someone to build a sheet
The same job, done again in seven places
One order moved from greeting to sale to invoice to accounts to fulfilment to after-sales through screenshots and group chats. Every handover meant somebody retyping it, and every mistake was found by the next department along.
Entering it took longer than doing it
Online and in-store were two sets of books
Storefront orders, products and content lived in one back office; footfall, samples and transfers lived in another, or in nothing at all. What one customer had browsed online and tried in a store never met.
The most valuable signal in the business was never connected
Small improvements couldn't get scheduled
Business teams could name several half-day savings every month, but each one joined the same development queue. By the time one was built, the way that work was done had often changed.
Not a capacity problem — every small thing shared one queue
Seven departments
What each one actually handed over
Finance
- Purchase orders, invoices and statements extracted into tables instead of retyped
- Store takings reconciled against system orders, with only the mismatches pushed to a person
- Expense pre-checks: over-policy, missing receipt, duplicate claim, flagged on the spot
- Ageing and collection reminders sent by customer tier
- Month-end aggregation and a first draft of the reports
Stays with people: Payment and credit approvals, what a discrepancy means, tax treatment — none of it moved.
People
- Inbound CVs screened and structured against each store role's requirements
- Interview scheduling and candidate status kept in sync, so nobody is dropped
- Joiner and leaver checklists dispatched, each department receiving only its own line
- Attendance and rota anomalies across stores surfaced
- Policy questions: leave, expenses, contributions, store allowances
Stays with people: Hiring, pay bands, performance, conversations, and every exception involving a person.
Engineering
- Business requests and store feedback condensed into tickets: classified, de-duplicated, linked to a module
- Interface and configuration docs updated alongside the code
- First drafts of code, test cases and migration scripts
- Production logs clustered, with similar past incidents and their fixes surfaced
- Release notes and changelogs drafted
Stays with people: Architecture and technology choices, what ships first, calling an incident. Review time unchanged.
Sales
- Leads de-duplicated, scored and assigned to a person
- Customer background and history assembled into a single page
- Follow-up reminders, escalated to a manager when they slip
- Quotes and contract documents drafted
- Won and lost reasons captured and grouped
Stays with people: The negotiation, the concession, the relationship, and 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 campaign data collected into one board
Stays with people: Pricing, promotions, channel strategy, and 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, physical photography.
Store management
- Daily trading summaries with anomalies flagged: footfall, conversion, returns
- Walk-in records structured, with 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.
Why this page has no figures
Not an omission — publishing one would drag the others down
They know it got faster; there's no measure both sides would sign
Internal roles have no natural counter the way order volume does. “Expenses went from next week to same day” is something the client says themselves — but it isn't a figure a third party can check, and converting it to a percentage is the step where it becomes an estimate.
So we publish none
The figures on our storefront case each carry the record they came from, which is exactly why that page is worth reading. Invent one here and the checkable ones lose their value alongside it. That trade isn't worth making.
The percentage isn't what you should be asking anyway
Ask this instead: how many times a week does this repeat, what does one mistake cost, and who is waiting on whom. You can answer all three from your own data, and you'll know more than any case study figure would tell you.
Three rules govern how we write these: no brand name and no industry, no figure without a checkable source, no back-office screenshots. This page is all three at once.
After delivery
They're the ones adding to it now
A new role, and they configure its Agent
The platform is theirs. When a role opens and needs help, the trigger, rules, output and human checkpoint get picked in the interface. They do the day-to-day faster themselves; anything they're unsure about, we look at together.
A new one runs alongside first
It gives suggestions and touches nothing real until its judgement has settled. Look first, let go after — the people using it know where they stand, which is why it spread.
The prompts are theirs to edit
Delivered as a library per department, written alongside them on site, with a stretch of time afterwards. Wording and rule changes are now made by the departments themselves, the same day.
It sits on their own servers
Installed on the client's own hardware from day one, with the source and the data in their hands. When they want us to help they grant access and close it again afterwards — so it's always clear who did what, and when.
This is the third system built on a client's own servers. As with the other two: the source goes into their repository and their own people run it day to day; when they want us to help, access is granted and closed again afterwards.
When this doesn't apply
The boundary, stated
Departments whose process still changes weekly Automating unsettled rules just produces the mess faster. We'll say leave it alone.
Anyone wanting to start with just one department Perfectly fine — it just sits closer to a single-module engagement, and scoping it as this line wouldn't be worth it. We'll say so.
Anyone expecting it to replace an ERP or people system It sits on top of them, reads from them and writes back. It doesn't replace them.
Anyone whose goal is headcount This hands over actions, not people. Used as a redundancy tool it gets quietly resisted into failure.
Questions
What you're likely to ask
Were all seven departments done at once?+
No — and doing it that way is how this fails. The first one is whichever has the highest volume and the most reversible mistakes; the rest follow once it works. That order isn't a technical preference, it's about momentum: the run log from the first department is the only material that convinces the second, and it works better than any proposal document. The foundation is built once, so later departments are lighter. How much lighter we won't put a number on — it depends on the state of that department's data.
Do people in the stores actually use it?+
That's the largest delivery risk in this kind of project, far larger than anything technical. Two things are non-negotiable: the entry point sits in the tool they already use — no app, no new password — and what ships first is whatever saves them time (asking about a product, generating a count list), with reporting and oversight coming later. We've seen the result of the opposite order: however good the system, the floor treats it as something built to measure them, and quietly stops using it.
Isn't the listing and imagery part the same as your other cases?+
The method is the same, which is why it isn't explained twice here — in this client's flow it's two lines inside the e-commerce card. For how that part actually works and where its limits are, the visual pipeline service and the content pipeline case both go into far more detail than this page would.
After delivery, do they come back to you to add things?+
Not for the everyday things: the platform and the source are theirs, and a new role Agent is configured in the interface — trigger, rules, output, checkpoint. What we would sit down about is the other kind — connecting an external system nobody has connected before, or a capability the platform doesn't have yet. Scope and pricing for that are agreed before anything starts, rather than raised afterwards.
Next