Business Process Automation: Build, Buy or Hybrid

Business Process Automation

Business process automation (BPA) uses software to run repeatable, rules-based work across people and systems. On the build-vs-buy question: buy a platform when the process is standard across your industry, build custom software when the process logic, data or risk model is your competitive advantage, and use a hybrid when a bought platform covers most of the workflow but one high-value step needs custom code. Most mid-sized organizations end up hybrid; the real decision is where to draw the line.

Key takeaways

  • Decide per workflow, not per company. The same organization can buy accounts-payable automation and build its pricing-approval engine.
  • Licence price is rarely the deciding cost. Integration, exception handling, maintenance and governance usually decide total cost of ownership.
  • Hybrid is a design choice, not a compromise: buy the commodity layers (workflow engine, connectors, telephony, OCR) and own the logic that differentiates you.
  • Process readiness matters more than tooling. Automating an undocumented or unstable process encodes its problems.
  • AI agents widen the build option but raise governance requirements; scope them to bounded, auditable tasks first.

What is business process automation?

Business Process Automation

Business process automation is the use of software to execute a multi-step business process, such as invoice approval, employee onboarding, order-to-cash or claims intake, with rules, triggers and system integrations replacing manual hand-offs. BPA covers the whole process, including people, approvals and exceptions, not just a single repetitive task.

BPA is often confused with its component technologies. Robotic process automation (RPA) automates clicks and keystrokes on a user interface. Integration platforms (iPaaS) move data between systems through APIs. Business process management (BPM) and workflow engines model who does what, in what order. A BPA initiative usually combines several of these layers, which is why “build or buy” is rarely a single decision.

BPA layer What it does Typical buy option When teams build it
Workflow / BPM engine Routes tasks, approvals and SLAs between people and systems BPM suites, low-code workflow tools Process is the product, or needs a custom user experience
Integration (iPaaS / APIs) Moves data between CRM, ERP, finance and other systems Connector platforms (Zapier, Make, n8n, enterprise iPaaS) Volume, latency or business rules exceed connector limits
RPA Mimics user actions on screens without APIs RPA platforms Rarely built; replaced by APIs where possible
Document processing (IDP / OCR) Extracts data from invoices, contracts, forms Document AI services Uncommon languages, layouts or validation rules
Decision logic Applies pricing, eligibility, routing or compliance rules Rules engines inside platforms Rules are proprietary or change weekly
AI agents Interpret unstructured input and take bounded actions Vendor copilots and agent builders Agent needs your data, tools and approval model

Low-code tooling is the most common bought layer. Gartner projects the low-code development technologies market will reach $58.2 billion by 2029 at a 14.1% CAGR (forecast published 4 November 2025, worldwide), naming agentic AI and citizen development as drivers. That growth is one reason the buy option keeps widening, and also why platform sprawl is now a governance risk.

Build vs buy vs hybrid: how the three BPA models compare

Buying a BPA platform wins on speed and maintenance for standard processes. Building custom automation wins on control and fit when the process itself differentiates the business. A hybrid model buys the commodity layers and builds only the logic, data model or interface that a platform cannot express.

Factor Buy (platform / SaaS) Build (custom software) Hybrid
Best fit Standard processes: AP, onboarding, ticket routing, lead routing Processes that encode pricing, risk, compliance or service logic unique to you Standard backbone with one or two differentiating steps
Time to first value Fastest; configuration rather than development Slowest; requires discovery, build and testing Moderate; platform covers the backbone while custom parts are built
Upfront cost Low to moderate (licences, setup) Highest (engineering effort) Moderate
Ongoing cost pattern Rises with users, runs, tasks or seats Mostly maintenance, hosting and change requests Licence plus a smaller maintenance budget
Control over logic and data Limited to what the vendor exposes Full Full on the custom layer, vendor-bound elsewhere
Main risk Lock-in, per-task pricing at scale, workarounds for edge cases Delivery risk, key-person dependency, maintenance debt Integration seams between bought and built parts

When buy is the better choice: The process is common across your industry, the vendor’s default path fits about as well as your current way of working, data access is simple, and errors are low-impact. If a competitor could buy the same tool and get the same result, the process is not a differentiator.

When build is the better choice: The workflow touches money, compliance, customers or systems of record in ways no product models; volumes make per-task pricing expensive; or regulation limits where data can be processed. Building also makes sense when the automation is part of the product your customers use.

When hybrid is the better choice: Most of the workflow is standard but one step carries the value: a scoring rule, a domain-specific knowledge base, a multi-tenant data model, a customer-facing portal. AB Ark’s comparison of custom AI agents and off-the-shelf tools applies the same split to AI agents specifically.

AB Ark field example: a hybrid build in event operations

AB Ark’s publicly documented Eventas case study shows the hybrid pattern in practice. The client’s teams were managing budgets, vendors and attendee communications across separate spreadsheets and apps. AB Ark bought the commodity voice layer (Vapi and Telnyx for the AI call agent) and built what no platform offered: a multi-tenant PostgreSQL engine with row-level security, retrieval-based knowledge bases for domain answers, and a workflow builder for the team’s own tasks.

The case study reports 70% less admin load and 85% of communications automated. Those are client-project figures published by AB Ark, not an industry benchmark, and the page does not state the measurement method or period. The transferable lesson is architectural: the bought voice infrastructure would have been costly to rebuild, while the tenant isolation and domain knowledge were the parts that made the system fit the business.

A caution on AI agents in BPA

AI agents make building more attractive, but they raise the governance bar. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls (press release, 25 June 2025). Gartner also warns that many use cases marketed as agentic do not need agentic implementations. In BPA terms, use deterministic workflow for steps that follow rules, and reserve agents for bounded steps that genuinely need judgment over unstructured input.

What does business process automation cost? A total-cost-of-ownership view

The cost of business process automation depends less on the licence or build quote than on integration, exception handling, change requests and governance over three to five years. A fair build-vs-buy comparison puts both options on the same multi-year total-cost-of-ownership (TCO) model, using your own volumes and rates rather than vendor list prices.

Published benchmarks support this. In Deloitte’s seventh Global Intelligent Automation survey (479 executives, 35 countries, published 2022), organizations beyond the pilot stage reported an average 32% cost reduction in targeted areas, while the estimated average payback for piloting organizations lengthened from 16 to 22 months as programmes grew more ambitious. The same survey found the hardest barriers to end-to-end automation were integrating different solutions (62%), lack of skills (55%) and inability to change processes or ways of working (52%). Over half of respondents had not calculated their cost reduction at all. These figures predate the current wave of AI agents, so treat them as directional rather than current pricing.

TCO component Buy (platform) Build (custom) What to ask
Initial cost Licences, setup, partner implementation Discovery, design, development, testing Is process discovery priced separately?
Usage cost Per seat, per run, per task or per bot Hosting, API and model usage What happens to cost at 3x current volume?
Integration Pre-built connectors; custom connectors cost extra Built to your systems and rules Which systems lack a supported connector?
Exceptions Often handled manually outside the tool Designed into the workflow What share of cases are exceptions today?
Change and maintenance Vendor ships updates; your configuration still breaks Your team or partner owns every change Who fixes it when an upstream system changes?
Governance and security Vendor certifications plus your access controls Your responsibility end to end Where does data reside and who audits it?
Exit cost Migration off the platform, re-implementation Knowledge transfer, documentation Can you export workflows and data in a usable form?

A simple way to compare options is the same formula for each, over the same horizon:

\text{TCO}_{n\,\text{years}} = C_{\text{initial}} + \sum_{t=1}^{n} \left( C_{\text{usage},t} + C_{\text{maintenance},t} + C_{\text{exceptions},t} + C_{\text{governance},t} \right) + C_{\text{exit}}

Compare that TCO against the annual value of the process: hours removed × loaded hourly cost, plus error, cycle-time or revenue effects you can measure. Where usage cost grows with volume, the bought option’s TCO line usually rises over time; the built option front-loads cost and then flattens. The crossover year, if one exists inside your horizon, is the most useful single number in the decision.

AB Ark’s guide to custom software and integration solutions makes the same point for integrations: automation platforms suit simple, low-volume workflows, while custom integration becomes the better fit when volumes are high, logic is complex or reliable error handling is required.

How to decide: the AB Ark BPA sourcing scorecard

The AB Ark BPA sourcing scorecard rates one workflow at a time on six criteria. A low total points to buying a platform, a high total points to a custom build, and a middle score, or a high score concentrated in one or two criteria, points to a hybrid where only those parts are built.

Score each criterion from 1 (strongly favours buy) to 5 (strongly favours build), multiply by the weight, and add the results. The weights below are AB Ark’s editorial defaults, based on which factors most often change the outcome in automation projects; they are not a validated industry benchmark. Adjust them to your context and keep the same weights when comparing workflows.

Criterion Weight Score 1 (buy) Score 5 (build)
Process differentiation 25% Same as competitors; a vendor’s default path fits Encodes pricing, risk, service or product logic unique to you
Integration depth 20% Two or three systems with supported connectors Many systems, legacy APIs or custom data models
Volume and cost scaling 15% Low, stable volume High or fast-growing volume under per-task or per-seat pricing
Risk, compliance and data control 15% Low-impact errors, no residency limits Touches money, regulated data or systems of record
Rate of change 15% Rules change rarely Rules or products change monthly or faster
Internal capability 10% No engineering team to own the system Engineering ownership exists or can be contracted

How to read the weighted score (range 1.0 to 5.0):

  • 1.0 to 2.4: Buy: Configure a platform, accept its defaults and spend effort on process clean-up and adoption.
  • 2.5 to 3.5: Hybrid: Buy the workflow and connector layers; build the criterion that scored 4 or 5, usually differentiation or integration.
  • 3.6 to 5.0: Build: Treat the automation as software you own, with product management, testing and a maintenance budget.

Two overrides apply regardless of score. If the process is undocumented or unstable, fix and document it before choosing either path, because automation will encode the variation. If a regulation prohibits processing data on a vendor’s infrastructure, the risk criterion decides on its own.

Worked example (illustrative, not a client case): a lending firm’s loan-pricing approval scores differentiation 5, integration 4, volume 2, risk 5, change 4, capability 3. The weighted score is 4.0, which points to a build for the pricing logic. The same firm’s employee onboarding scores 1, 2, 1, 2, 1, 1 for a weighted 1.35, which points to buying an HR workflow tool. One company, two different answers, which is why the scorecard runs per workflow.

How to implement business process automation: a six-step sequence

Business process automation succeeds when process clarity comes before tool selection. The sequence below applies whether you buy, build or go hybrid; only steps 3 and 4 change materially between the three models.

  1. Map the process as it runs today: Record steps, systems, hand-offs, volumes and exception rates. Process mining or task mining tools help where event logs exist; interviews and shadowing work where they do not. Deloitte’s survey identified process fragmentation as the top barrier to scaling automation for four consecutive surveys.
  2. Simplify before you automate: Remove duplicate approvals, standardize inputs and agree on one owner per decision. A process that varies by team will produce an automation that breaks by team.
  3. Score the workflow and choose the sourcing model: Run the scorecard above, then shortlist platforms (buy), define the architecture (build), or split the workflow into bought and built components (hybrid).
  4. Pilot one bounded slice: Choose one process segment with measurable volume and a clear baseline. For buy, this is a configuration pilot; for build, a proof of concept or minimum viable product; for hybrid, the integration seam between the two.
  5. Design for exceptions and oversight: Define what the automation does when data is missing, a system is down or a case falls outside the rules. Route those cases to a named human queue with an SLA, and log every automated decision for audit.
  6. Measure, then scale: Compare results with the baseline before automating the next process.

Roles you need: A process owner from the business, an automation or solution architect, integration or software engineers (internal, contracted or through staff augmentation), and someone accountable for security and data governance. Citizen developers can handle low-risk, task-level automation, but Deloitte’s research positions them as a complement to a central automation team rather than a replacement.

Metrics to track: Cycle time from trigger to completion, straight-through processing rate (cases completed with no human touch), exception rate and exception backlog, error or rework rate, cost per transaction, and hours returned to the team. Set each baseline before the pilot starts; without it, the business case cannot be proven.

Common failure modes: Automating a broken process; underestimating integration work; buying a platform priced per task for a workflow whose volume will multiply; building custom software with no one budgeted to maintain it; and deploying AI agents on open-ended tasks without approval steps or audit logs.

If your scorecard points to a build or hybrid, AB Ark’s custom software development team can run the discovery and architecture steps with you and scope the first bounded pilot.

Business Process Automation

Frequently asked questions

What is the difference between business process automation and RPA?

Business process automation automates an entire process, including approvals, people, rules and system integrations. Robotic process automation (RPA) is one technique within BPA: software robots that mimic user actions on a screen, typically used where systems lack APIs. RPA is fragile when screens change, so most teams prefer API-based integration where it is available and keep RPA for legacy systems.

Is low-code automation build or buy?

Low-code automation sits between the two. You buy the platform, but your team or partner still designs, builds and maintains the workflows on it. Treat low-code as “buy” for licensing and vendor lock-in, and as “build” for ownership, testing and change management. Many hybrid architectures use a low-code platform for the workflow backbone and custom code for complex logic.

Can we start by buying and build custom later?

Yes, and it is often the lowest-risk path. Buying first lets you learn the real volumes, exceptions and rules before committing engineering budget. To keep the option open, confirm that workflows and data can be exported, avoid embedding critical business logic in proprietary scripting, and record the volume threshold at which a custom build would pay back.

How long does business process automation take to implement?

Implementation time depends on process stability, the number of systems involved and the sourcing model, so any single figure is misleading. Configuring a bought platform for a standard process is usually the fastest route; custom builds add discovery, development and testing; hybrids sit between. The most reliable way to estimate is a bounded pilot on one process segment, which also produces the baseline metrics the business case needs.

Should small businesses build custom automation?

Usually not at first. Small businesses typically gain more from buying established tools for standard processes and connecting them with an integration platform. Custom automation becomes worthwhile when one workflow is central to how the business wins customers, when per-task platform costs climb with volume, or when off-the-shelf tools cannot apply the business’s rules reliably.

The decision in one line

Buy business process automation for the processes you share with every competitor, build it for the processes that make you different, and use a hybrid when one step in an otherwise standard workflow carries the value. Make the call per workflow, on a multi-year TCO model, after the process is mapped and simplified.

If you want a second opinion on where to draw the build-buy line for a specific workflow, book a free consultation with AB Ark and bring your process map and current volumes.

Sources

+ posts

Head Of Product

Previous Article

Top Bespoke Software Development Companies

Write a Comment

Leave a Comment

Your email address will not be published. Required fields are marked *