Standardize the core work before the next acquisition arrives.
To standardize processes across acquired companies, define how the core work should run, from quote and order to scheduling, delivery, and billing, and build that process once as the platform company’s system. Each new add-on then moves onto a known standard instead of bringing another set of spreadsheets and habits that headquarters must learn and reconcile.
The aim differs from replacing a single spreadsheet. The question is not how to automate one team’s workbook but what every location should do the same way, so the business can absorb acquisitions without adding a new variation each time. The system becomes the definition of how the platform operates, and the integration plan for each deal points at it.
Timing matters. Standardizing between acquisitions, while the platform is still small enough to change, is far easier than doing it after several add-ons have settled into their habits. Leadership should treat the standard as part of the buy-and-build thesis, with a sponsor accountable for it, rather than as an IT cleanup to schedule when things are quieter.
Spreadsheets that worked for one company break at the second or third acquisition.
A founder-led company can run well on spreadsheets because the people who built them are in the room. After an acquisition, the platform inherits a second set of workbooks with different columns, pricing logic, and naming. By the third deal, headquarters is merging files by hand, and nobody can say with confidence which version of a number is current.
The symptoms are familiar. Period-end reporting depends on each location sending a file in a different format. Customers who buy from two locations appear as different records. Pricing drifts because each site copies rates from a local sheet. Staff who move between locations have to relearn the paperwork, and managers cannot compare performance on equal terms.
Those problems grow with every add-on because each acquisition multiplies the combinations. Two companies on different spreadsheets create one set of mismatches to manage. Five create many. A shared system reverses the arithmetic: each new location adopts the same records and workflows, so reporting, pricing, and staffing get simpler as the platform grows rather than harder.
Define the standard process with the people who run the work.
Start with the workflows every location performs and that drive revenue or cost: taking an order or request, pricing it, scheduling the work, completing it, and invoicing. For each one, document the steps, roles, required information, and approvals. Compare how the platform and each acquired company do it today, and choose the approach that is clearest and easiest to control.
Involve operators from more than one company. A standard written only at headquarters tends to miss the exceptions that field teams handle routinely, and it will be quietly worked around. When site managers help choose the standard, they understand why it looks the way it does and can explain it to their teams.
Write down shared data definitions alongside the process: what a customer is, how locations and service lines are coded, which statuses a job moves through, and what counts as complete. These definitions let reporting compare sites fairly and make each future acquisition a matter of mapping into known categories rather than inventing new ones.
Build the standard once, then onboard each add-on with a repeatable plan.
Build the standard as the platform’s system of record for operations, whether that is a configured product, a custom internal tool, or a combination connected to accounting. Designing it for many locations from the start means locations, permissions, and reporting by site are part of the model, not features added later when the second acquisition exposes their absence.
Onboarding an add-on then follows a repeatable plan: inventory its current tools and data, map its customers, services, and prices into the standard definitions, migrate open work and recent history, train staff with the materials used for the last site, and run the old and new processes side by side until the numbers match.
Record what went wrong at each onboarding and fix it in the plan before the next one. Perhaps price lists needed more cleanup than expected, or a role was missing from the permissions. Each correction makes the next add-on smoother, and the platform builds a practiced integration capability that the fund can point to when it considers further deals.
Allow local variation deliberately, where the business actually differs.
Not every difference is a bad habit. Locations may face different regulations, labor rules, tax treatments, customer contracts, or service mixes. The standard should include configuration for these: settings by location, region-specific forms, or optional steps that apply only where needed. What it should not allow is a different process simply because a site has always worked that way.
Keep a short written list of approved variations with the reason for each, and review it when adding a location. Variations without a business reason tend to multiply until the standard exists only on paper. A small list of justified differences, handled in configuration, keeps one shared system while respecting the real conditions each site works under.
Baybloom builds platform systems and internal tools for multi-location operators working through this kind of standardization. Whichever route a company chooses, the pattern holds: agree on the standard with the people who do the work, build it once, onboard each acquisition with the same plan, and treat every exception as a decision rather than a default.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project