Ask an owner how many tools the business runs and you'll usually get a number between eight and fifteen: a CRM, a scheduler, a proposal tool, invoicing, a forms tool for intake, something for projects, something for planning, an inbox that's really a database if you squint. Ask a second question, quietly, and the real answer comes out: who moves the customer's information from one of those tools to the next. It's never the software. It's the owner.
The job nobody put on the org chart
There's a plain term for this and it's worth saying out loud in a Monday meeting: glue work. Glue work is the unpaid, undocumented labor of taking a fact that already exists in one system and typing it into another system so the two agree with each other. The deposit that landed in the bank but hasn't been marked paid in the invoicing tool. The reschedule that happened by text but never made it into the calendar the technician actually uses. The proposal that got accepted verbally on-site and now has to be re-entered as a won deal, a new project, and a renewal date, in three different places, by one person, from memory.
Glue work doesn't show up on a scorecard because nobody designed it as a job. It accumulates because each tool was bought to solve one problem well, and each tool did solve that problem well, in isolation. The forms tool captures the lead beautifully. The scheduler books the appointment beautifully. Neither one knows the other exists. The owner is the only piece of infrastructure that has read access to all of it, so the owner becomes the join between the tables, the thing a database would normally do automatically, done instead by a tired person at 9pm cross-referencing three tabs.
Why "we've scaled" is the wrong read
The common story owners tell themselves is that this is just the cost of growth: more tools because more customers, more customers because the business is working. That's half right. The business did grow. But growth didn't cause the stitching, it just made the stitching more expensive to keep doing, and made it more visible when it failed. A missed handoff at three customers is an apology. A missed handoff at thirty customers is a lost renewal, and the owner doesn't find out until the customer mentions it on the way out the door.
The tell is this: if the owner went on holiday for two weeks with no laptop, would the business's tools keep agreeing with each other? In a stitched business, the answer is no, because the owner isn't running the business from the tools, the owner is running the tools from their own head, using the software as filing cabinets rather than as a system. We didn't scale. We just found a way to hide the bill for never building one system, and the bill's been sitting in the owner's calendar the whole time, disguised as busyness.
A worked case
Picture a small services business, the kind that does site visits and follow-up work. The owner's complaint, stated in the owner's own words, is "we keep losing track of who's paid and who hasn't, and I'm the one who has to check." The obvious fix, the one most advice reaches for first, is a better invoicing tool, or a reminder to check the bank feed more often.
The real diagnosis, once you follow the fact around the business, is different: the payment status lives correctly in the invoicing tool, the job status lives correctly in the scheduler, and the two never talk to each other. The owner is the only thing that reads both and reconciles them, which means the owner is, functionally, doing the job of a database relationship by hand, every week, without ever having been told that's the job.
What changed wasn't a new invoicing tool. It was making the customer record itself the thing both processes point to, so a payment and a job status became two views of one record rather than two separate facts that happen to describe the same customer. The owner stopped being the place where those two facts got compared against each other. What improved wasn't revenue, and it isn't a number worth inventing here. What improved is that the checking stopped being a task at all, because there was nothing left to reconcile.
Where consolidation is the wrong call
It would be tidy to say the answer is always "put everything in one system," but that's the simplified version, and it doesn't survive contact with a real operation. Specialist tools earn their place. Accounting software built for compliance shouldn't be replaced by a general system that does bookkeeping as an afterthought. A scheduling tool built for a specific trade's dispatch problem can be genuinely better at that one thing than a broader platform's version of it.
The argument isn't "fewer subscriptions." The argument is one customer record that every tool reads from and writes to, so the fact of who the customer is, what they bought, what they owe, and when they renew exists exactly once. Keep the specialist tool if it earns its place. Just make sure it's reading the same record as everything else, instead of holding its own private version of the customer that only the owner knows how to reconcile with the rest.
The test that actually tells you
Forget counting tools. Count handoffs. Walk one customer from first inquiry to renewal and count how many times a fact about that customer has to be manually re-entered, re-typed, or re-checked by a person rather than simply carried forward by the system itself. Each of those is a place where the owner, or whoever the owner has delegated the glue work to, is standing in for a connection that software should be making.
That number is the real measure of how far the business has to go, not the number of logins on the password manager. A business with three tools and twelve handoffs is more fragile than a business with ten tools and two handoffs. The tools were never the problem. The handoffs were always the job, and until now, nobody was paying the person doing it, including the owner.
The fix isn't heroic. It's structural. It's deciding, deliberately, which record is the one true record of the customer, and refusing to let any tool keep its own private copy of a fact that belongs somewhere else. Do that, and the owner gets to go on holiday. Don't, and the owner just keeps being the glue, quietly, for as long as the business exists.