B2B service with context: why a generic chatbot falls short

The decision lands on many operation teams in the same form: we want to automate supplier and customer service, and the market offers two shapes. A generic assistant, quick to deploy, that converses well. Or a contextual assistant, which needs rules, systems access and exceptions mapped before it answers anything.

Our position, stated early: the generic assistant is not the cheap option. It just moves the cost from the project to the operation, where it shows up as checking work nobody budgeted for.

What each option actually answers

A generic assistant is trained to hold a good conversation, not to know your process. It does not know that a supplier's purchase order goes through an approval level, that one type of cargo has an exception, or that the query should end in a specific system. What it has is language. What it lacks is the process.

The contextual assistant is the same language pointed at a defined scope: your rules, your systems, your exceptions, with access limited to what the project authorized. It answers inside the operation, or it stops and hands off.

flowchart LR
    subgraph sc["Generic"]
        direction TB
        q1["supplier question"] --> a1["generic answer"]
        a1 --> u1["employee checks alone"]
    end
    subgraph cc["With context"]
        direction TB
        q2["supplier question"] --> r2["rules + systems + exceptions"]
        r2 --> e2["routes to the right flow"]
        e2 --> l2["within the defined access limit"]
    end

The comparison on one real question

Take the worked example: a supplier asks about the status of a delivery. The answer depends on the contract type, the agreed channel and the current stage. A delivery on the road has one answer. A delivery with a pending document has another. Here is what each option does with it:

The hidden cost is in the second column. Every vague answer creates a check, and the check lands on the same team that was already stretched. The conversation got faster. The process did not. Service looks like it works in the demo and fades from the routine once people find out they still have to confirm everything.

The criteria that should decide it

Not every service desk needs context. The decision follows three questions:

• Do the answers depend on your rules and systems? If the frequent questions are genuinely generic, opening hours, catalog basics, the generic assistant can carry them honestly.
• Are the rules written down? The process has to be written down: which questions appear, what the path is for each, which rules decide the answer, where the exceptions are. If the rules live only in people's heads, that documentation work happens before either option.
• Can the assistant query the sources? The answer sits in the ERP, the TMS, the database, the team's spreadsheet. Without authorized access to the right source, context is not available to add, and the decision is premature.

In the delivery example, the contextual option only makes sense if the contract rules are written down and the delivery status can be queried with authorized access. When all three answers are yes, the contextual option is one the process can use. When the first is a clear no, the generic assistant is not a compromise. It is the correct tool.

The trade-off we pick

For contextual service, the scope is narrow on purpose: in the example, check the delivery status and the issues linked to it, nothing more. A narrow scope makes the pilot testable and the risk predictable, and expanding later is easier than pulling back.

One choice is worth stating. You can start with the most frequent cases and leave exceptions for later. We choose the opposite. Exceptions, the expired contract, the special cargo, the order outside the standard, define the limits of what the assistant can answer on its own. Without that limit, there is no way to know when it should stop, and shallow service makes its worst mistakes exactly on the rare cases.

A contextual assistant is not presented as free of errors. What the project defines is what happens when confidence is low, when the rule is ambiguous or when the data is missing: stop and route to a person, with a named queue, a priority and a record of the decision. A team that knows when the assistant will stop trusts it more in the cases where it continues.

What would change the pick

Honesty cuts both ways, so name the cases where we would pick the generic option:

• the questions really are generic, with no dependence on contracts, approval levels or systems;
• the operation cannot yet access the data it needs, so context cannot be delivered, and a documented stage of generic service for the simplest queries is better than a stalled project;
• the volume is too small to justify a diagnostic that maps rules, access and data.

Notice all three are conditions about the operation, not about the technology. When they change, the pick changes with them.

In summary

The generic assistant answers generically because it does not know your process, and the cost it saves in the project it returns to the operation as checking work. When answers depend on your rules and systems, pick the contextual assistant: narrow scope, exceptions mapped first, limited access, and a defined handoff for what is not an answer. When the questions are genuinely generic or the context is not yet available, the generic option is the honest choice. The expected benefit of context is more consistent answers and requests that reach the right place, a hypothesis to validate with real data, not a promised result.

Want to assess how your operation's service can get context? Request a diagnostic