Build, Buy, or Use an Existing AI Assistant?

Choose an existing AI assistant when a person can steer and check the work. Buy a workflow application when it covers your process and your systems with acceptable controls. Build the missing parts when your requirements justify owning their maintenance. Test each option against the same completed task before you commit to a contract or an engineering project.

Define the job you need to finish

Consider a distributor that receives purchase orders by email. A clerk reads an attachment, identifies the customer, matches each line to a product code, and enters a draft order in the enterprise resource planning system, or ERP. They check contract prices and flag missing information before a manager releases the order.

The proposed AI task is to prepare that draft order with links to its source. Completion means that the clerk has a correct, reviewable record in the ERP. A neatly formatted response in a chat window covers only part of the task. Measure the clerk's whole handling time, including checking the output and entering it into the next system.

Write down the required fields, permitted actions, and exceptions. An unknown product code goes to the clerk. A price discrepancy goes to the account owner. A duplicate email mustn't create a second order. Keep credit approval, stock allocation, and customer commitments with their existing owners unless the project explicitly changes those responsibilities.

Compare the three options

These options describe how you deliver the workflow. A bought application may call the same model API as a custom build. An existing assistant may connect to your systems. Compare what your team must configure, verify, and support in each case.

A hybrid may fit best: buy document extraction, keep your product matching rules in a small company-owned service, and use the ERP's approval screen. Specify who supports each boundary. A hybrid with unclear ownership can leave the clerk mediating between vendors whenever an order fails.

When an existing assistant fits

Start here if the clerk handles a manageable number of orders and can easily check the extracted fields against the attachment. A general assistant can help them prepare structured text while they keep control of the final record. This approach can also test whether extraction solves enough of the problem to justify a larger project.

Don't assume an assistant needs constant copying and pasting. OpenAI's connected-app documentation describes search, synced content, and supported actions; availability depends on the app and account conditions. Check the actual capabilities and permissions of the app you intend to use. Access to an email inbox doesn't establish that an assistant can create a correctly approved ERP draft.

The limit may be the surrounding work. If the clerk still looks up every product, resolves customer identities, and retypes the result, faster extraction may save little overall time. Conversely, a straightforward draft-only task may need no new integration. Record where the person intervenes and how long those steps take before you decide to expand it.

When to buy a workflow application

Buying makes sense when a vendor already handles the process you need and can demonstrate it on your systems. Ask them to run your purchase orders, including awkward cases, through your ERP version. A connector listed on a website isn't evidence that it supports your custom fields, authentication setup, or approval sequence.

Use the trial to settle support boundaries. Who repairs a broken mapping after you add a product? Who updates the connector after an ERP upgrade? Can your team change a rule without a vendor ticket? Agree the response to a stalled order, the information your support team can see, and the route for escalating a fault.

Check the exit before signing. Ask for an export of your mappings, order history, and audit records in a format you can read. Check whether a different tool can retrieve the original attachments and resume unfinished work. Include implementation charges, usage limits, and required support in the comparison. The lowest subscription price may cover a narrower scope than the competing offer.

When a custom build earns its cost

Build when a demonstrated gap has enough business value to justify an ongoing technical owner. That gap may be a specialised product-matching rule, a legacy ERP interface, or an approval requirement that available applications can't enforce. Write down the gap and test it with vendors before treating custom engineering as the default.

A custom build can use an existing model, managed extraction service, or automation platform. Your engineers then own the workflow code and its connections. Microsoft describes integration design and deployment as implementation work even within Copilot Studio. A visual builder can reduce coding while leaving your team responsible for process design and testing.

For the order example, keep customer IDs, product validity, and approval limits in application checks. Give the model a bounded extraction task and require it to identify missing information. Before writing to the ERP, validate the fields and check the acting identity's permissions. Record a stable order identifier so a retry can find the existing draft instead of creating another.

Name the person who handles expired credentials, provider outages, and changed order formats. Give them a queue of failed cases and a way to pause new processing while clerks continue manually. Include time for maintaining representative test cases and rerunning them after changes. If you can't fund that ownership, reduce the scope or choose a service with support you can verify.

Check privacy and action controls

Review the actual data path for each option: the email source, any search index, the model service, application logs, and the ERP. Name the identity at each step. Test whether a clerk can retrieve an account they don't handle and whether revoking their source access removes their access through the AI tool.

Microsoft's connector access guidance distinguishes source-specific access from visibility to everyone in an organisation and warns that incorrect permissions can expose sensitive content. Verify the connector configuration rather than assuming that connecting an approved product preserves every source restriction.

Also separate model training from retention. OpenAI says it doesn't use API data for training unless you opt in, but its data-controls documentation describes default abuse-monitoring retention of up to 30 days, subject to exceptions, and separate application-state retention. Its reduced-retention controls require approval and have limitations. Check the chosen endpoints and every third-party service's policy before deciding what customer information to send.

Test an instruction embedded in an incoming attachment, such as a request to bypass review. The system must treat the attachment as order data and enforce approval independently. Ask each provider to demonstrate the boundary between extracting an order, creating a draft, and releasing it. Apply the same test to your own build.

Calculate the cost of accepted work

Compare options over the same period and volume. Include setup, licences, model usage, integration maintenance, staff review, exception handling, and rework. Add an estimate for incident handling, then explain the assumption. Count the cost of the people running the process even when their salaries sit outside the technology budget.

Here is an illustrative calculation, not a vendor quote or an observed result. Assume a tool costs AUD 500 a month and staff spend 20 hours a month reviewing its output at an assumed loaded cost of AUD 80 an hour. The annual operating cost is AUD 6,000 for the tool plus AUD 19,200 for review: AUD 25,200 before setup and maintenance. Halving the subscription saves AUD 3,000 a year. Cutting review by ten hours a month saves AUD 9,600 in staff capacity at that assumed rate.

Capacity savings don't automatically reduce payroll. State whether the team uses the time to process more orders, shorten the queue, avoid planned hiring, or reduce paid hours. Compare those outcomes with a measured baseline; the value depends on what the business actually does with the time.

Use cost per correctly completed order as a comparison measure: total workflow cost divided by accepted orders, including orders that staff finish after an exception. Report errors and delay alongside that figure. An option that cheaply rejects difficult orders can look efficient if your calculation omits the manual queue. Count a retry or duplicate as extra work, not another successful order.

Run a trial that can change your decision

Choose a small set of past orders covering ordinary attachments, unknown products, changed prices, duplicates, and incomplete customer details. Agree the correct outcome with the clerk and approver. Use the same cases for each candidate, with approved or masked data, and begin without releasing live orders.

1. Define acceptance. Name the fields that must match, the review steps that must occur, and the exceptions that must stop processing. Set the acceptable error and handling-time limits before you see the results.
2. Measure the whole task. Time extraction, checks, transfers, and exception handling. Record failures, omitted records, and duplicate attempts. Preserve the comparison with the current manual process.
3. Test recovery. Expire a credential, interrupt the ERP write, and retry the same order. Confirm that staff can find its state and that the system doesn't create an extra record.
4. Test ownership. Ask the intended operator to correct a mapping and investigate a failed order. Note when they need a vendor, consultant, or engineer and include that dependency in the support plan.
5. Review the evidence. Reject candidates that fail required access or approval controls. Compare the remaining choices on accepted work and total cost. Record unresolved cases and who will decide them.

A small trial can expose a poor fit but won't establish the long-term error rate. Follow it with a supervised period on representative work, then review performance after system or model changes. You can expand from extraction to ERP drafting later if the additional integration earns its cost.

What investors should ask

For a venture-backed startup, ask which custom component makes the product better for customers and which components the team can replace. An engineering team can own differentiated workflow logic while buying model access and routine infrastructure. Check whether customer-specific integration work consumes product capacity and whether the company includes that work in its deployment economics.

For a private equity portfolio, compare workflows across companies before assuming that a common tool delivers common results. Two distributors may share a software vendor but use different ERP versions, product identifiers, and approval rules. Reuse a test method and purchasing terms where they fit; budget separately for each company's implementation and support.

Ask management to show the last failed case, who repaired it, and how much work the repair took. Then ask what happens if that person leaves or the vendor contract ends. Those answers reveal the operating commitment behind the chosen option. For external delivery, compare the scope and support obligations in the rates and engagement models with the actual work your trial identifies.