Diligence on a services business follows the work, not the software list.
Technology due diligence for a services or multi-location business should answer a practical question: can the company schedule, perform, quote, and bill its work reliably on the systems it has, and what breaks as it grows? The answer rarely sits in a list of software subscriptions. It sits in how a job moves from the first call to the paid invoice, and in how many hands and spreadsheets it passes through.
A useful review covers five areas. It maps the systems the business actually runs on, looks for the red flags common to services companies, tests what management says against what staff do, checks access and contracts, and converts the findings into the first plan after closing. Each area should produce findings the deal team can weigh alongside commercial and financial diligence, not a technical appendix.
Depth should follow the thesis. When technology is the product, code quality and engineering practice need close review. In a services business, the product is the work that crews and office staff deliver, so the review centers on operating systems, data quality, and dependence on individuals. That focus matters most when the plan calls for new locations or add-on acquisitions that will run on the same systems.
Map the systems the business really runs on.
Start with the core workflow: how requests arrive, how jobs are scheduled and dispatched, how quotes and estimates are built, how technicians record the work, and how invoices and collections happen. Name the system used at each step. In many services companies that includes a field service or scheduling product, an accounting package, a CRM that may or may not be current, and several shared spreadsheets.
Look for the systems nobody lists. Pricing often lives in a spreadsheet one manager maintains. Customer lists sit in a founder’s personal email or phone. Payroll, supplier portals, the website, and the domain may be registered to a personal account rather than the company. Each of these is a working part of the business, and each needs to be identified before the buyer depends on it.
For multi-location businesses, repeat the map for more than one site. Locations acquired over time often run different tools, different price lists, and different habits for the same job. Knowing where they diverge tells the buyer how much standardization the plan will need, and whether reporting across locations is produced by a system or assembled by hand each month.
Watch for the red flags specific to services businesses.
The most common red flag is a single person who knows how a system works. It may be an office manager who built the scheduling setup, a contractor who maintains a custom application, or a founder who holds every administrator login. If that person left the week after closing, could the business still dispatch crews, send invoices, and run payroll? The answer shapes the transition plan.
Pricing held in a spreadsheet is the second. When quotes depend on a workbook with hidden formulas and manual cost updates, margin depends on whoever edits it. Ask how prices are set, who can change them, how discounts are approved, and whether anyone can see the margin on a job before it is quoted. Weak answers point to both a risk and a clear value creation opportunity.
The third is a missing connection between field work and billing. When completed work is retyped from paper or photos into accounting, jobs go unbilled, invoices go out late, and reporting trails reality. Trace a handful of recent jobs from dispatch to payment, and note each manual step and delay. The gaps you find usually point to the first operational improvements after closing.
Ask management questions that test how the work actually happens.
Management presentations describe how the business should run. Interviews with a dispatcher, a controller, and a field supervisor show how it does run. Ask each to walk through an ordinary day and a bad one: a canceled job, a disputed invoice, a technician who calls in sick. The workarounds they describe are the most reliable map of where the systems fall short.
Here are useful questions to ask management. Which reports do you trust, and which do you rebuild by hand? Who can add or remove a user in each system? Where does pricing come from, and when was it last updated? What happens when two locations handle the same job differently? Which vendor or developer would you call if the scheduling system stopped working tomorrow?
End the interviews by covering access and contracts. Confirm that the company, not an individual, holds administrative access to its accounting, scheduling, email, domain, and payment systems, and list any accounts that need to move before or at closing. Have counsel review software licenses, hosting agreements, and developer contracts for change-of-control terms and for what they say about custom code and records.
Turn the findings into the first 100 days.
Diligence findings are most useful when they are sorted by timing. Some belong in the purchase agreement or must be resolved before close, such as critical accounts held personally or unlicensed software. Others belong in the buyer’s 100-day plan: moving access into company control, confirming backups, and documenting the steps only one person knows. The remainder feeds the longer value creation roadmap.
For each significant finding, write the business risk in plain terms, the recommended response, and a rough sense of effort. A pricing spreadsheet becomes a pricing discipline initiative. A gap between field and billing becomes an integration project. Dependence on one person becomes a documentation and access task. That format lets the operating partner and management agree on priorities without translating a technical report.
When the plan includes add-on acquisitions or new locations, the same review becomes the baseline for integrating them, because the platform’s systems set the standard the next company will move onto. Baybloom Software helps portfolio company leaders turn assessments like this into integration and operational software work. Whoever does the work, the aim is the same: findings that change decisions, not a report that stays in the data room.
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