The method
A company has one constraint at a time.
At any given moment, one thing limits how much a company can sell and deliver. Not five things. One. Improve anything other than that one thing and the improvement is absorbed by the constraint: the extra leads queue, the extra capacity idles.
This is not our idea. It is the Theory of Constraints, and it has run factories for forty years. We apply it to the whole company — to its ability to win a customer and to serve one — and we use automation as the lever.
Every company has a demand side and a capacity side.
The demand side is everything that turns a stranger into a signed customer: marketing, sales, quoting.
The capacity side is everything that turns a signed customer into a delivered, paid and retained one: onboarding, delivery, support, renewal — and the HR, finance and data functions that hold it all up.
The constraint is always on one side or the other. The whole question is which.
Three questions find the constraint in most companies.
- Where is the queue? Inquiries waiting for a reply, or signed projects waiting to start?
- Where do the most expensive hours go? Are your best people quoting, delivering — or answering questions whose answer already exists somewhere in the company?
- What happens when you add? After a strong month in sales, does delivery strain? After a quiet week in delivery, does sales fill it?
The Constraint Audit asks these questions properly, with your numbers, across every department. The answer is usually clear within a fortnight — and usually not what the management team expected.
Automation here means three things. None of them is a chatbot bolted on.
- Workflows — things that should happen without a person pushing them: a project set up the moment a contract is signed, a status report assembled before anyone asks.
- Knowledge — answers that exist in your company but not where they are needed: the specification from a past project, the policy nobody can find, the customer's history at the moment they call.
- Decisions — routine judgments made consistently: which inquiry is worth a senior's time, which ticket is urgent, what a project of this shape usually costs.
People stay where judgment is the product. Everything around that judgment is what we remove.
One number tells you whether it is working.
Cost-to-serve: everything it costs to take one customer, project or order from signature to paid invoice, divided by how many you served.
We use this one number because it is honest about order. Add demand to a jammed capacity side and cost-to-serve rises — overtime, rework, churn. Add capacity to an empty demand side and it rises too — the same fixed costs spread over fewer customers. It only falls when the right side was automated first. That makes it the scoreboard for the whole method, not just for one project.
The constraint moves. That is the flywheel.
Remove a capacity constraint and demand becomes the constraint: you can now serve more customers than you are winning. Remove a demand constraint and capacity becomes the constraint: you are winning more than you can serve. Each system we build moves the constraint to the other side, and each turn leaves the company larger than the one before.
This is the mechanism by which every well-run company grows. Most do it by instinct, late, and by hiring. We do it deliberately, early, and mostly without.
Inside your stack. Inside your permissions.
- Systems are built into the tools you already run, not beside them.
- Access rights are inherited, not re-invented: a system can only see what the person using it could see.
- Data is processed where you require it, with a processor agreement in place before anything is connected.
- Every system ships with documentation and a handover session. Your team can own it; nothing depends on us staying.
- Fixed price per system, scoped from the audit.