Configure, buy or build? Choosing the right improvement

Your CRM already sends quote reminders. The sales team still wants a better follow-up system. Both statements can be true.

Consider a customer who tells a rep to wait until the project budget is approved. The rep remembers the conversation, but the CRM does not. Its scheduled email goes out on time, following its configured rules, and asks whether the customer has made a decision.

Buying another reminder tool may reproduce the same problem. Building an elaborate AI sales agent may be unnecessary. The missing capability could be a reliable way to record a call commitment and update the existing next-action field.

The build vs buy AI automation decision becomes easier when it starts with that level of precision. Identify the operational gap first. Then choose the smallest maintainable change that closes it.

Diagnose the gap before choosing the technology

At Bosar, our starting point is a real transaction or task, followed from its trigger to its outcome. A general request such as “automate sales” is too broad to evaluate. “Prepare a reviewed follow-up after checking the current quote and latest customer conversation” is testable.

Four different problems can sit behind a complaint that the software does not work:

Type of gap	What it looks like	First thing to investigate
Missing configuration	A useful feature exists but is disabled or incomplete	Settings, permissions and workflow rules
Missing information	The system acts on an outdated or incomplete record	Capture, ownership and source quality
Fragmented process	Each tool works, but the handoff between them fails	Shared identifiers, events and integration
Missing capability	The required calculation or behaviour is genuinely absent	Specialist products or a bounded custom build

These categories can overlap. The distinction prevents a software purchase becoming an expensive way to avoid an unresolved process decision.

Write the desired behaviour in plain language

A useful requirement names the trigger, required information, expected output and conditions that should stop the process.

For the follow-up example: when a quote needs attention, check its current revision and latest relevant interaction, prepare the appropriate next action, and return it to the rep for approval. A customer who asked for a pause should not receive another chase simply because a date passed.

That description gives every candidate solution the same job to prove.

Configure when the capability is already there

Existing products often contain more than teams use. Before specifying custom automation, inspect the actual edition, settings and permissions available to the business.

Prospect CRM, for example, documents native workflows with triggers, filters, delays, tasks, emails and webhooks, along with testing and run history. A requirement involving a known event and a fixed response may fit this existing capability. Prospect CRM automation workflows.

Configuration is particularly attractive when the necessary information is already structured, the business rule is stable and someone owns its upkeep. A threshold-based approval or a task created when an opportunity changes stage may not require a language model at all.

Configuration still needs a process owner

The setting is only part of the work. Someone must decide what happens when a record is reassigned, a task is overdue or the customer responds through another channel.

Test those cases before enabling a rule widely. Document who can change it and how a salesperson reports an inappropriate action. A workflow that nobody feels authorised to repair can remain wrong long after the team understands why.

Configuration is also the wrong answer when it depends on staff re-entering the same missing information forever. That may be a useful temporary step, but it should be costed as ongoing work.

Buy when specialist capability matters

Some tasks need substantial domain software. Manufacturing estimation is a good example: interpreting a request, choosing a production route and calculating cost are different functions.

A useful evaluation should cover CAD inputs, factory-specific costing, machine constraints and pricing rules. Check how each candidate handles these requirements on your own jobs, including the exceptions that need an estimator’s judgment.

For a metalworking business, attempting to recreate an established costing engine may be a poor use of its budget. The more valuable work could be configuring that engine correctly and connecting its output to commercial review, follow-up and order creation.

Evaluate against your difficult jobs

Give a prospective supplier representative requests, including the ones that cause your estimators trouble. Include incomplete drawings, unusual finishes, repeat jobs with a changed quantity and a request outside your normal production capability.

Ask what the product does with missing information. Ask which machine and material assumptions need maintaining, how overrides are recorded, and what remains manual. A convincing standard demonstration does not establish performance on your workload.

Our discussion of manufacturing estimation explains why extracting dimensions alone does not produce a defensible price. The same principle applies elsewhere: evaluate the specialist judgment your business needs, not the polish of the interface.

Build when a defined gap remains

A custom build makes sense when a valuable requirement remains after configuration and suitable products have been assessed. The scope might be narrow: connect supported call summaries to a CRM review queue, compare an accepted quote with an incoming order, or assemble a dispatch exception brief from several systems.

Narrow does not mean trivial. The integration still needs correct permissions, reliable record matching, handling for failed requests and a clear account of what it changed.

The owner should be able to answer a simple question: when the automation cannot complete its work, who will know and what will happen next?

Use AI for the parts that need interpretation

Reading an unstructured customer email may benefit from AI. Calculating an approved price from known quantities and rates usually needs a controlled calculation. Checking whether a required field is empty can be a simple rule.

Anthropic distinguishes predefined workflows from agents that decide their own steps, and recommends increasing complexity only when needed. It also recognises the cost and latency tradeoffs of agentic systems. That is a useful design principle for business automation, independent of which model a project uses. Anthropic on building effective agents.

An AI component should earn its place by improving the work being tested. Calling the whole system an agent does not make it more valuable.

A combination is often the right answer

Configure, buy and build are not mutually exclusive choices for an entire company. They are decisions about parts of a process.

For quoting, the combination might be specialist estimation software, existing CRM opportunity management and a small integration that prepares a complete review pack. For dispatch, it could be existing shipment records with a custom check that highlights conflicting delivery instructions before release.

The estimation and quoting solution separates request interpretation, costing and approval for this reason. Different parts of the chain may deserve different tools.

Keep one authoritative record for each fact

When several systems are involved, decide which one owns the customer account, product, approved quote, shipment and invoice. A new dashboard should not quietly become an alternative place to maintain all five.

The integration can present information together without taking ownership of every record. If someone corrects a delivery address, define where that correction belongs and how other views receive it. Otherwise the new automation adds another version for staff to reconcile.

Compare ownership as carefully as features

A feature checklist is useful but incomplete. The following questions expose differences that matter after a system goes live:

Decision area	Evidence to request
Fit	A representative task completed with your inputs
Exceptions	A visible hold or review path when information is missing
Integration	Confirmed access to the required records and actions
Permissions	Clear limits on what each user and automation can read or change
Traceability	Source information and a record of important updates
Monitoring	A named route for failures, overdue items and recovery
Change ownership	The person responsible when processes or software change
Portability	Usable data exports, documentation and an exit route

A product may handle much of this within its platform. A custom build may need these capabilities added explicitly. A no-code integration also needs ownership; visual configuration does not remove operational responsibility.

Check access before accepting a proposal

An integration diagram is not evidence that the required access exists. Confirm the subscription tier, supported API operations, permissions, limits and any restrictions on historical data.

If access is unavailable, the design may need an export, a reviewed manual step or a different scope. Discovering that early can save more time than choosing a faster development tool.

Compare total cost over the same period

Use a consistent planning period for every option. A first-year comparison is useful; a longer view helps when migration or maintenance dominates the decision.

Include discovery, configuration or development, data preparation, licences, usage charges, integration work, training, monitoring, support and the internal time required to operate the process. Add a realistic allowance for changes and an eventual transition away from the chosen supplier.

As an illustrative comparison, assume two options deliver the same scope. A purchased tool costs AUD $300 monthly and needs four hours of internal administration at AUD $75 an hour: AUD $600 monthly, or AUD $7,200 annually. A custom integration has AUD $100 in monthly running charges but needs eight hours of monitoring and maintenance at the same rate: AUD $700 monthly, or AUD $8,400 annually. These are assumed figures, not supplier quotes. Add each option’s upfront costs separately. The lower software bill alone does not identify the lower ownership cost.

Count the work that remains manual

Two options with similar software costs can leave very different workloads. If one requires an administrator to correct identifiers each morning, include that work. If another reduces preparation time but doubles review effort, count both sides.

Time released is not automatically a payroll saving. A better financial case may be faster service, more quotes handled by the same team or reduced rework. State which outcome you intend to measure and avoid counting the same benefit twice.

The AI audit is where those assumptions should become a prioritised decision. It should make a small configuration change a legitimate recommendation, even when a larger project was initially imagined.

Make the pilot a decision, not a demonstration

A useful pilot has a boundary, representative examples and a decision date. It produces enough evidence to proceed, change direction or stop.

Use completed work whose correct outcome is known, alongside a controlled set of current tasks. Preserve difficult cases in the sample. Removing every exception makes the pilot easier to pass and less useful to the business.

Define acceptance and stop conditions

Specify what must be correct, what requires review and which actions remain unavailable. For an order-preparation pilot, that might mean every proposed product and quantity is source-linked, unknown values remain visibly unresolved and no draft can release stock.

Measure total task time, including review and correction, as well as output quality. Record failures rather than quietly fixing them outside the test.

If a core data source is inaccessible or the review burden removes the benefit, pause expansion. The next step may be data cleanup, simpler configuration or a different product. Our implementation approach treats that evidence as part of delivery, with adoption and ownership included in the work.

Frequently Asked Questions

Is custom automation always more expensive than buying software?

No. A small integration can cost less to operate than a broad subscription, while a specialist product can be far cheaper than recreating its core capability. Compare the same scope, planning period and support responsibilities. Include internal administration and maintenance in both options.

Should AI make the whole decision within a workflow?

Only where that authority is deliberately designed and justified. Many useful workflows combine interpretation with fixed rules and person approval. Pricing, customer commitments and consequential record changes need clear controls. More autonomy should follow demonstrated reliability and a business reason.

What if our software does not offer the API access we need?

Check supported exports, imports and native integrations before assuming a live connection is possible. A reviewed file-based process may be sufficient for some tasks. If the only option is fragile or conflicts with system restrictions, reduce scope or reconsider the tool choice.

Can we keep our current CRM and accounting software?

Often, yes. The first investigation should identify whether the problem lies in configuration, data capture or a handoff. Replacing software creates migration and training work of its own. Keep systems that perform their core role well and address the specific gaps around them.

What should a pilot prove before we expand it?

It should demonstrate acceptable output quality, manageable review effort, useful performance on representative exceptions and a reliable failure path. Someone must also be able to maintain it. A successful demonstration is one completed example; a useful pilot explains where the system can be trusted and where it cannot.