Your Salesforce org decides how hard the chatbot is

The short version

• There are three routes: native Agentforce or Einstein Bots, a third-party chat platform on the API, or a custom agent that calls Salesforce as one tool.
• A bot that writes to Salesforce hits the same required fields, validation rules and triggers a human does, so a heavily customised org is the real scope of the work.
• The bot acts as a Salesforce user, so what it can read is decided by its profile and the sharing model, not by its prompt.
• Native agent pricing is consumption based, so the number you need is credits per conversation, and you only get that by measuring in your own org.
• A chatbot does not create knowledge. It publishes what you already have, including the gaps, faster and to more people.

What are your real options for a chatbot in Salesforce?

Three. Salesforce's own agents, meaning Agentforce for the LLM generation and Einstein Bots for the older intent and dialogue model, running inside Service Cloud and routed by Omni-Channel. A third-party chat platform that hosts the conversation and reads and writes Salesforce over the REST API. Or an agent you build yourself, where Salesforce is one tool the agent can call alongside your other systems.

Choose by where the conversation starts and who owns the escalation. If every chat has to end up in a service console with the transcript attached to a case, and the queue rules are already in place, native is much less work, because that plumbing is the product you are buying. If the conversation starts on a marketing site, mostly answers presales questions, and only sometimes needs a record, hosting it outside Salesforce and calling in over the API is lighter and cheaper to change.

The third route earns its keep when the answer lives in several systems at once. A question like 'where is my order and can I change the address' is not a CRM question. It is a CRM question plus a warehouse question plus a permissions question. Native agents can reach out through Flows and external services, but once most of the work sits outside Salesforce you are maintaining Salesforce configuration in order to orchestrate systems Salesforce does not own, which is usually harder than the reverse.

Before any of this, check which licences your chosen channel needs. Messaging channels, agent seats and consumption credits are separate lines on a quote, and that is a procurement question you want answered before you design around a channel rather than after.

How do the three routes compare?

What does a chatbot need to read and write in Salesforce?

Start with identity, because everything else depends on it. A bot that cannot tell who it is talking to can only answer questions from public content. Once you can resolve a visitor to a Contact or Person Account with reasonable confidence, the same bot can answer about their cases, their orders and their entitlements. Most of the useful behaviour in a Salesforce chatbot sits on the far side of that one problem.

Reads are the easy half: Contact, Case, Knowledge, and whatever object actually holds your product data, which in a mature org is often a custom one. Writes are where the design happens. Creating a case, updating a field, attaching the transcript and logging what the bot told the customer all change the records your service team and your reports depend on. Decide early which writes may happen unattended and which need a human to confirm.

Keep the write list short at first and be specific about it. A bot that can read widely and create one kind of case is useful and auditable. A bot that can update arbitrary fields on arbitrary records is a data quality incident waiting for a bad day.

Why does your org's customisation set the real scope?

Because the bot's writes go through the same metadata a human's do. Required fields, validation rules, record types, duplicate rules, Apex triggers and record-triggered Flows all fire on an insert from an API session exactly as they fire from the console. A ten-year-old org with forty required fields on Case does not need a cleverer prompt. It needs a harder integration.

The usual failure is mundane. The bot has a sensible conversation, tries to create the case, and hits a required picklist that nobody could infer from what the customer said. You now choose between asking the customer a question they should not have to answer, picking a default and accepting that your reporting gets a little dirtier, or routing to a human. All three are defensible. Discovering the problem in production is not.

So read the metadata before you design the conversation. Pull the field list, the validation rules and the triggers for every object the bot will touch, in the sandbox you intend to test in. The conversation design falls out of that, not the other way round.

Who is the bot inside your Salesforce org?

A user, with a profile, a permission set and a position in the sharing model. That is the honest answer, and it decides what the bot can see. No prompt instruction restricts access. If the integration user can query an object, the bot can reach it, and anything the bot can reach can end up in a reply.

So set it up as you would any integration. A dedicated user, a connected app with OAuth, scoped permission sets rather than a wide profile, field-level security on the fields you do not want surfaced, and none of the 'make it an admin to unblock the sprint' shortcut that then stays for two years. Widening sharing to make a bot work is the moment to stop and redesign.

Keep the audit trail answerable. You want to be able to say which records the bot touched yesterday, and on whose behalf, without reconstructing it from raw logs. That matters the first time somebody asks whether the bot changed a field it should not have, and it matters more in regulated work.

What does a Salesforce chatbot cost to run?

On the native side, by consumption. Salesforce announced flexible Agentforce pricing in May 2025, moving agent work onto credits rather than seats alone, and its pricing page publishes a worked example at $500 per 100,000 Flex Credits. For its own help agent, Salesforce says it charges only for resolutions, and it has published production metrics from running that agent on help.salesforce.com across 4.3 million inquiries.

The list price is the part you can look up. The number you need is credits per conversation, and that depends on how many actions each turn takes in your org, which you cannot know before you build. Build a narrow slice, replay real transcripts through it, measure, then multiply. A forecast built on anything else is a guess with a currency symbol in front of it.

Then add the costs that appear on nobody's pricing page: the integration work, the knowledge content somebody has to write and keep current, the evaluation harness, and the upkeep of a bot that drifts out of date every time the product changes. In year one those usually outweigh the per-conversation line. Third-party platforms tend to price per conversation or per seat, which moves the risk rather than removing it, because you pay for conversations that resolved nothing as readily as for ones that did.

What should happen when the bot cannot answer?

It hands over, with the transcript, and without a promise it cannot keep. The handoff is the part of a Salesforce chatbot most worth designing properly, because it decides whether the bot saved the interaction or wasted the customer's time twice. Route into the Omni-Channel queues you already run, attach the conversation to the case, and tell the customer what happens next in plain terms.

Check the queue hours before you write the escalation copy. 'Let me get someone to help you' at 2am, into a queue that opens at nine, is worse than saying nobody is available until morning and offering to raise a case instead. The bot needs to know the business hours it is operating in.

Design the honest dead end too. A bot that says it does not know, and shows the customer the next step, is doing its job. A bot that produces a confident paragraph about a refund policy it was never given is the failure mode that costs you a customer and a week of cleanup.

How do you know whether it is actually working?

Measure resolution in the record, not containment in the chat tool. Containment counts conversations that ended without an agent. Some of those ended because the customer gave up, closed the tab and phoned you, which registers as a success in one dashboard and a cost in another. The number worth tracking is whether the thing the customer wanted actually happened.

Build the evaluation set from real transcripts before launch, including the ones that went badly. Score the answers, and score the writes separately: did the case get created, with the right record type, in the right queue, with the fields a human would have set. Those are two different kinds of wrong and they need two different checks.

When is a Salesforce chatbot not worth building?

When you have no maintained knowledge content, when volume is low enough that two people absorb it comfortably, or when the real problem is a broken process the bot would merely narrate. A chatbot does not create institutional knowledge. It publishes whatever you already have, gaps included, faster and to more people.

Expectations are running ahead of deployments, and most of the published expectation comes from vendors who sell the product. Salesforce's 2025 service research reports that service professionals expect AI to resolve half of service cases by 2027, and its 2026 agents edition surveys 3,075 customer service professionals across 13 countries. Read those as what the market intends, not as what is working. US Census Bureau data on business AI use, meanwhile, finds the heaviest adoption among firms with at least 20 employees.

For a smaller company that is not a reason to stay out. It is a reason to pick one narrow job with real volume, usually the five questions you answer the same way every day, and do that one properly. A vendor survey of 3,350 leaders of businesses with 200 employees and under reports stronger revenue growth among AI adopters, which is a correlation from an interested party, so treat it as a reason to be curious rather than evidence that buying a bot causes growth.

What should you answer before designing the conversation?

• •Which object actually holds the answer, and is it standard or custom?
• •How will the bot know who it is talking to, and what happens when it cannot tell?
• •What are the required fields, validation rules and triggers on every object the bot will write to?
• •Which writes may happen unattended, and which need a human to confirm?
• •Where does an unanswered conversation go, and what are that queue's hours?
• •Who is the integration user, and what can it currently see that it should not?