An AI assistant for B2B shop support: tools, permissions and the human handoff

Support in a B2B shop looks different from consumer support. The people writing in are purchasers, technicians and accountants who know exactly what they want: the delivery date of order 4711, a copy of last month’s invoice, the declaration of conformity for a part, the replacement for a discontinued article. Most of those answers already exist in the ERP, the PIM or a document store; what costs time is finding them and writing them down.

That makes B2B support a good fit for an LLM assistant, and also a place where mistakes are expensive: a wrong delivery date stops a production line, a wrong price becomes a dispute. This post describes how I would design such an assistant for a B2B shop: which requests to take on, how tools get their permissions, where people stay in the loop, and how to tell whether it works.

What B2B customers actually ask support

Before choosing a model or a vendor, sort a few hundred real tickets into request types. In the B2B shops I work on, the same categories come back, and they differ mainly in where the answer lives and what a wrong answer costs.

The first three rows are lookups with one correct answer in a system you control. They are where an assistant earns its keep. The last row is where it should never improvise.

Two lessons from consumer support

The best-known numbers come from Klarna. In February 2024 the company reported that its AI assistant had handled 2.3 million conversations in its first month, two-thirds of its customer service chats, doing the equivalent work of 700 full-time agents, with a 25% drop in repeat inquiries and errands resolved in under 2 minutes instead of 11. In May 2025 its CEO told Bloomberg that Klarna was hiring human support staff again, because the cheaper AI service had produced lower quality, and that customers must always know there will be a human if they want one.

The second lesson is legal. In Moffatt v. Air Canada, a British Columbia tribunal dealt with a chatbot that told a customer he could apply for a bereavement fare retroactively, which contradicted another page on the airline’s site. Air Canada argued that the chatbot was a separate legal entity responsible for its own actions. The tribunal rejected that, held the airline responsible for all information on its website, whether from a static page or a chatbot, found it had not taken reasonable care to ensure the chatbot was accurate, and awarded about 650 Canadian dollars plus interest and fees. It is a small-claims decision, not a precedent for Austria or Germany, but the reasoning is the one I would expect any court to follow.

Architecture: retrieval, tools and a handoff path

A B2B support assistant has three kinds of capability, and keeping them separate is what makes it safe. Retrieval over public knowledge: product documentation, FAQs, terms and conditions, shipping rules. Tools over account data: orders, deliveries, invoices, all scoped to the logged-in company. And a handoff tool that creates a case in the ticket system or CRM with a summary, so the person who takes over does not start from zero.

For the retrieval side the usual RAG engineering applies: chunking, hybrid search for part numbers and reranking, as in a production RAG pipeline. One B2B-specific point: terms, shipping rules and warranty conditions change, and an assistant that quotes last year’s return window is the Air Canada scenario in miniature. Index documents with a validity date and a single current version, and make the assistant cite the document it answered from.

Tools that run in the customer’s context

OWASP’s LLM06:2025 Excessive Agency names three root causes: excessive functionality, excessive permissions and excessive autonomy. Its mitigations read like a design spec for a support assistant: offer only the tools you need, keep each tool narrow, execute extensions in the user’s context with minimum privileges, require approval for high-impact actions, and enforce authorisation in downstream systems rather than relying on the model to decide what is allowed.

In code the rule is simple: the model may pass an order number, never a customer number. The server takes the company ID from the session and the back-end API checks it again. An injected instruction in a product review cannot make the assistant read someone else’s invoices, because no tool accepts that parameter.

// server/api/assistant.post.ts (Nuxt, AI SDK style tools)
import { z } from 'zod'
import { tool } from 'ai'

export default defineEventHandler(async (event) => {
  const { user } = await requireUserSession(event)        // 401 if not logged in
  const companyId = user.companyId                          // from the session, never from the model

  const tools = {
    getOrderStatus: tool({
      description: 'Status, delivery date and tracking for one order of the current customer.',
      inputSchema: z.object({ orderNumber: z.string().regex(/^[0-9]{6,10}$/) }),
      execute: async ({ orderNumber }) => {
        const order = await erp.getOrder(orderNumber, { companyId })   // ERP enforces the scope too
        if (!order) return { found: false }
        return { found: true, status: order.status, confirmedDelivery: order.confirmedDate ?? null, tracking: order.trackingUrl ?? null }
      },
    }),
    handOffToSupport: tool({
      description: 'Create a support case with a summary when the request needs a person.',
      inputSchema: z.object({ topic: z.enum(['price', 'complaint', 'return', 'technical', 'other']), summary: z.string().max(1500) }),
      execute: async ({ topic, summary }) => crm.createCase({ companyId, userId: user.id, topic, summary }),
    }),
  }
  // ... streamText({ model, system, messages, tools, stopWhen: stepCountIs(5) })
})

Note what the order tool returns: a confirmed delivery date or null. If the ERP has no confirmed date, the assistant says so instead of estimating. That one design choice prevents the most damaging class of B2B support errors. The broader identity questions, service accounts and token scopes, are in AI agents are identities.

What stays with people

Rollout is a sequence of permissions, not a launch. I start read-only: status, documents, invoices. Write actions such as reordering a previous order or opening a return request come next, and only with an explicit confirmation step in the UI that shows exactly what will be submitted, the pattern described in human-in-the-loop approval gates. Some things never move to the assistant:

• Prices, discounts and quotes outside the published price list.
• Delivery commitments that the ERP has not confirmed.
• Interpretation of contracts, warranty or liability.
• Technical approval of a substitute part for a safety-relevant application.
• Anything involving an upset key account; route by customer tier, not only by topic.

For those cases the assistant’s job is to collect the facts, order number, article, quantity, what went wrong, and hand off with a summary. That is still valuable work, and it is the part customers notice when the person who calls back already knows the case.

Designing the handoff

Klarna’s CEO put the requirement plainly: customers must know there will always be a human if they want one. In a B2B shop that means a visible "talk to a person" option in the chat at all times, not only after three failed answers, plus clear information about support hours. When the assistant hands off, the case should contain the conversation, the tool results it used, and its own summary, marked as machine-generated so the agent checks it rather than trusts it.

Two triggers for automatic handoff work well: the request falls into a topic on the "stays with people" list, or the assistant has no tool result or source for its answer. The second trigger is the important one. An assistant that says "I could not find a confirmed delivery date, I have passed this to our order team" is useful; one that guesses is a liability.

Transparency, the AI Act and data protection

Article 50 of the EU AI Act applies from 2 August 2026. Its first paragraph requires providers to design AI systems that interact directly with people so that the people concerned are informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed, observant and circumspect person. A chat widget that looks like live chat with a named agent is exactly the case where it is not obvious, so label it. My Article 50 checklist covers the implementation details.

B2B does not mean no personal data. Contact names, email addresses and delivery addresses of people at your customers are personal data under the GDPR, and the conversation log will contain them. Decide the retention period for transcripts, what reaches the model provider and under which data processing terms, and whether you need a DPIA; the worked DPIA example uses a support assistant as its case.

Measuring whether it helps

Deflection, the share of chats that never reach a person, is the number vendors like and the one that hides failures: a customer who gives up also never reaches a person. Vendors also define resolution in their own way. Intercom, which prices its Fin agent per outcome at 0.99 dollars, counts a resolution when no further help is requested after Fin’s last answer, and charges one outcome per conversation. That is a reasonable billing rule and a weak quality metric, so measure your own.

Turn the reviewed conversations into an eval set and run it before every prompt or model change, as described in LLM evals for product features. And before customers see anything, run the assistant for a few weeks as an internal tool for your own support team, drafting answers they send or discard. You get labelled data, the team learns where it fails, and the first customer-facing version starts with known limits instead of hopes.

Sources

1. Klarna: AI assistant handles two-thirds of customer service chats in its first month (press release, 2024)
2. Entrepreneur: Klarna is hiring customer service agents again, according to its CEO (May 2025)
3. ABA Business Law Today: BC tribunal confirms companies remain liable for information provided by AI chatbot
4. OWASP GenAI Security Project: LLM06:2025 Excessive Agency
5. OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
6. EU AI Act, Article 50: Transparency obligations
7. Intercom: Fin pricing and billable outcomes