They had three implementation partners. What they needed was an architect.
UFP Industries, a $6B building-products manufacturer, ran nine business units on seven disconnected systems: two Salesforce orgs, five HubSpot instances, and pipeline tracked in spreadsheets by three of them. Leadership could not produce a single company-wide number for pipeline or forecast, because there was no system in which one existed. Three implementation partners had already been hired. What the company was missing was not build capacity: it was someone to decide what should be built, and to say no to the rest. I ran a month of per-business-unit process discovery, eliminated 15-20% of the manual steps before designing anything, then architected the consolidation and directed the vendors through it. Around two million records were migrated. Quote cycles went from nine days to two. Company forecast accuracy reached 86%.
The problem
A $6 billion company could not tell you how much pipeline it had. Not because nobody was counting. Because nine business units were each counting differently, in seven different systems.
Two Salesforce orgs. Five HubSpot instances. Three business units tracking pipeline in spreadsheets. Every unit reported to leadership out of its own workbook, in its own format, on its own definition of a qualified opportunity. There was no company-wide forecast that could be called accurate or inaccurate, because there was no company-wide forecast at all. There was a stack of nine, and a person whose job it was to add them up.
The cost wasn't a broken system. It was nine separate versions of the truth, and a leadership team that had to choose between them every time it made a decision.
A quote took nine days. Generated and approved in the packaging business through about six rounds of revision, in a macro-driven Excel model, because every quote is a bespoke size and material, with no standard SKUs.
Discounting governed by nothing. The average discount was 12%, with no deal desk. Reps discounted, and the number was discovered later.
Leads waited in a queue nobody owned. A new lead waited roughly four days for a first response, and only 19% of leads ever became qualified.
Seven instances, duplicated and stale. Around two million contact and company records sat across seven instances, duplicated and inconsistent. Sales-to-delivery handoffs were manual, at a manufacturer where delivery is the product.
The diagnosis
They had already hired three implementation partners. Nobody had hired an architect.
A Salesforce partner builds what you specify. A HubSpot partner builds what you specify. A data-engineering consultancy builds what you specify. All three are good at their jobs. None of them will tell you what to specify, and crucially, none will tell you when the answer is “don't build that.” That was the gap I was there to fill. Implementation capacity was not the constraint. Judgment was.
Put an operator between the company and its vendors
This is the entire argument for the role. Three vendors will build exactly what they're told. None is paid to say the spec is wrong, or that the right answer is to build less. The person who decides what they build, and when to build nothing, has to be yours, not theirs.
Never migrate a broken process
Lift nine units' existing processes into one system and you get one system running nine broken processes, with better reporting on the breakage. So nothing was designed for the first month: every unit's journey was mapped end to end, and 15-20% of the steps (manual, repetitive, value-free) were removed first. The architecture was designed for the process that should exist.
The technical problem was never the hard part
Nine business unit leaders each have a rational reason why their process is different, and a few are right. Requirements-gathering across nine units is a negotiation before it's an analysis. Any consultant who arrives with the architecture already drawn has skipped the only part that determines whether it gets used.
What I built
One system, from seven
Two Salesforce orgs and five HubSpot instances consolidated into a single Salesforce (sales and support) and a single HubSpot (marketing), adopted across every go-to-market team. Around two million contact and company records cleaned, de-duplicated and migrated.
A quoting system for a business with no SKUs
A fully custom Salesforce CPQ for the packaging business, replacing the macro-Excel model: every quote a bespoke size and material. Deal-desk approval workflows were embedded directly into it, so discounting became a governed decision rather than a discovered fact.
Automated lead routing across the unified org
Replacing a process in which a lead's fate depended on which business unit's spreadsheet it happened to land in.
A single source of truth for the number
Pipeline, bookings and forecasting centralised in Salesforce Data Cloud, flowing into Databricks, with 30+ leadership dashboards in Domo covering pipeline, closed-won, win/loss, forecast, and territory, product and business-unit performance, all sliceable by unit and period.
Integration with the businesses that actually deliver
Salesforce wired into three ERPs (Microsoft Dynamics, NetSuite and Epicor) so closed deals flow to booking and fulfilment, and the active-customer list flows back into the CRM.
AI agents to find the revenue hiding between the business units
Account enrichment and cross-BU opportunity detection inside Salesforce (a construction account surfaced as a retail prospect, for instance), turning nine siloed books of business into cross-sell pipeline for the first time.
The outcome
Twelve-month engagement. Forecast accuracy measured in Q3 2025.
We had the implementation partners. What we didn't have was anyone who could stand between nine business unit leaders and three vendors and decide what actually got built. Shashank spent his first month telling us what not to do, which was not what we hired him for and was exactly what we needed. We came out of it with one system, one number, and quotes going out in two days instead of nine.
What this engagement didn't solve
One business unit never adopted it, and that's the most useful thing in this case study. Retail went to full daily use and hit 92% forecast accuracy, best in the company. The construction business units did not: adoption there ran at under two logins per employee per week. Same system, same training, same phased rollout.
The difference wasn't the software and it wasn't the users. It was that retail's leadership ran their business out of the system, and construction's leadership did not. If the person running a unit doesn't open the dashboard, nobody below them does either, and no amount of enablement substitutes for a leader who has decided the system is where the truth lives.
This also killed a piece of the build. Clari revenue intelligence went into the three construction units and never produced a result worth reporting, because it had nothing to read. A revenue intelligence tool in a unit that doesn't use the CRM is an expensive listening device pointed at a silent room.
I'd sequence it differently now. I treated adoption as the last phase: build it, then drive usage. It should have been the first: the month-one deliverable isn't an architecture, it's the business-unit leader's own operating cadence running inside the system, so everyone below them has to follow. Get that and the rollout is downhill; miss it and you'll build something excellent that a third of the company ignores.
Why this matters for you
This is your problem if:
You have grown by acquisition and now run more than one CRM, and nobody wants to be the one who says which survives
Each of your business units or regions reports a different number, and leadership picks between them
You are about to engage a systems integrator and aren't sure what to tell them to build
Your quotes take a week and your discounts are whatever the rep decided that day
You have rolled out a CRM before, and a meaningful part of the company simply never opened it
Your pipeline lives in spreadsheets, and everyone has agreed to stop mentioning it
If you're hiring implementation partners, hire the architect first
Your Salesforce partner, your HubSpot partner and your data consultancy will each build exactly what you ask for. Nobody in that room is paid to tell you that what you asked for is wrong, or that the right answer is to build less. That person has to be yours.
Never migrate a broken process
Map every journey, cut the steps that create nothing, and then design the system. Otherwise you'll spend a year and a great deal of money arriving at one system with all your old problems in it, plus better dashboards for observing them.
Adoption is a leadership behaviour, not a training deliverable
Whichever unit's leader runs their business out of the system will get a business that runs out of the system. The others will attend the training, nod, and go back to the spreadsheet. Fix the leader's cadence first and the rollout looks after itself.