Industries
Domain knowledge is not a nice-to-have in this work — it's what lets us tell you in week one that three of your four ideas won't pay off. If your sector isn't listed, we'll say honestly whether our experience transfers.
Cut-off times, customs windows and settlement runs do not wait for office hours. The systems we build are designed to degrade back to your manual process safely — not to need rescuing at night.
SECTOR 01
Sellers running 3–12 marketplaces
Order exceptions multiply with every market you add. Listing rules, address formats and returns policies all differ, and the work lands on one team who become the bottleneck.
Exception triage · Catalogue localisation · Payout reconciliation
SECTOR 02
3PLs, forwarders, last-mile operators
Documents arrive as scans in whatever format the shipper felt like. Status queries from clients repeat endlessly, and the answer is always somewhere in a system nobody wants to open.
Document intake · Status queries · Exception alerts
SECTOR 03
B2B catalogues, quoting, tenders
Quotes need the current price list, the customer's contract terms and stock reality at once. Getting that wrong costs margin; getting it slowly costs the order.
Quote drafting · Contract lookup · Tender response
SECTOR 04
DTC operations and customer care
Support volume spikes with every campaign, and most of it is the same six questions. The interesting cases get buried under the routine ones.
First-line support · Review triage · Content localisation
SECTOR 05
Supplier comms, specs and QC records
Specifications live in drawings and PDFs, QC records in spreadsheets, and supplier correspondence in email. Answering one question means opening three systems.
Spec retrieval · Supplier email · QC document review
SECTOR 06
Reconciliation, claims, document review
High-volume matching work with a checkable right answer — the closest thing to an ideal automation candidate, provided the guardrails are real.
Payout matching · Claim intake · Statement review
Fit test
Sector matters less than shape. These four questions predict success better than the industry label does.
01
Under roughly fifty instances a week, the engineering rarely pays back. A person doing it occasionally is usually the right answer, and we'll say so.
02
If two senior people would decide differently, there is nothing to measure against and no bar to clear. Judgement work stays with people.
03
A wrong draft is reviewed away. A wrong payment is not. We automate where mistakes are cheap and reversible, and route the rest.
04
If the information only exists in someone's head or a system with no API, the first project is data work — and we'll price it as such.
Different goods, different regulators, the same underlying job: a high-volume decision with a checkable right answer that a person is currently making by opening three systems.
Where to start
Almost nobody should start with their hardest problem. This is the project we most often recommend first in each sector — chosen because it is verifiable, bounded, and pays back inside a year.
| First project we suggest | Why this one | Typical payback | |
|---|---|---|---|
| Marketplace sellers | Order exception triage across platforms | Highest volume, recognisable shapes, and every case already has a recorded outcome to test against | 4–7 months |
| Wholesale & distribution | Supplier email and PO confirmation parsing | The data is already arriving; nobody has to change how they work for it to start paying | 3–6 months |
| Third-party logistics | Freight document intake into the TMS | Structured output, checkable against the booking, and clerks feel the relief in week one | 5–8 months |
| Beauty & personal care | Claim and ingredient compliance sweeps | A single blocked listing costs more than the build; the rules are written down and testable | 2–5 months |
| Food & grocery | Short-shelf-life markdown suggestions | Daily decisions, immediate feedback loop, and waste is measured already | 3–6 months |
| Electronics & parts | Compatibility and cross-reference answers | The knowledge exists in datasheets nobody can search; wrong answers are caught by the customer's own fitment | 4–8 months |
Payback ranges assume the twenty-hours-a-week threshold is met. Below that, none of these are worth building and we will say so before you spend anything.
Constraints we design around
These are not compliance certifications and we are not lawyers. They are the constraints that have actually changed a design decision on a real project.
PDPA obligations mean customer records get field-level retention windows and deletion has to propagate to the retrieval index, not just the database. We build the deletion path in the first sprint, not as an afterthought when someone asks.
If any market touches the EU, GDPR applies to the whole pipeline. That usually means regional inference, a data-processing record that names every sub-processor, and no training on customer content under any circumstance.
Each platform has its own limits on automated messaging, response templates and listing claims. An agent that is technically excellent and violates a seller policy is a suspension waiting to happen, so platform rules are part of the evaluation set.
Health, cosmetic and food claims are regulated differently in every market we work in. Generated copy is checked against a per-market restricted-terms list before it can reach a listing queue, and the list is maintained with the client.
HS codes, country-of-origin statements and declared values carry legal weight. Anything in this category is drafted, never submitted autonomously, regardless of measured accuracy. That is a policy, not a threshold.
Agents propose refunds; they do not move money. Financial authority stays with a person or an existing rules engine, and the approval is recorded against the named human who gave it.
Company size
The technical work is similar across sizes. What differs is who decides, how long approval takes, and what "done" has to look like.
A
Founder-led · fastest
The person who decides is the person who does the work, so scoping is quick and honest. Risk is concentration: one process, one dependency. We keep builds small enough that the runbook genuinely lets you take over, because you may have to.
B
Our most common client
Big enough that the volume justifies the build, small enough that a department head can approve it. There is usually one internal technical person; we work alongside them rather than around them, and they own the system afterwards.
C
Procurement enters the room
Security review, vendor onboarding and a longer approval chain. We plan for six to eight weeks before kickoff and provide the security pack up front. The build itself is not slower; getting permission to start is.
D
Sometimes not us
At this size the constraint is usually organisational rather than technical, and a firm with change-management muscle may serve you better. Where we do fit is as a specialist team on one bounded system, working under someone else's programme.
Poor fit
Said plainly, because finding out in month three is expensive for both of us.
Regulated medical judgement needs a firm with clinical governance and the certifications that go with it. We do not have them and would not pretend the operational parallels are close enough.
Model risk management, adverse-action explainability and financial regulation form a specialism of their own. Adjacent back-office work in a financial firm, yes. The lending decision itself, no.
If AI is the product you sell rather than the thing that runs your operations, you want an in-house team building durable capability, not an outside firm. We will say so and it costs you nothing to hear it.
We are a small team in one time zone. Systems are built to degrade to the manual process safely rather than to be rescued at 3am, and if your process cannot tolerate that, we are the wrong size of firm.
The long run
Almost every proposal you will read stops at go-live. This is the part that decides whether the thing was worth building, and it looks the same across sectors.
M3
Month three or four
Something upstream changes — a supplier's format, a marketplace's category rules, a policy rewritten in place — and accuracy dips before anyone notices operationally. This is what the monitoring is for. On a healthy deployment it is caught by an alert, diagnosed in a day, and never reaches the queue.
M6
Month five to eight
The team asks for the agent to handle three adjacent tasks. Two are usually good ideas and one is the tail nobody should automate. We rescope rather than extend quietly, because a system that grows sideways without a new accuracy bar is how a good deployment turns bad.
M9
Month eight to twelve
Volume has grown and someone reads the invoice properly. This is usually where escalation-rate tuning, context trimming and a model change pay for themselves. On two deployments we have cut monthly run cost by more than half in this window without touching accuracy.
M12
The decision point
By now your team either wants the runbook or wants us to keep going. Both are normal endings and neither carries a penalty. We ask directly at month eleven rather than letting a retainer roll on out of inertia — a renewal that nobody consciously chose is not a good sign about the value.
The systems that survive year two are the ones where somebody internal owns the numbers. If nobody on your side reads the monthly report, that is the strongest predictor we know of a deployment quietly dying — stronger than accuracy, volume or budget.
Not sure?
You don't need to know whether AI is the right tool — that's the question the scoping week answers. Roughly a third of what we're asked about gets a no.