Building a vertical SaaS bolt on search around workflow fit

By Joash Boyton, founder, owner and CEO of Acquiry

Sponsored educational article by Acquiry.

Build a vertical SaaS bolt on search around the customer workflow the existing platform needs to improve. Define the missing task, the customer who needs it and the operating constraints the buyer must respect. Translate those requirements into observable target characteristics, then separate what research can indicate from what an owner conversation or specialist review must verify. Annual recurring revenue can help describe a business, but it cannot establish workflow fit by itself.

This approach gives an origination partner a more useful instruction than a broad request for software companies in the same industry. It helps distinguish a genuinely complementary product from a superficially similar offering, and it gives the buyer a reason to reject attractive-looking companies that do not solve the intended problem. The guide below develops a workflow-to-target map, practical screening questions and fictional comparisons that can be used when commissioning a search.

Define the platform's missing job

Start with a customer task rather than a product category. What is the customer trying to accomplish before, during or after using the buyer's existing platform? Where does the current offering stop? What work does the customer perform elsewhere? Describe the gap in terms of the people, decisions and outputs involved, without assuming that an acquisition is the only way to address it.

Ask the product and customer-facing teams to provide evidence for the gap. This might include authorised summaries of recurring customer questions, workflow observations or known implementation requirements. Keep a customer request distinct from a validated acquisition thesis. A request for an additional feature may reflect a useful need, but the buyer still has to decide whether acquiring a business is an appropriate route.

Write a one-sentence objective that a researcher can understand. For example, a hypothetical platform might want to support the handover between planning a task and confirming that the task was completed. The sentence should identify the gap without specifying a target prematurely. If stakeholders cannot agree on that sentence, resolve the disagreement before asking an adviser to map the market.

Map the workflow before naming targets

Draw the current workflow as a sequence of customer actions. For each action, identify the person performing it, the information required, the decision made and the output produced. Mark where the buyer's platform participates and where another product, a service provider or a manual process takes over. The map is a commercial description to guide the search, not a technical architecture diagram.

Then identify the connection the acquisition is expected to improve. The buyer may want to add a missing activity, reduce an awkward handover or support a different role in the same process. Each objective points toward different target characteristics. A product used by the same customer is not automatically part of the same workflow, and a product in an adjacent category may be relevant if it solves the actual gap.

Ask what would change for the customer after the acquisition under the proposed operating plan. If the buyer cannot describe that change, it may be relying on a category-level consolidation thesis rather than workflow fit. That may be a legitimate strategy, but it should be named accurately. Do not use a workflow narrative to justify a search whose real objective has not been agreed.

Identify the user and the purchasing decision

The person who performs a task may not be the person who chooses or pays for the software. Record both roles in the target brief. Ask whether the proposed addition would serve an existing user, introduce a new user group or require a separate buying decision. This distinction affects how the buyer should investigate customer overlap and the credibility of its distribution assumptions.

For initial research, look for descriptions of intended users, use cases and customer types. Treat those descriptions as signals to verify. A product marketed to the same industry may serve a different department or a different part of the organisation. The search should explain why the relevant user and purchaser relationships matter rather than assuming that shared industry language establishes commercial alignment.

When the opportunity reaches an authorised conversation, ask how customers adopt the product and who participates in the decision. The answer may reveal that the proposed bolt-on requires a different sales or implementation capability. That does not automatically rule it out, but the buyer should decide whether that operating model fits its resources before treating the target as an easy addition.

Translate the gap into target characteristics

Convert the workflow map into a small set of target characteristics. Include the task served, the relevant user, the customer context and the point of connection with the buyer's platform. Add any operating limits that materially affect fit, such as a requirement to preserve a standalone product or avoid a service model the buyer cannot support. Explain the reason for each characteristic.

Separate characteristics that can be researched publicly from questions that require direct verification. A public product demonstration may indicate which task the software supports. It may not show the full implementation effort, contractual rights or support requirements. The brief should tell the researcher what evidence is sufficient for apparent fit and what must remain unresolved until the appropriate stage.

Avoid filling the brief with technical preferences that the buyer has not justified. A preferred technology may be relevant, but the team should explain why it changes the acquisition decision and who will assess it. The search partner can record signals and organise questions. Qualified technical reviewers should determine the conclusions that depend on architecture, security, code quality or integration feasibility.

Explore before and after the current product

An adjacent workflow can sit upstream or downstream of the buyer's existing product. Ask what the customer does immediately before using the platform and what happens to its output afterward. These questions can identify a useful search space without assuming that the buyer must acquire a direct competitor or another product with the same category label.

Also examine the handover itself. The missing capability may concern coordination, information quality or a decision between tasks rather than an entire new workflow. A focused product could therefore be more relevant than a larger application with a broad feature list. The buyer should explain the desired contribution and let the research test which types of business could provide it.

Set boundaries for adjacent exploration. A researcher should show how each proposed category connects to the original customer objective and which new assumptions it introduces. The buyer then decides whether to investigate. Without that discipline, adjacency can become a reason to include any software business serving a vaguely similar audience, making the resulting list difficult to qualify.

Test customer overlap without assuming cross selling

Customer overlap can mean several different things. The businesses may serve the same industry, the same kind of organisation, the same department or the same individual user. They may even serve some of the same accounts, subject to authorised verification. Record which meaning matters to the acquisition thesis and what evidence would establish it.

A shared customer category does not establish that the buyer can sell the target's product through its existing channel. Ask about the purchasing decision, implementation effort and resources needed to support the additional offering. The sales and customer-success leaders who would participate should review the assumption. The search brief should not turn an untested commercial possibility into a guaranteed benefit.

The buyer may also want access to a different customer group. In that case, lower overlap might be part of the rationale rather than a weakness. Define whether the search seeks deeper workflow coverage for current customers or entry into an adjacent customer context. Mixing those objectives without explanation can cause the adviser to alternate between incompatible target profiles.

Examine product connection as a question

At the search stage, define how the products might relate rather than claiming they will integrate easily. The buyer may contemplate a connected experience, a coordinated sales proposition or continued standalone operation. Each model requires different evidence. Ask the product lead to identify the minimum connection needed for the acquisition rationale to hold.

For a connected experience, investigate the information that needs to move, the people who will use it and the expected behaviour at the handover. For a standalone model, ask what support and governance the acquired product would need without immediate technical integration. For a combined proposition, ask whether the customer understands the value of using both products and what implementation work would be required.

Do not allow a statement that an interface exists to settle the question. The relevant technical team should assess whether the available capability supports the buyer's intended use, on acceptable terms and with manageable work. The origination brief should preserve the question and identify the reviewer rather than presenting a public feature description as a verified integration conclusion.

Include the work around the product

A customer workflow can depend on onboarding, configuration, training or ongoing support as well as software. Ask which of those activities the target performs and which the customer performs. For search purposes, identify whether the buyer wants to acquire that operating model and whether it has the capacity to sustain it. Do not assume that all recurring customer activity is automated.

A useful early question is what happens when a customer uses the product in an unusual way or encounters a problem. Who understands the issue, and how is it resolved? The answer may point to documentation, specialist staff or a founder's personal knowledge. These are matters for further investigation, not automatic reasons to reject the company.

The buyer should distinguish a product capability it wants to preserve from work it hopes to change. If the acquisition thesis assumes that manual effort can be removed, identify the evidence needed to test that assumption. A search should not classify a service-intensive business as a straightforward software bolt-on merely because its customer interface looks like an application.

Put integration capacity into the search brief

Ask the buyer's operating team what it can realistically absorb. Identify who would own the product relationship, who would support the acquired team and who would evaluate any proposed integration. Record competing commitments and decisions that remain pending. The target criteria should reflect the buyer's actual capacity rather than an imagined organisation that will appear after completion.

For example, the buyer may be able to support a standalone product but not a rapid migration onto its existing platform. Or it may have the technical resources to connect products but lack leadership capacity for a separate operating unit. These hypothetical constraints lead to different search requirements. The adviser should understand the distinction before presenting companies as suitable bolt-ons.

Review capacity when the search changes. A target with a broader product or a different service model may require more than the original integration plan contemplated. The buyer should decide whether to expand the plan, seek additional resources or exclude the target. Do not let the attractiveness of a company quietly rewrite a critical operating constraint.

Ask why recurring revenue continues

Recurring revenue is relevant to a software search, but the buyer should investigate what supports it. Ask what customers repeatedly obtain, why they continue using the product and what would prompt them to reconsider. These commercial questions connect the revenue description to the workflow thesis without attempting to perform a full financial diligence exercise during origination.

Distinguish value from replacement difficulty. A customer may value the product's contribution, face work to change systems or rely on a specific support relationship. The buyer needs to understand the combination rather than compress it into a label such as sticky. Ask the adviser to preserve those questions in qualification and involve the appropriate specialists when evidence becomes available.

Also ask whether the revenue description is consistent across materials. The finance team should determine which definitions and reconciliations it needs. Public statements, management explanations and reviewed evidence should remain distinguishable. This guide does not prescribe accounting treatment or a valuation multiple. The search decision is whether the apparent revenue model supports a sensible next investigation into the desired workflow capability.

Examine concentration in the workflow evidence

A compelling demonstration may reflect one customer type or a particularly successful implementation. Ask whether the same workflow applies across the target's customer base and where it differs. The early search note can identify the segments that appear relevant and the evidence still needed. It should not assume that one example establishes a universal product fit.

Customer concentration also matters to how the buyer tests the thesis. If a small number of relationships appear central, the buyer should ask what those customers use, what support they require and how the target's proposition depends on them. The appropriate information request should be authorised and proportionate. Do not contact customers without agreement merely to accelerate research.

Look for contrary evidence as well as successful uses. A customer leaving, reducing use or choosing another product may reveal a limitation worth understanding. Such evidence does not settle the acquisition decision by itself. It helps the buyer identify which assumptions need testing before a company moves from apparent fit to a more developed opportunity.

Separate search signals from diligence conclusions

Create two columns in every target note. The first records what research or an authorised conversation indicates. The second records what remains to be verified and by whom. This simple separation prevents useful early signals from becoming stronger claims as the information moves between the origination team, product team and investment decision-makers.

A public product description may indicate support for the desired task. An owner may describe a particular integration or customer relationship. A technical reviewer may later assess the evidence. Preserve the source and status at each stage. The buyer should be able to tell whether a statement is a marketing description, a management assertion, an observed demonstration or a specialist conclusion.

Use progression gates tied to the workflow thesis. Before further work, ask whether the company still appears capable of solving the defined gap and whether any critical contradiction has emerged. The gate should not require every diligence question to be answered immediately. It should ensure that the next request is justified by the evidence and the buyer's decision needs.

Calibrate the search with a small sample

Before broad owner outreach, review a limited research sample with the buyer's product and operating leads. Ask them to explain which companies seem relevant and why. Compare those judgments with the researcher's interpretation of the brief. The purpose is to identify ambiguities in the target criteria while the search remains easy to adjust.

Include an apparent fit, an adjacent possibility and an attractive-looking mismatch in the sample. Use fictional examples if real company information is not authorised for the exercise. Ask what evidence would change each classification. This tests whether the brief is actionable and whether the buyer's specialists agree on the underlying workflow objective.

Record changes precisely. If the team changes the required user group or operating model, update the target criteria and the reasons for them. Avoid relying on an informal instruction to find more companies like the preferred example. A concrete revision helps the adviser apply the learning to businesses that may look different while serving the same acquisition purpose.

Work through a hypothetical workflow comparison

Consider a hypothetical platform used to plan recurring operational work. Customers then use a separate process to record completion and handle exceptions. The buyer believes a bolt-on could improve that handover, but has not yet decided whether the acquired product should remain standalone or become closely connected. This is an invented scenario, not an Acquiry case study or a description of a live target.

The first fictional target supports the completion stage directly and serves the same user role. Its public description suggests a focused product, but the buyer does not yet know the implementation and support requirements. The second serves the same industry and has an attractive recurring-revenue description, but its core workflow concerns a different department. The third offers a service that completes the desired task using an internal tool.

The first target appears closest to the workflow objective, subject to verification. The second should not be preferred solely because it belongs to the same industry or has a familiar revenue label. It might support a different acquisition thesis, but that would require an explicit decision. The third could be relevant if the buyer wants the service model or can substantiate a different plan, but the internal tool should not automatically be treated as a separable product.

The next evidence requests should differ. For the first, the buyer might seek an approved workflow demonstration and a discussion of implementation. For the second, it should decide whether the different customer role serves a strategic objective worth exploring. For the third, it should investigate how the service and tool depend on each other before assuming the capability can be operated as software alone.

The comparison shows why workflow fit should lead the search. A list organised only by sector and recurring revenue could put all three companies in the same category. A workflow map explains their differences and gives the buyer a reasoned next action for each. It also helps the adviser avoid presenting a changed acquisition thesis as if it were simply another example of the original brief.

Test the same target against a different buyer

Now imagine a second hypothetical platform with a different operating model. It already provides the completion workflow but lacks the specialist service capacity to support complex customer cases. For this buyer, the service-led target in the previous example might deserve closer investigation. The focused software product may offer less incremental capability. The target has not changed; the buyer's gap and resources have.

This variation is useful when reviewing an adviser's shortlist. Ask why each company fits this platform, rather than why it is an appealing software business in general. The answer should connect the target's apparent contribution with the buyer's existing product, customer relationship and operating capacity. A generic description of quality is insufficient to establish platform-specific fit.

Do not turn the comparison into a universal preference for product-led or service-led businesses. The buyer should select the operating model it wants and test whether the target can support it. The search partner's task is to make the distinctions visible, organise relevant evidence and help create informed owner conversations within the agreed scope.

Build the workflow to target criteria worksheet

Use the following fields for each workflow gap. Keep the worksheet short enough to use during a search review, but include enough detail to explain why a criterion matters. The same worksheet can accompany a commissioning discussion with an origination adviser and guide the buyer's internal review of apparent fits.

Customer task and current boundary

Describe the task, the person performing it and where the buyer's current product stops. Record the evidence supporting the gap and the person responsible for validating it. Avoid a feature wish list without a customer context. The field should make it possible for someone outside the product team to understand what the acquisition is intended to improve.

Intended acquisition contribution

State whether the buyer seeks a product, a team, an operating capability or a combination. Explain the desired relationship with the existing platform, such as continued standalone operation or a connection requiring further evaluation. Identify any assumption about the acquired business that would materially change the thesis if it proved false.

Searchable characteristics

List the observable signals that justify including a company in initial research. These may concern the task served, user role, customer context or product description. State what each signal can establish and what it cannot. Give the researcher a reason for the criterion so that adjacent businesses can be assessed intelligently rather than matched mechanically to keywords.

Customer and purchasing alignment

Describe the relevant overlap or adjacency in users, purchasers and customer organisations. Record whether the thesis depends on serving current customers more deeply or reaching a different group. Identify the commercial questions that need review by sales or customer-facing leaders. Do not assume that shared accounts create permission or practical ability to cross sell.

Product and operating dependencies

List the connections, support activities and people that appear relevant to the desired capability. Mark which are known, which are management statements and which require specialist review. Identify the buyer's responsible technical and operating leads. This field should guide proportionate investigation without becoming a premature claim that integration is straightforward or impossible.

Revenue and customer value questions

Record why customers appear to continue using the offering and what evidence would test that explanation. Include the relevant revenue definitions for finance review, but do not let a single recurring-revenue field substitute for understanding the workflow. Note whether the observed use case seems representative and what contrary evidence should be investigated.

Exclusions and strategic trade offs

Identify the workflow or operating features that would make a target unsuitable for this buyer. Explain the reason and who can approve a change. A company may be attractive in general while failing a platform-specific requirement. Keep that distinction explicit so the search does not drift whenever a compelling but different business appears.

Next evidence and decision

State the next question, the approved information required, the responsible reviewer and the decision it will support. The next step might be additional research, an owner conversation, specialist review or exclusion. Avoid an undefined instruction to learn more. A precise next step allows the team to judge whether the search is resolving the acquisition thesis.

Commission the search around the map

Give the origination partner the worksheet and ask it to explain the brief back in its own words. Request an example of an apparent fit and an apparent mismatch using fictional or authorised material. Resolve differences before broad contact begins. The provider should understand both what the buyer wants and why superficially similar companies may not qualify.

Agree how the partner will involve the buyer's product team. The search should not require technical specialists to review every raw name, but it should bring consequential ambiguities to them early. Define the information needed for a focused review and the person authorised to revise the brief. This makes specialist input practical rather than leaving it as a general promise of later diligence.

Also agree what the partner may say to owners about the buyer's product plans. A search thesis is not an approved integration commitment. The approach can explain the capability the buyer is investigating and invite a discussion of fit, while keeping unverified plans conditional. The owner should not be told that a particular future product or operating arrangement has been decided when it has not.

Where Acquiry fits

Acquiry helps buyers define target profiles, research companies and approach owners around a specific acquisition rationale. Its software coverage includes vertical SaaS and workflow software, with attention to recurring-revenue quality and retention. That combination is relevant when a software platform needs origination support guided by a clearly defined workflow gap.

The buyer's product, finance and operating specialists remain important to the search. They determine which assumptions are acceptable and assess the technical, financial and operational evidence required as a discussion develops. If the missing capability can be addressed more appropriately through building or partnering, the buyer should consider that route rather than treating an acquisition search as a commitment to buy.

The useful engagement starts with the map: what the customer needs, what the platform lacks and which target characteristics could close the gap. Origination then becomes a disciplined investigation of that thesis, not a search for recurring revenue that happens to share an industry label.

Frequently asked questions

Is annual recurring revenue useful in a bolt-on search?

It can help describe and screen a business when the definitions and evidence are clear. It does not establish that the product solves the buyer's workflow gap or that customers value it for the reasons the buyer assumes. Use it alongside questions about the task, customer relationship, support requirements and operating model. Have the finance team determine the appropriate definitions and verification needed at each stage.

Should the target serve exactly the same customers?

Not necessarily. The buyer may seek deeper workflow coverage for existing customers or access to an adjacent customer group. Define which objective applies and what resources it requires. Shared industry language is not enough to establish overlap, and different customers are not automatically a weakness. The search should explain how the customer relationship supports the acquisition thesis and what evidence remains to be collected.

Does a product need to integrate immediately to be a useful bolt-on?

That depends on the buyer's intended operating model. A standalone product may fit one strategy, while another may depend on a connected experience. Specify the minimum connection required for the thesis and ask qualified technical reviewers to evaluate it. Do not let a general preference for integration substitute for an explanation of the customer value and work involved.

How much technical diligence belongs in initial research?

Initial research should identify consequential technical questions and avoid presenting unverified assumptions as conclusions. The depth of review should match the next decision and the available permissions. If a technical constraint determines whether a company can fit at all, involve the relevant specialist early. Other questions may reasonably wait until an authorised discussion provides the information needed to assess them.

What if a target has a strong product but a different workflow?

Decide whether it supports a separate acquisition objective worth pursuing. Do not silently redefine the current search to accommodate it. Record the difference, the new assumptions and the decision-maker who can authorise an alternative thesis. The company may be attractive, but platform-specific fit still needs to be established on its own terms.

What should an adviser deliver after the first mapping exercise?

Ask for a clear explanation of how each apparent fit connects to the workflow objective, what evidence supports that view and what remains unresolved. Include representative exclusions so the buyer can test the criteria. The actual deliverables should be agreed in the engagement. The practical standard is whether the output helps the buyer decide where an owner conversation or specialist review is justified.

Make the next search decision

Before outreach, confirm that the buyer can explain the workflow gap, the desired contribution, the relevant customer relationship and its own operating limits. Then review whether the target criteria make those requirements observable. Any remaining uncertainty should have a question, an evidence source and a person responsible for deciding what the answer means.

A vertical SaaS bolt-on search is most useful when it tests a specific improvement to the platform's customer proposition. The workflow map keeps that purpose visible as the team encounters attractive companies, new information and tempting adjacencies. It gives the buyer and its origination partner a shared basis for deciding what to investigate, what to exclude and when the thesis itself should change.

Sources and further reading

• Acquiry buy-side acquisition process: https://www.acquiry.com/acquisitions/
• Acquiry software coverage: https://www.acquiry.com/saas-acquisitions/

About the author: Joash Boyton is founder, owner and CEO of Acquiry, a Melbourne-based M&A advisory firm focused on buy-side acquisition origination. The firm helps buyers define target criteria, identify off-market businesses and qualify owner discussions. acquiry.com.