BUILD AND OPERATE
We build automation for the processes that slow a portfolio company down: lead routing, quoting, scheduling, invoicing, records requests, document generation and reporting. Then we operate it. The company gets the output. We carry the technical load. This page explains how we scope, build, integrate and hand over, and why automation on top of an undefined process will fail every time.
Most automation engagements end with a handover document and a set of credentials. The consultant builds a workflow, trains a few people, and leaves. Inside a portfolio company with no dedicated engineering team, that handover is the moment the automation begins to decay. Nobody updates the integrations when the CRM changes. Nobody adjusts the routing rules when the sales process shifts. Within six months the automation is a ghost, half running, trusted by no one.
We take the opposite approach. We build the automation and then we operate it for as long as the holding period requires. Our team monitors the workflows, adjusts the rules, fixes the breakages and handles the exceptions that software alone cannot resolve. The company gets the benefit of automated processes without the burden of maintaining the machinery. When the exit comes, we hand over a running system with documentation, or we continue operating it under the new owner. The choice is the client's.
This model works because we are not a software vendor selling a platform licence. We are an operating services firm. We write code, configure tools, integrate systems and then sit beside the business running the result. The distinction matters. A platform you buy still needs someone to own it. We become that someone.
We automate discrete, repeatable processes that touch multiple systems or multiple people. Lead routing from a website form into a CRM, with assignment rules based on territory or product line. Quoting workflows that pull pricing from an ERP, apply approval rules and send a formatted document to the prospect. Scheduling that checks technician availability across a fragmented fleet and confirms appointments without a dispatcher working through a spreadsheet. Invoicing that pulls line items from a work order system, applies contract rates and sends the invoice with the correct attachments. Records requests that receive a customer email, parse the intent, retrieve the documents from a repository and reply. Document generation that assembles a contract, a statement of work or a compliance filing from a template and a set of inputs. Reporting that pulls data from three operational systems and produces a weekly pack the operating partner actually reads.
We do not automate strategic decisions. We do not automate hiring, performance management or anything that requires judgement. We do not automate processes that change weekly. If a process is still being invented, automating it is a waste of money. We will say so directly. The best automation candidate is a process that the team already runs the same way every time, where the pain is volume or speed or error rate, not ambiguity.
We also do not replace systems that already work. If the company runs Salesforce and QuickBooks and a field service tool, we build automation that sits across them, moving data and triggering actions. We are not asking anyone to rip out a CRM. Integration over replacement is cheaper, faster and far less disruptive to a management team that is already stretched.
We scope automation engagements one process at a time. The client identifies the process. We define the current state together: who touches what, which systems are involved, where the delays and errors cluster. Then we agree a window. The window is the period during which we will build the automation, test it, run it in parallel with the manual process and then switch over. A typical window for a single process is six to eight weeks from kickoff to live operation, though complex integrations can run longer.
Scoping one process at a time keeps the work contained and the value visible. The operating partner sees a specific problem get solved. The management team sees a specific burden lifted. There is no eighteen month digital transformation programme with a steering committee and a roadmap deck. There is a process that hurts, a window in which we fix it, and a live automation at the end that we continue to operate.
This approach also limits risk. If the first process goes well, we tackle the next. If the company's priorities shift, we pause. The engagement is modular by design. We have built and operated twenty live properties across multiple portfolio companies, and the ones that worked best started with a single, painful, well understood process and expanded from there.
Most portfolio companies run a patchwork of systems assembled over years and through acquisitions. A CRM that one division uses religiously and another ignores. An ERP that was implemented for the largest business unit and never rolled out further. Spreadsheets that fill the gaps. Our automation sits on top of this reality. We do not require a clean, consolidated tech stack before we start. We integrate with what is there.
We connect to APIs where they exist. Where they do not, we work with flat file exports, email parsing, screen scraping where it is reliable, and direct database access where the client permits it. The automation layer becomes the connective tissue that the portfolio company never had the engineering resources to build. When the company eventually migrates to a new system, we update the integrations. The automation adapts rather than breaking.
This is not a permanent architecture. It is a holding period architecture. It is designed to work for the years the private equity owner holds the asset, delivering efficiency gains that flow straight to EBITDA, without requiring a capital investment in a new systems platform that will take two years to deploy and distract the management team from running the business.
Three processes account for most of the automation engagements we run. Lead routing is the simplest and often the most immediately valuable. A portfolio company spends money on marketing, generates inquiries, and then loses some fraction of them because the right salesperson does not get the lead fast enough, or at all. We build routing that captures the inquiry, enriches it against the CRM, applies assignment rules and notifies the rep within minutes. The disposition writes back to the client's system. The loop closes.
Quoting is the next common starting point. In many mid market companies, quoting lives in the head of a senior salesperson or a branch manager. They know the pricing, the discounts, the margin thresholds. When they are busy, quotes go out late or with errors. We build quoting automation that pulls product and pricing data from the ERP, applies rules the sales leadership defines, and generates a formatted quote document. The salesperson reviews and approves, but the assembly work is done. Speed rises. Errors fall.
Scheduling is harder but higher impact. Field service businesses, logistics operators and professional services firms all run some form of scheduling that is part system, part instinct. We build scheduling automation that reads technician or consultant availability from the operational system, matches it to job requirements and produces a schedule that a dispatcher can adjust. The dispatcher remains in control. The automation handles the combinatorial work that exhausts a human brain by ten in the morning.
Each of these processes touches revenue or cost directly. That is intentional. We prefer to automate processes where the improvement shows up in a number the operating partner already tracks.
Back office processes are quieter but compound quickly. Invoicing is a prime example. A company delivers a service, the work order sits in one system, the contract rates sit in another, and the invoice gets built by hand in a third. Days pass between service delivery and invoice issuance. Cash conversion suffers. We build invoicing automation that pulls the work order, applies the contract rate, assembles the invoice with supporting documents and sends it. The finance team reviews before it goes, but the manual assembly disappears.
Records requests follow a similar pattern. A customer or a regulator asks for a document. Someone in the company searches a file share, an email archive or a document management system, finds the right version, redacts what needs redacting and replies. We automate the retrieval and assembly steps. The human still reviews for appropriateness and redaction. The search time drops from hours to minutes.
Document generation covers the repeatable paperwork that every business produces: contracts, statements of work, compliance filings, employment letters, change orders. We build templates that pull data from the systems of record and produce a formatted document. The legal or compliance review step remains. The typing, formatting and data entry do not. Across a portfolio company producing hundreds of documents a month, the cumulative saving is material.
Portfolio company reporting is often a manual, weekly slog. Someone exports data from the ERP, the CRM and the operational system, combines them in a spreadsheet, formats the output and emails it to the operating partner. The process is fragile, slow and prone to version confusion. We build reporting automation that pulls from the source systems on a schedule, applies the transformations the operating partner needs, and produces a consistent output in the format the partner prefers.
We do not build dashboards that nobody opens. We build reports that arrive in an inbox as a PDF or a spreadsheet, ready for the Monday morning call or the monthly board pack. If the operating partner wants a live dashboard, we can build that too, but we default to the format the recipient will actually use. The goal is not visual elegance. The goal is that the operating partner stops asking for the numbers and starts receiving them.
The reporting automation also serves the management team. The same data that flows to the operating partner can flow to the branch manager, the sales director or the CFO, each with the appropriate level of detail. The single source of truth is not a new system. It is an automation layer that sits across the existing systems and produces consistent outputs from the data they already hold.
Every automation engagement we run is built with an exit in mind. The code is documented. The integrations are mapped. The operational runbooks are written so that another team can take over. When the portfolio company is sold, the buyer can choose to keep us operating the automation, bring it in house, or migrate it to their own platform. We support all three paths.
If the buyer wants to bring the automation in house, we provide a transition period during which we train their team, transfer the documentation and remain available for questions. The transition is priced into the engagement from the start. There is no hostage situation where the automation only works if we remain involved. We build to hand over.
If the buyer wants us to continue operating, we negotiate a new agreement directly with them. Several of our live properties have transitioned through an acquisition and continued running under new ownership without interruption. The automation does not care who owns the company. It cares that the integrations are maintained and the rules are current. We handle both.
Automation on top of a process nobody has defined will fail. If the team cannot describe the current process in a consistent way, if three people give three different accounts of how a quote gets built, then the first step is not automation. The first step is process definition. We can help with that, but it is a different engagement and a different timeline. We will not write code against ambiguity. The result would be an automated version of confusion, which is worse than the manual version because it produces errors at machine speed.
Automation that tries to replace human judgement will also fail. We can route a lead, but we cannot qualify it the way an experienced salesperson can. We can assemble a quote, but we cannot negotiate it. We can schedule a technician, but we cannot decide which customer is angriest and needs the first visit. The automation handles the mechanical work. The humans handle the decisions. When clients ask us to automate the judgement, we decline. It is not technically possible in a way that is reliable enough for a real business.
Finally, automation that requires the company to change its core systems before we start will usually stall. We have seen too many projects where the automation was contingent on a CRM migration that was supposed to take three months and took eighteen. We integrate with what is there now. If the company migrates later, we adapt. But we do not make our work dependent on someone else's system project completing on time. That way lies disappointment and a wasted holding period.
Questions
Cost depends on the complexity of the process, the number of systems involved and the quality of the data in those systems. A straightforward lead routing automation with one CRM and one form might run for a few thousand dollars to build and a monthly operating fee in the low hundreds. A multi system quoting automation with complex pricing rules and approval workflows will cost more. We scope and price one process at a time. We provide a fixed price for the build phase and a recurring monthly fee for operation. There is no minimum commitment beyond the build, though most clients keep us operating the automation for the duration of the holding period.
We monitor the automations we operate. When an integration fails, a data format changes or an exception occurs that the automation cannot handle, our team is alerted. We investigate and fix the issue, typically within the same business day. The client does not need to diagnose the problem or find a developer. The operating fee covers monitoring and maintenance. If the breakage is caused by a change the client made without telling us, we still fix it, and we discuss how to prevent it happening again. The goal is that the automation runs quietly and the client notices only the output.
Yes. We need enough access to build and operate the automation. For API based integrations, we need API keys or credentials with the minimum necessary permissions. For file based integrations, we need access to the export location. For database access, we work with the client's IT team or managed service provider to set up a read only connection. We document every access point and every permission. We do not store credentials in plain text. At the end of the engagement, we provide a complete list of access points so the client can revoke them if they choose.
No. We do run an eighty agent call centre, and that team handles outbound calling and qualification work. Process automation is a different service line. It involves software development, system integration, workflow configuration and ongoing technical operations. The automation runs on servers, not on phone lines. The team that builds and operates it is a technical team, not a calling team. The two services can work together: a lead routing automation might hand qualified leads to the calling team for follow up. But they are distinct capabilities with distinct teams and distinct economics.
Resistance is common and we do not dismiss it. Often the resistance comes from a legitimate concern: the automation might eliminate a step that exists for a reason nobody documented, or it might expose performance data that someone would prefer to keep opaque. We address resistance by involving the people who do the work in the scoping process. We ask them to walk us through the current state. We show them what the automation will and will not do. We make clear that their judgement remains essential. If the resistance persists and the operating partner cannot resolve it, we recommend pausing. Automation forced on a team that will not use it is a waste of money.
Related
Next step
Process automation inside a portfolio company is not a technology project. It is an operating decision. The question is whether a repeatable process that currently consumes management time and introduces errors can be made faster, cheaper and more reliable without distracting the leadership team from running the business. We believe the answer is often yes, provided the process is well understood, the automation is built to integrate rather than replace, and someone competent operates it for the duration. That is what we do. We build the automation, we run it, we maintain it, and we hand it over cleanly when the exit comes. If you have a process that fits the description, we are ready to scope it. If you are not sure whether a process is ready, we will tell you honestly. Either way, the conversation starts with the process, not with a platform pitch.
Start a conversation