Three tools, eleven spreadsheets, one platform.

The problem

The company had grown from 8 people to 30 in three years, and its tooling grew the way tooling always grows: one subscription at a time. By the time they called us, the operational picture looked like this:

• Onboarding lived in a project-management tool — a 40-step template cloned for each new client, with fields filled in by hand.
• Billing lived in a subscription-management tool that didn't know what the PM tool knew, so every contract change was entered twice.
• Support lived in a helpdesk where a dispatcher read every incoming ticket and decided who should handle it.

None of the three shared data. The glue was people: the operations lead spent roughly two days per new client shepherding the checklist, and the team maintained eleven spreadsheets to reconcile what the tools disagreed about. Billing errors — a provisioned service that never made it onto an invoice — were caught quarterly, if at all. An internal audit we ran in week one found ~$4,100/month in services being delivered but not billed.

The approach

The core design move: one system of record, three agents working on top of it. Instead of syncing three databases that disagree, we built a single PostgreSQL schema for clients, contracts, services, and tickets — then gave each operational workflow an agent that acts on that shared state.

1. Onboarding agent — takes a signed contract (PDF), extracts the service schedule, generates the provisioning plan from the firm's 40-step playbook, executes the automatable steps (accounts, licenses, monitoring, welcome sequences), and assigns the human steps with context attached. Nothing is marked done until verified — the agent checks that the license actually exists, not that a box was ticked.
2. Billing agent — watches the same state. When a service is provisioned, changed, or cancelled, the invoice line follows automatically. Month-end, it drafts invoices, reconciles against delivered services, and flags anomalies for the bookkeeper instead of letting them ship.
3. Support routing agent — reads each incoming ticket, pulls the client's environment and history from the shared record, classifies urgency and category, and routes to the right engineer with a briefing note. Ambiguous tickets go to a triage queue — the dispatcher role became an exception-handler role.

Agents act, an orchestrator supervises

Each agent runs on an event queue and writes back to the system of record — so every action is inspectable, replayable, and reversible. A thin orchestration layer enforces the rules the business actually cares about: no invoice goes out without a matching provisioned service; no onboarding step is skipped without a named human overriding it; every agent action above a spend threshold requires approval. Autonomy where it's cheap to be wrong, checkpoints where it isn't.

Stack notes

Next.js + TypeScript on Vercel for the dashboard and approval queues; PostgreSQL (Supabase) as the system of record; queue-backed workers for agent runs so long operations survive restarts. Ticket classification runs on a fast model with the client's service catalog in context; contract extraction and anomaly analysis on a frontier model. Stripe for payment execution — the billing agent drafts, Stripe charges, and the two are reconciled nightly.

The rollout

You don't rip out a company's billing system in one weekend. Each workflow moved independently, ran in parallel with the old tool until trust was earned, and only then was the subscription cancelled.

The results

Measured at 90 days after full cutover, against the company's own records from the prior two quarters:

The recovered billing leakage alone — services delivered but never invoiced — pays for the entire build in under 18 months, before counting the retired subscriptions or the operations lead's reclaimed two days per client.