You’ve picked a workflow. Now comes the harder question: where should it live? Start with the systems and people already doing the work. Then compare what each approach would actually require.
Our starting point: test a relevant capability in your existing stack first. Move on when you can name a requirement it cannot meet. If the real problem is unclear ownership or outdated information, fix that before introducing another tool.
This is an editorial comparison of approaches, not a product ranking. The same vendor can fit more than one column depending on what you already own and how you deploy it.
| Decision | Extend an existing platform | Buy a specialist product | Build a custom workflow |
|---|---|---|---|
| Access | Check how existing groups and source permissions carry through. | Require a demonstration of customer boundaries, revoked access, and service accounts. | Own identity propagation, authorization checks, and their tests. |
| Integration | Verify the exact connector and actions your license supports. | Check read/write scope, sync delays, limits, and failure recovery. | Budget for APIs, retries, schema changes, and connector maintenance. |
| Evaluation | Find out which results and traces you can inspect or export. | Run your examples, including failures, rather than relying on the demo set. | Build and maintain test datasets, scoring, review, and regression checks. |
| Operating effort | Assign an administrator and a workflow owner; native features still need oversight. | Agree on escalation, support boundaries, and responsibilities on both sides. | Assign engineering ownership after launch, including incidents and upgrades. |
| Cost structure | Count add-on licenses, usage charges, administration, and review time. | Count seats or usage, onboarding, integration, minimum commitments, and exit costs. | Count development, model usage, retrieval/storage, observability, review, and ongoing support. |
| Ability to leave | Check export options and dependencies on the platform’s identity and content model. | Test export of knowledge, configuration, history, and evaluation evidence. | Check portability of state and data; custom code can still depend heavily on one provider. |
Ask for a total-cost estimate at your expected workload. A seat price, a model-token price, and a per-resolution price describe different things. Include the people who maintain sources and review answers in every option.
Start here: if most useful documents live in one platform, evaluate its search and assistant capabilities against a small set of real questions.
Look further when: important sources are missing, access cannot be represented correctly, or you cannot inspect the evidence behind an answer. Compare a cross-system search product with custom retrieval against those specific gaps.
Deciding test: remove a user’s access to a source and check search results, generated answers, and cached responses against your required revocation window.
Read the knowledge workflow brief →Start here: evaluate drafting inside the help desk where agents already work. Measure the time to a correct, reviewed response.
Look further when: the answer needs information or actions outside the help desk, or its review process does not fit your team. A separate product must earn back the extra handoff; a custom workflow needs a maintenance owner.
Deciding test: include an outdated help article and a request for an unauthorized refund. Check that the agent sees the gap and retains control over what is sent.
Read the support workflow brief →Start here: find out whether the bottleneck is locating approved answers, drafting, or getting experts to review them. An owned answer library may improve the process before you add AI.
Look further when: response volume, reusable evidence, and review handoffs justify specialist tooling. Custom work needs a concrete integration or control requirement, not just the ability to build a demo.
Deciding test: change a claim after approval. The workflow should require review of the changed version before submission.
Read the sales workflow brief →These examples show why the details matter. We checked the linked documentation; we have not tested these products in a customer environment.
Microsoft documents connector settings that either respect source access lists or make content visible to everyone in the organization. Its guidance warns that incorrect settings can cause oversharing. Read Microsoft’s access guidance.
Ask for proof: the configuration and denied-access behavior of your chosen connector. Having a connector does not by itself establish correct access.
Intercom documents source inspection and editing an answer in the composer before sending. It also describes warnings when an answer uses internal sources. Read Intercom’s Copilot guide.
Ask for proof: the sources enabled in your workspace, what agents see before sending, and whether the behavior matches your customer-data boundaries.
Amazon Bedrock supports evaluating retrieval and retrieval-plus-generation, including supplied outputs from custom systems. Read AWS’s evaluation overview.
Ask for proof: results on your representative questions, reviewer agreement, and access to the evidence needed to investigate failures. An evaluation feature is not an acceptance decision.
Download the decision worksheet (.md) →
Turn the chosen approach into a pilot review →
Already testing an approach? Use the pilot evaluation worksheet to record results →