What are we actually buying or building?
Start with the accepted result. “We need an AI agent” describes a possible implementation, not a business outcome. “We need every suitable enquiry assigned, prepared with current information and ready for review” gives us something we can test.
Map the process from arrival to completion. Identify the source, decision, reviewer, destination and exception path. Then ask where the current process fails. If people cannot agree which price list is authoritative, resolve that first. Software will otherwise make the disagreement travel faster.
There are more than two choices. We can keep the current process with a better template, buy a product, connect existing tools, or build a bounded workflow. Choose the smallest option that meets the important conditions and leaves the team able to operate it.
Which route fits the problem?
| Your situation | Best starting option | Evidence to request |
|---|---|---|
| The job is drafting, summarising or finding material in an existing app | Use the app feature or buy a suitable product | A trial on real examples, with the required data controls. |
| The product works, but somebody copies its output into another system | Add a light integration | A correct destination record, duplicate prevention and failure alerts. |
| The same business decision combines several current records and specific exceptions | Consider a custom workflow | Source trace, explicit decision rules, review queue and recovery demonstration. |
| The process changes every time and the volume is uncertain | Keep a person in control with assistive tools | A clearer process and evidence that work actually repeats. |
| The task must work when a vendor or model changes | Buy or build with a tested exit path | Exported records, portable instructions and a maintained manual route. |
These are decision rules, not guarantees. A product can fail an essential permission requirement. A custom system can fail because nobody owns it. Remove options that cannot satisfy a hard condition before comparing convenience or price.
When should we buy a product?
Buy when the useful result is already a supported product workflow and the team can accept its limits. For example, Google documents email drafting and search inside Gmail; Microsoft documents drafting and summarising in Outlook. Those features deserve a trial before a bespoke inbox is commissioned. Gemini in Gmail and Copilot in Outlook.
Pros
You can inspect a real interface before committing and test whether people will use it. Standard support, documentation and account administration can reduce the work your own team must invent. The product may already sit near the information needed.
Cons
You accept the supplier's workflow, release schedule and plan boundaries. A feature on a marketing page may not be available in your account or mailbox type. A product that gets most of the way there may still leave the hardest exception with your staff.
Ask the supplier to demonstrate your awkward case, including what happens when the source is missing. Ask how to export your records and revoke access. If the answer requires a sales promise about a future feature, evaluate the product as it works today.
When is a small integration enough?
An integration moves information between suitable existing systems. We would consider it when the team likes its inbox and customer system but repeatedly copies the same accepted information between them.
Workflow platforms such as Zapier and Make offer app connections and chargeable workflow actions. Their meters differ: Zapier uses tasks for successful actions, while Make uses credits, with some AI actions consuming more. Price the actual sequence, not just the trigger. Zapier workflow and task definitions and Make workflow and credit definitions.
The advantage is a limited change to the way people already work. The tradeoff is another connection to monitor. Check ownership of each account, field mapping, duplicate prevention and what happens if the destination is temporarily unavailable.
Prefer an ordinary rule when the answer is deterministic. If every approved form submission creates the same kind of task, a model may add no useful judgement. Add AI only to the part that needs interpretation, such as extracting a request from varied free text.
When does a custom workflow earn its cost?
Consider a build when an important repeated outcome requires your particular combination of sources, rules and handoffs. The workflow might need a current stock record, an approved customer policy and a named reviewer before preparing a response. It may also need to prove what happened after a person approved it.
The upside is control over that process. The downside is responsibility for operating it. Someone must handle changing app permissions, supplier changes, source updates, monitoring and failures. Custom software does not make the underlying model infallible.
We favour an explicit sequence before a broadly autonomous agent: collect evidence, check conditions, prepare work, review and verify the destination. Anthropic's engineering guidance recommends starting with simple approaches and adding complexity when the task warrants it. Building effective agents.
Keep business rules outside a long prompt where possible. A reviewer should be able to read the rule, identify its owner and tell when it last changed. Use a model for interpretation and drafting, while keeping critical checks observable.
What should a proper brief contain?
- Outcome: the finished result and who accepts it.
- Inputs: where the information comes from and who may access it.
- Rules: current policies, prohibited actions and missing-data behaviour.
- Permissions: separate read, draft, write and send authority.
- Exceptions: who receives uncertain or failed cases.
- Evidence: what proves the right result reached the right destination.
- Operations: owner, support, monitoring and recovery.
- Exit: exported records, documentation and a manual fallback.
For Thailand and Europe, include the languages, date conventions and timezones your team actually handles. Give the implementer examples of ambiguity. A deadline with no timezone should be surfaced for review, not silently interpreted by the software.
A clear brief makes product trials fairer too. It lets you reject a custom proposal when an existing product already satisfies the same conditions.
What evidence should we require before paying for more?
Ask for a small working slice using safe representative inputs. Include a normal case, an incomplete one, a conflicting source and a failure in a connected system. Define acceptance before seeing the result. Keep serious errors separate from presentation preferences.
Inspect the actual destination. A screen saying “completed” is not enough if the task never appeared for its owner. For a draft, check the source and recipient. For a record update, check the saved fields. For a customer send, retain the provider's receipt.
Compare the whole cost: product fees or hosting, variable model usage, integration, review, maintenance and exit. OpenAI's API pricing is usage-based and distinct from a chat subscription, which illustrates why a model allowance must be budgeted separately in an API-backed build. API pricing. Use the cost guide for a complete example.
Ask the team who will actually use it to run the trial. A good demonstration by its builder does not prove the workflow fits a busy afternoon.
Who keeps the workflow useful after launch?
Name the business owner and the technical support owner. The business owner keeps policies and acceptance criteria current. The support owner handles failures, access changes and supplier updates. They may be the same person, but neither job should be implied or invisible.
Agree what support includes. Does it cover a changed email permission, a broken source format, a model retirement and an unsuccessful run? Who can pause the system? Who receives the alert when the main owner is away?
Keep the test pack and business context portable. You should be able to explain the workflow without opening one supplier's chat history. That makes an eventual product change less disruptive and gives another person a fair chance of maintaining the work.
Common mistakes
Building before trying the feature already included in the office suite. Buying a product because it has AI rather than because it completes the job. Calling an integration “maintenance free”. Giving a broad agent more authority than the process requires. Pricing development while ignoring support and the work left with people.
Another common trap is treating a failed pilot as wasted effort. A small test that reveals unclear ownership or poor data has answered a valuable buying question. Fix the process or keep the manual route instead of expanding a system that has not earned trust.
Your next step
Write the accepted outcome and hard conditions on one page. Try the most suitable existing product against that brief. If one narrow connection is missing, price an integration. If the important business logic still has nowhere to live, commission a bounded pilot with acceptance evidence, ownership and an exit plan agreed from the start.
Sources and review date
Reviewed 12 October 2026. Prices and plans are as of October 2026. DLVX recommendations are editorial judgements, not a vendor ranking or a promise of results. Recheck the linked terms before buying or connecting business data.
- Gemini in GmailChecked 2026-10-12. Built-in email drafting and search
- Copilot in Outlook FAQChecked 2026-10-12. Built-in drafting and summaries
- Zapier pricing and definitionsChecked 2026-10-12. App connections and successful-action task billing
- Make pricing and definitionsChecked 2026-10-12. Workflow app connections and credit billing
- Anthropic building effective agentsChecked 2026-10-12. Start simply and add complexity when warranted
- OpenAI API pricingChecked 2026-10-12. Usage-priced API processing
Want to apply this to your team? Get a free AI plan.