Best AI Chatbots for Enterprise Customer Support: Five Documents to Ask For

Enterprise chatbots are not chosen the way small-business ones are. Nobody signs up on a card and tries it for a fortnight. A chatbot for enterprises goes through a security review, a legal review and a procurement process, in that order, and the product with the best answers loses to the one with the completed paperwork more often than anybody admits.

That is the difference between a three-month procurement and a nine-month one, and it has nothing to do with which chatbot answers best. This page covers the five documents, what to verify in each, the technical controls that come up in review, and the pricing models you will be comparing once security clears you.

The five documents, and what to check in each

1. SOC 2, and specifically Type II

This distinction catches people, and it matters. A Type I report describes the controls a vendor had in place on a single day. A Type II report tests whether those controls actually held over a period, usually six to twelve months.

Type I is a photograph. Type II is a film. Ask which you are being sent, and check three things when it arrives: the report period end date, whether it is current or eighteen months stale, and whether there are exceptions noted. Exceptions are not automatically disqualifying, but they are the part of the report worth reading.

Expect to sign an NDA to receive it. That is normal and it is not a delay tactic.

2. The data processing agreement

Ask for their standard DPA up front rather than negotiating one from scratch. Two things to look for: whether it names sub-processors by reference to a maintained list, and what the notification period is when that list changes.

A vendor who will send you a DPA before you have signed anything is a vendor whose legal function is set up for enterprise. A vendor who sends a sales deck instead is telling you about their next six months.

3. The sub-processor list

Every AI support product runs on somebody else's model, and often somebody else's hosting and search infrastructure too. That chain is your chain now.

Ask for the current list, in writing, with locations. Then ask the question people forget: how are you notified when it changes, and can you object? A thirty-day notice period with a right to object is the reasonable standard.

4. Data residency

Where is data stored, where is it processed, and are those the same place? They frequently are not, because the model call may go somewhere the storage does not.

Be specific about your requirement before you ask. "EU data residency" means different things to different vendors, and the answer that matters is whether your data leaves your region at any point in the request path, including for model inference.

5. No-train terms

Whether your customer conversations can be used to train anyone's model. There are two contracts to check, not one: what the vendor commits to you, and what the vendor has committed with their model provider. A vendor promise that is not backed by their upstream agreement is not worth much.

Ask for it in the contract rather than in a support article, because support articles change without a signature.

Send those five requests in one email on day one. The reply time tells you more about the vendor than the demo does.

The technical controls that come up in review

The Asyntai column is ours, so read it as a disclosure. Each entry describes a capability that exists in the product, not a certification: the audit log is insert-only and blocks deletion by design, chat retention is a configurable auto-delete with a separate switch for captured leads, and the output classifier is a check on what the system produces rather than an instruction in a prompt. Certifications are a separate question. Send us the same five-document request as everybody else and judge the reply.

Two of those deserve extra attention because they are where demos are weakest.

PII redaction has to happen before the model call, not only before storage. Test it: type a fake card number and email address into a demo conversation and ask the vendor to show you what was sent upstream.

Output controls get described as a policy in a prompt. A prompt instruction is a request, not a control. Ask whether there is a separate check on what the system produces before a customer sees it, and ask to test it with the awkward questions your own compliance team will ask.

What the platforms cost

Enterprise tiers are largely quote-only, which is itself worth planning around. The published numbers below are the tiers beneath the one you will end up buying, and they set the shape of the meter.

We make Asyntai, so read that row as a disclosure. We have listed product capabilities and prices only, and made no compliance claims here: ask us for the same five documents as everybody else, and judge us on the reply. That is the standard this page argues for and it applies to us too.

The meter question at enterprise volume

At small scale the difference between meters is a rounding error. At enterprise volume it is a budget line, and it changes which model you want.

The ratio to calculate is conversations per agent per month. Below roughly two hundred, per-agent pricing tends to be cheaper. Above it, outcome pricing tends to be. Work out your own number before the first negotiation, because it tells you which concession to push for.

One more thing to model: what happens in an incident. A product outage or a billing error can triple support volume for a week. On an outcome meter that is a bill, and it arrives in the same month as the incident. Ask whether there is a cap or a smoothing mechanism.

What "enterprise chatbot" actually means here

The phrase covers three different products and buyers routinely compare across them without noticing, which is why shortlists fall apart in week three.

The Asyntai column is ours, so read it as a disclosure. The public website row is where we are strongest, and it is also the row that ships first in most enterprise programmes, because the content is already public and the security review is correspondingly short.

The security review differs sharply across those three. A public website chatbot handles no personal data until somebody types some, which makes it the easiest of the three to get through review. An in-product agent sees account data by design. An internal agent sees whatever your staff can see, which makes permissions the whole conversation.

Scope your project to one of those three before you write a requirements document. Teams that write "enterprise chatbot" and mean all three end up with a shortlist where no product fits, because no product is best at all three.

Why public-site deployments ship first

If you are looking for somewhere to start, the public website is usually it, for three practical reasons rather than any strategic one:

• The content is already public. Your product pages, documentation and policies are readable by anyone, so indexing them raises no data question.
• The failure mode is contained. A wrong answer on a public page is embarrassing. A wrong answer inside an account can be a breach.
• The volume is there. Pre-sales and pre-login questions are high volume, highly repetitive and currently answered by people or not at all.

Shipping that first also gives your security team a real deployment to review before the harder one, which is worth more than another round of vendor questionnaires.

Integration is the other half of the review

Security clears the vendor. Integration decides whether the deployment survives contact with your existing stack.

• Your ticketing system. An AI layer that cannot hand a conversation to your existing help desk, with context attached, creates a second queue nobody owns.
• Your identity provider. Both for staff access and, on authenticated products, for knowing which customer is asking.
• Your knowledge sources. Documentation, policy pages and internal articles frequently live in three different systems with three different access models. Ask how each is connected and what happens when a restricted document is indexed by accident.
• Your telephony and CRM. If support spans voice and account management, an AI layer that only sees chat has a partial view and will contradict what a customer was told on the phone.

Ask for a demonstration of each connection running live, not a logo grid. In enterprise deployments the integrations are where the timeline actually goes.

Running a pilot that proves something

Most enterprise pilots are designed to succeed, which makes them worthless. Four rules make one that tells you the truth:

1. Use your real content, including the messy parts. Not a curated knowledge base written for the pilot. If your documentation contradicts itself in places, the pilot needs to meet that.
2. Pick one product area, all of its questions. Not the easy questions across everything. A narrow scope with full depth exposes failure; a broad shallow scope hides it.
3. Score accuracy against a written answer key. Have your own experts write the correct answers first, then compare. Scoring after the fact drifts toward generosity.
4. Include the adversarial set. Questions about things you do not offer, questions with false premises, and questions your compliance team would fail an agent for answering. This is the set that separates products.

Sixty questions, scored against a key, run identically across two vendors, will settle an argument that six weeks of demos will not.

Five things to put in the first email

1. SOC 2 Type II report, current period, under NDA. Ask for the period end date in the reply so you know before you sign the NDA.
2. Standard DPA and current sub-processor list. Plus the notification period for changes.
3. Data residency for storage and for model inference. Name your region and ask them to confirm both separately.
4. Contractual no-train terms, including with the model provider. In the contract, not the documentation.
5. Which tier includes SSO, RBAC and audit export. This usually changes the price more than the negotiation does.

What to do next

• Send the document request before the demos. It disqualifies vendors faster than any feature comparison and it costs you one email.
• Calculate conversations per agent per month. That single ratio tells you which pricing model to push for.
• Write your answer key. Sixty real questions with correct answers, written by your own experts, before any pilot starts.
• Test redaction and output controls yourself. Do not accept a description. Type the fake card number and see what happens.

This is not the exciting part of choosing an AI support platform. It is the part that determines whether the project ships this year, and it is almost entirely front-loaded work you can do in a week.