3x volume, same team

Over a single peak season, transactions on a national online marketplace tripled. We built that marketplace's operating system and we still run it, so we watched the problem arrive from the inside.

This is the first of our case pages. Each one starts with a line from our one-pager and explains how we got there.

The volume problem

When transactions grow, the work around them grows too. More customers ask where their order is. More merchants ask about payouts. Refunds pile up, and so do the numbers someone has to pull together for Monday's meeting. In most businesses that work grows in step with volume, and the usual answer is to hire.

At three times the volume, a team of about twelve people would have needed six to eight more to keep up. Before that plan was even written, the support queue showed the strain: replies started to slip on the busiest days.

When we looked at where the hours went, most of them went on sorting. Someone reads a message and works out what kind it is. They find the order and write the obvious reply. Only a small share of messages needs a person to think about it.

The volume tripled. The decisions didn't. That gap is the case for an AI layer, and it's where we started.

What we built

What we built is an operating layer that today connects 16 systems and runs about 100 automated jobs. In plain words, these are the parts that carry the volume.

Support triage. We built it and ran it in production. It read each incoming customer and merchant message, worked out what kind it was, pulled up the order and the history, and drafted a reply. A person read the draft and sent it. The AI never sent a reply to a customer by itself.

Lifecycle and win-back. Automated messages go to customers based on what they did or stopped doing: a first order, a basket left behind, a long gap since the last purchase. Nobody has to remember to send them. The marketing lead, working from a weekly AI-drafted plan, decides what goes out.

The founder cockpit. One live view of the business replaced the reports people used to build by hand. The numbers are already there on Monday morning. Someone reads them instead of compiling them.

A nightly AI council. Every night, seven AI advisors review the business and write proposals. A manager accepts or rejects each one. We haven't yet tracked accepted proposals as wins, so we don't claim results for the council. We describe what it does and leave it there.

The first piece to go live was support triage. It went from spec to live in under 7 days with one junior developer, for under $10k. The rest was added piece by piece on top of it.

What stays human

Every customer reply was sent by a person. Every council proposal is decided by a manager. Refunds, partner payouts and deal pricing also stay with people. When the layer meets something it doesn't recognise, it hands it to a person instead of guessing. Every edge case reaches a human.

This is a design choice. A layer that sends on its own leaves no record of who approved what. A layer where a named person approves each send leaves a full audit trail, and it is the only kind a team will trust at three times the volume.

What it replaced and what it costs to run

The main thing it replaced was the hiring plan. The team that handled the old volume handles three times as much, because the sorting no longer lands on them.

The build cost is the easy part to state. The first deployment came in under $10k. The running cost is the number owners should ask about, and we split it into three lines: model costs, infrastructure, and the time a person spends reviewing drafts.

The review time is the line most vendors leave out. It's also the one that makes the system trustworthy. If you take it out, you save a few hours and end up with a layer nobody relies on.

What moved

Transaction volume tripled and the team didn't grow. That's the result we stand behind, and it's the one on our one-pager.

We'd rather publish one verified number than five estimates. When we can put a second number on this page, we'll add it with the date it was measured.

What we'd do the same, and what we'd change

The same. We'd start with one agent on one queue and get it live inside a week, before planning anything bigger. A first deployment that ships in days teaches more than a plan that takes months. We'd keep a person on every send from day one, because adding approval later is harder than starting with it. And we'd put a manager's yes or no on anything an AI proposes, as we did with the council.

Differently. We'd track outcomes from the first day. Today we can say what the council proposes and what a manager accepted. We can't yet say what those decisions earned, and that's the weakest part of this case page. A new deployment should write down the number it has to move before it starts, then measure that number every week. We'd also cap what the AI advisors propose: they wrote more proposals than a manager could read, and the good ones got buried.

Where this applies

The same pattern shows up well beyond marketplaces. Any business where volume grows faster than headcount has the same split: a large share of sorting work and a small share of decisions. Clinics with a busy reception desk, letting agencies in peak season, distributors taking repeat orders on WhatsApp and agencies handling client requests all look like this from the inside. The first question is always the same: which queue grows fastest when the business does?