Guides
How to choose a platform for company assistants
A buyer’s checklist for platforms that connect people to company knowledge and systems: integrations, governance, approvals, audit, isolation, secrets, Arabic, channels and pilot design.
Updated · 7 min read
Start with the workflow, not the vendor
Most failed assistant purchases fail before the demo: the team evaluates features in the abstract and discovers after signing that the platform cannot touch the one system that matters. Write down two or three concrete workflows first, each as a sentence a user would actually say, such as “investigate this alert and propose an incident update” or “summarise supplier emails and draft replies for my approval”.
For each workflow, list the systems it reads, the systems it changes, the people who must approve changes, and what “done” looks like. That list becomes your test script. It also tells you early whether you need an assistant that acts, or only an assistant that answers questions.
- Systems read: for example Dynatrace, Splunk, ServiceNow, a mailbox.
- Systems changed: tickets created or updated, emails sent, calls placed.
- Approvers: which role may approve which action, and who is the fallback.
- Languages and channels: Arabic, English or both; web chat, email, messaging apps such as WhatsApp, Telegram, Microsoft Teams or Slack, voice or phone.
- Success measure: time to a usable answer, steps removed, errors avoided.
Evaluation criteria and questions to ask vendors
Use the table below as a scoring sheet. Score each row only on what the vendor demonstrates against your workflow; a roadmap slide scores zero.
| Criterion | What good looks like | Question to ask the vendor | Red flag |
|---|---|---|---|
| Integrations | Typed read and write tools for your actual systems, plus a way to add your own | Which tools exist for our systems, and which of them can change data? | A logo wall with no list of operations |
| Governance | Allow, deny or require approval per tool, per assistant, per tenant | Can reading email run freely while sending always needs a person? | One global on/off switch for “actions” |
| Approvals | Run pauses, an authorised person approves the exact action, run resumes | Show a paused run being approved by someone other than the requester. | Approval is a confirmation click by the same user in the chat |
| Audit | Request, tool calls, inputs, approvals and results recorded per run | Can we see who approved what and what the tool returned? | Only chat transcripts are kept |
| Tenant isolation | Enforced at the data layer, not only in application code | What stops a query from returning another tenant’s rows? | “Every customer has its own prompt” |
| Secrets | Credentials encrypted at rest, keys rotated, never returned by the API | How are connector credentials stored and rotated? | Credentials visible in the admin UI or sent to the model |
| Arabic support | Arabic understanding, Arabic answers and right-to-left documents | Run our workflow in Arabic end to end, including the report. | Arabic only through a translation layer |
| Channels | Web chat, email, messaging apps, voice and phone sharing one policy and audit path | Do phone calls go through the same approvals as chat? | Each channel is a separate product with separate rules |
| Model flexibility | Several model providers behind one gateway; switching does not break assistants | What changes if we switch models next quarter? | Agents hard-wired to one provider |
| Pilot | Fixed scope, real systems, agreed success measures, clean exit | What do we own if we stop after the pilot? | Pilot only in the vendor’s sandbox with sample data |
How deep are the integrations, really?
Count operations, not logos. An integration that can only search a ticketing system is very different from one that can also create incidents and change their state. Ask for the tool list per connector and how each tool is classified: read, write, destructive or external send. That classification is what your governance rules will hang on.
Also ask how you add systems the vendor does not support. The Model Context Protocol (MCP) has become a common way to expose tools to assistants; a platform that can register an MCP server per tenant, and apply the same policies to its tools, will not leave you waiting for the vendor’s roadmap.
Governance, approvals and audit: what to verify
Governance is only real if it is enforced before a tool runs. Ask where the permission check happens and what the assistant sees when it is denied. A good platform checks the user’s identity and roles on every request and evaluates a policy for each tool call, so a clever prompt cannot talk the model into an action the user is not allowed to take.
Approvals must be durable. If a run is waiting for a manager, it should survive restarts and resume at the same step when the decision arrives, with the approved content only. Finally, open the audit record for a run you just watched and check that it tells the full story: who asked, which tools ran with which inputs, who approved or rejected, and what happened next.
Security architecture: tenant isolation and secrets
A platform holds credentials to your most sensitive systems, so its security design matters more than its model. For tenant isolation, ask whether the data layer itself refuses queries that are not scoped to a tenant, including nested writes, or whether isolation depends on every developer remembering a filter.
For secrets, ask which algorithm encrypts connector credentials, whether each ciphertext is bound to its tenant so it cannot be copied to another record, how key rotation works for existing credentials, and whether any API ever returns a credential. Vague answers such as “we use the cloud provider’s encryption” are a signal to dig further.
Arabic support and regional requirements
For organisations in Saudi Arabia and Jordan, Arabic support is a functional requirement, not a nice-to-have. Test with real Arabic requests from your users, including mixed Arabic and English technical terms, and check that generated reports read correctly right to left. Tool names and system identifiers should stay intact inside Arabic text.
Regional data protection law also shapes the purchase. Saudi Arabia’s Personal Data Protection Law has been fully enforceable since 14 September 2024 and applies to organisations outside the Kingdom that process personal data of its residents. Jordan’s Personal Data Protection Law No. 24 of 2023 took effect on 17 March 2024. Ask each vendor where prompts, tool results and logs are processed and stored, and involve your data protection officer before the pilot, not after.
Channels and model flexibility
If your users will reach the assistant by phone or voice as well as chat, check that every channel goes through the same identity, policy and audit path. Phone adds its own risks: ask whether outbound calls can be restricted by country, whether premium-rate destinations are blocked, and whether call volume can be capped.
Model choice will change faster than your contract term. Prefer platforms that reach several providers through a gateway, so you can move a workflow to a better or cheaper model without rebuilding tools or policies. Botify follows this pattern: models through OpenRouter, and web chat, web voice, phone, email, Telegram, WhatsApp, Microsoft Teams and Slack sharing one governance path, with Arabic and English throughout.
How to run a pilot that proves something
A good pilot is small, real and measurable. It uses your systems and your users, runs a workflow you already chose, and ends with a decision rather than a slide deck.
- Pick one workflow with clear value and moderate risk, such as incident investigation or email triage.
- Connect real systems with least-privilege credentials created for the pilot.
- Set policies before the first run: read tools open, anything that changes data or contacts people behind approval.
- Agree success measures up front and record a baseline of how the work is done today.
- Include failure tests: a user without permission, a rejected approval, an Arabic request, a revoked credential.
- Review the audit trail with security and the data protection officer at the end.
- Confirm the exit: how you export your configuration and data, and how credentials are destroyed.
Frequently asked questions
What is the difference between a platform for assistants and an orchestration platform?
The terms overlap. A platform for assistants emphasises building and running them; an orchestration platform emphasises the control layer around them: identity, policy, approvals, model routing and audit. For enterprise use you need both, so evaluate the control layer as carefully as the assistant.
Should we build our own platform instead of buying one?
Building makes sense if assistants are your core product and you can staff the control plane long term. Most enterprises underestimate the non-model work: multi-tenancy, credential storage, approvals, audit and connector maintenance. Buying lets the team focus on workflows, as long as the platform lets you add your own tools.
How many criteria should a platform RFP include?
Keep it short enough that vendors must demonstrate every item. The ten criteria in this guide cover what usually decides success; add sector-specific requirements from your security and compliance teams rather than long generic questionnaires.
Why does Arabic support matter when choosing a platform?
Users in Saudi Arabia and Jordan will ask in Arabic, often mixing in English technical terms, and managers expect reports they can read right to left. A platform that handles Arabic only through translation tends to lose meaning and formatting, so test it end to end in Arabic during the pilot.
Which actions should require human approval in a pilot?
Anything that changes data outside the platform or contacts people: sending or forwarding email, creating or updating tickets, placing calls, and deleting anything. Read-only lookups can usually run directly. Loosen approvals only after the audit trail shows the assistant behaves as expected.