This professional services business was running on 12 different tools, a CRM, HubSpot, Airtable, Google Workspace, Slack, and email infrastructure among them, and none of them talked to each other. Someone was always the bridge: copying a new contact from one system into another, updating a status by hand, checking two places to make sure a number matched. No single one of those tasks took long. Thirty seconds here, two minutes there. But spread across the team and the week, it added up to 48 hours, a full-time job’s worth of labor, producing nothing anyone could actually use.
Why nobody had caught it
That is the part worth sitting with. No single touchpoint was ever big enough to justify fixing on its own. You do not hire someone to spend thirty seconds on a task, and you do not build a business case around two minutes of copy-paste. The arithmetic only becomes visible once you add every instance of it up across the whole week, and the labor was scattered across departments, a sales rep here, a marketing coordinator there, an operations manager somewhere else, so no single person could see that the total reached one full-time equivalent. The team had tried smaller fixes before: a few spreadsheet formulas, some scheduled manual exports, one narrow integration set up years earlier with no monitoring attached, so its failures went unnoticed until someone spotted wrong numbers downstream. None of that reduced the 48 hours. It just moved the bottleneck to a different desk.
Mapping before building
Before a single workflow was built, we catalogued every system in the stack: what data originated there, where it needed to land, how often the transfer had to happen, and what actually went wrong when it did not arrive on time. That mapping produced the 180 touchpoints, not an estimate, a documented inventory. Each one was then tagged along two lines: what kind of data it moved (a contact record, a campaign result, an invoice status, a calendar event, a form submission) and how bad it was when it failed. Some failures were cosmetic, a stale field in a dashboard nobody checked in real time. Others were operational, a missed invoice update that held up a client deliverable, or a lead that fell out of follow-up because the CRM never got the signal from HubSpot in time. That distinction mattered, because building every one of the 180 touchpoints to the same standard would have been wasted effort. The categorization is what made the scope of the actual build defensible.
16 workflows, built in the order that mattered
From that map, we scoped and sequenced 16 automated workflows. The order was not arbitrary: the contact data sync between HubSpot and the CRM went first, because eight of the other workflows depended on that data being current before they could run correctly. Get the foundation wrong and everything built on top of it inherits the problem.
Every workflow carried its own error handling as a requirement from day one, not something added once things were already running. Any path with a real business consequence got a failure route: a log entry, an alert to the right channel, and a documented way to recover. That is the detail that separates real operations infrastructure from a pile of scripts that happen to be working today. It is also the only reason the uptime number below is something we can actually measure, without monitoring built in from the start, nobody would know it.
The build itself ran six weeks. The final week was set aside entirely for handoff: documentation, walkthrough sessions with the team, and confirmation that everyone understood what each workflow did, where its logs lived, and what an alert actually meant. The dependency map from the discovery phase did not get thrown away once the build was done. It became a standing reference the operations team still uses today when they are deciding whether a new tool can be safely added to the stack.
What changed
All 180 touchpoints were gone within the first full week the system ran, not reduced, gone. The tasks that used to consume that time do not exist anymore. The infrastructure has held 99.7% uptime since deployment, a number that reflects the monitoring built into it rather than luck: when something does fail, the system detects it, logs it, and alerts the team, so recovery is measured in minutes instead of however long it takes someone to notice a number looks wrong.
Building the same capability as custom software, scoped engineering, integrations written from scratch, a QA cycle, deployment, ongoing maintenance, would have run to roughly $180K. This delivered the same outcome for a fraction of that, and the investment was recovered in 2.3 months. Every month since month three has been a net gain. The 48 hours a week the team used to spend moving data by hand now goes to work the business actually cares about, and the 12 systems no longer need a human standing between them to stay in sync.
If your team is the glue holding several tools together by hand, our work connecting business tools is built to take that job off their plate.