Chatbots by vertical in 2026: pick by escalation, not industry

"We need a chatbot for banking" is the most common opening line in a mid-market chatbot RFP, and it is the line that costs the procurement team most of its leverage. In May 2026 the cross-industry feature set that vendors compete on is broadly the same. Where the deployments diverge is in three lines almost no RFP scores on: when the bot hands off to a human, where the conversation logs live, and what audit trail the regulator expects when a customer complains. The vertical label on the platform is the least informative axis of the decision.

This article is for the Head of CX, COO or Head of Digital at a mid-market bank, health provider, retailer or education group sitting in front of a shortlist of "industry-specialised" chatbot platforms in 2026. The vertical badge does real work in marketing decks. It does almost no work in the operational reality of a deployment that survives twelve months.

What every chatbot in 2026 has to do, regardless of vertical

Several obligations apply to every customer-facing chatbot in the EU, the UK and most US states in 2026, irrespective of the industry it serves.

The first is disclosure. EU AI Act Article 50 transparency obligations bind from 2 August 2025 and require that "providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system". A chatbot that pretends to be a named human is now a regulatory exposure, not a UX choice.

The second is accessibility. The European Accessibility Act became applicable on 28 June 2025 for products and services placed on the EU market, which includes consumer chat interfaces. The UK equivalent operates through the Equality Act 2010 reasonable-adjustments duty. Either way, a chatbot that cannot be operated by a screen reader is a procurement liability before it is a customer one.

The third is logging. Whichever vertical the chatbot serves, the conversation logs are personal data the moment a customer can be identified from them, and GDPR Article 30 records of processing apply. The vendor's storage region, retention window, and processor sub-chain are not vertical questions. They are baseline questions, and they decide whether the chatbot can be deployed at all.

The fourth is a real 24/7 availability claim. Every modern chatbot platform offers always-on coverage as a headline feature. The honest operational read is that 24/7 availability is the easy part; what makes the claim hold up is the out-of-hours escalation path. A bot that answers at 03:00 and then queues the user behind an empty inbox until 09:00 does not deliver 24/7 service. It defers complaint volume.

These four lines are the floor. The interesting differences sit on top of them.

Where the verticals actually diverge: escalation, data egress, audit trail

Three axes do the work the "industry" label pretends to do.

Escalation rules. A retail chatbot can hand off to a generic support queue and recover most of the user experience. A banking chatbot that detects a vulnerable customer under the FCA Consumer Duty cannot. It has to route to an agent trained in vulnerability protocols, with the conversation context attached, inside a window the firm can defend to the regulator. A clinical chatbot triggered by suicidal ideation has a different version of the same problem: the escalation is to a clinician, the SLA is measured in minutes, and the log of the handover is the audit trail. The vertical does not change the bot, it changes the escalation graph behind the bot. Vendor scoring should reflect that.

Data egress. The model endpoint a chatbot calls is a data-egress decision. For a UK bank, the FCA's October 2024 thematic review of trading-firm AI use and the Senior Managers and Certification Regime accountability stack make the regulated firm responsible for what their model providers do with the data. For a US health system, the HIPAA Business Associate Agreement has to name the specific model endpoint, region and version, and "OpenAI signed a BAA" in a vendor deck covers only what the BAA actually scopes. For a school, GDPR Article 8 raises the bar on consent for any chatbot interaction with a child under 16 (the threshold varies by member state). Each of these is a different concrete contractual line, not a different platform.

Audit trail. Most general-purpose chatbot platforms log conversations for analytics. What regulators are starting to ask for in 2026 is a different artefact: a reconstructible audit trail showing which model version answered which user, when, with what prompt, what knowledge-base snippet was retrieved, and what was escalated. The Information Commissioner's Office consultation on generative AI and data protection closed in 2024 with this expectation already in the recommendations. A platform that retains only the final text and not the upstream retrieval and model-version metadata fails the audit posture, regardless of the vertical sticker on its homepage.

If a procurement team scores vendors on these three axes first and the industry packaging second, the shortlist changes.

Banking and finance: FCA Consumer Duty, vulnerability detection, advice perimeter

Banking chatbots in 2026 carry three regulatory loads that retail and education do not.

The first is the FCA Consumer Duty, in force since 31 July 2023 for new and existing products and extended on 31 July 2024 to closed-book products. The Duty requires firms to act to deliver good outcomes for retail customers, with explicit attention to consumers in vulnerable circumstances. A chatbot is a customer-communication surface the firm operates, which means the firm has to evidence that vulnerable customers receive an outcome at least as good as the non-vulnerable population. The operational implication is that the chatbot needs vulnerability-detection heuristics (financial distress language, bereavement cues, mental-health indicators) wired into the escalation graph, and the firm needs to be able to show the regulator the audit trail when asked.

The second is the advice perimeter. Under FSMA section 22 and the FCA Handbook PERG 8.30, giving a personal recommendation on a specified investment is a regulated activity. A chatbot that wanders from product information into personalised recommendations crosses the perimeter and exposes the firm to enforcement and rescission. Most banking chatbots in 2026 stay deliberately on the "information, not advice" side; the vendor selection question is whether the platform supports a hard policy boundary the bot cannot cross even under prompt-injection pressure.

The third is fraud and impersonation. The UK Payment Systems Regulator's Authorised Push Payment reimbursement rules took effect on 7 October 2024 and shifted reimbursement liability for most APP fraud onto sending and receiving payment firms. A banking chatbot is a fraud-pretexting surface, both as a target (criminals use chatbot transcripts to learn the firm's patterns) and as a defence (the bot itself can detect grooming language). The procurement question is which side of that ledger the platform sits on by default.

The vertical-specialist banking chatbot vendors in 2026 earn their premium when they bring these three loads pre-configured. The general-purpose vendors can deliver the same outcomes, but the configuration work moves into the buyer's project plan.

Healthcare and telemedicine: HIPAA BAA scope, clinical-decision-support line, EHDS

Healthcare chatbots split into two categories that procurement teams routinely conflate.

The first category is patient-administration and triage chatbots. These handle appointment booking, prescription refills, insurance and benefit eligibility, and symptom-checker routing. They are not regulated as medical devices in the US (the FDA's Clinical Decision Support exemption applies when the clinician can independently review the basis for the recommendation), and in the EU they sit outside MDR if the output is information rather than a medical-purpose recommendation. They still carry HIPAA in the US and GDPR Article 9 special-category-data protections in the EU. The Appify-internal note on healthcare AI governance in 2026 covers the deployer-side stack in more detail.

The second category is clinical-decision-support chatbots. These give specific clinical recommendations to clinicians or patients. They are regulated as Software as a Medical Device (SaMD) under the FDA SaMD framework and under EU MDR Regulation 2017/745. The platform decision in this category is structurally different: the vendor needs a CE mark or FDA clearance for the specific clinical indication, the post-market surveillance burden is real, and the conformity assessment cycle is measured in quarters. Vertical-specialist healthcare chatbot vendors are the only realistic answer here. The general-purpose platform conversation does not start.

For patient-administration use cases, the platform decision turns on HIPAA BAA scope (specific model endpoints, regions, and routing paths), on EU European Health Data Space (EHDS) Regulation 2025/327 obligations as they phase in (the EHDS regulation entered into force on 26 March 2025 and most secondary-use provisions become applicable from 26 March 2027), and on the escalation path to a clinician for any indication of clinical urgency. The vertical label does some of this work. The contractual specifics do all of it.

E-commerce: the easy case where vertical packaging is mostly marketing

E-commerce is the vertical where the gap between vendor marketing and operational reality is widest, and where general-purpose chatbot platforms tend to win on total cost.

The actual jobs the e-commerce chatbot does in 2026 are well-bounded: product discovery, sizing and fit, returns initiation, order-status lookups, post-purchase upsell, and abandoned-cart recovery. None of these are regulatory-heavy. The conversation logs are personal data under GDPR but not special-category. The escalation path is to a generic customer-service queue that already exists. The audit-trail expectation is light. What matters for the buyer is the catalogue and inventory integration, the checkout-flow handoff, and the abandoned-cart trigger latency.

In that environment the "e-commerce chatbot" packaging buys very little beyond a faster integration with Shopify, BigCommerce or the firm's existing OMS. The platform-fit question is mostly an integration question. Vendor differentiation collapses into "does it speak to my product feed and my support ticket system in the way our existing CX architecture expects".

The honest operator read is that e-commerce is the case where a general-purpose chatbot platform plus a competent integration partner outperforms a vertical-specialist vendor on twelve-month total cost of ownership for most mid-market retailers.

Education and online learning: minors, accessibility, plagiarism scaffolding

Education chatbots carry three loads that the other verticals do not.

Minors. Most education customer bases include users under the GDPR Article 8 age threshold (16 by default; lower in some member states down to 13). Parental consent and child-friendly transparency are not optional. The UK Information Commissioner's Office Age Appropriate Design Code has been in force since 2 September 2021 and applies to any online service likely to be accessed by children. The chatbot's data-handling has to comply, and the design choices (defaults, nudges, transparency) are scored against the code.

Accessibility. Education chatbots interact with neurodiverse learners, learners with sensory impairments, and learners whose first language is not the language of instruction. Where the European Accessibility Act and the UK Equality Act set the floor, education buyers tend to set a higher ceiling. The vendor question is whether the chatbot supports learner-side customisation (text-to-speech, contrast, language) as a first-class feature or as a roadmap promise.

Plagiarism and learning integrity. The most-recent shift in the education chatbot conversation is the boundary between tutoring (helpful) and ghostwriting (a learning integrity violation). The Department for Education's policy paper on generative AI in education and the JCQ guidance on AI use in assessment both treat the chatbot's behavioural design as part of the school's academic-integrity posture. A chatbot that completes an essay on request is not the institution's tool. A chatbot that scaffolds the learner toward writing the essay themselves is.

The vertical-specialist education chatbot vendors do real work here. The general-purpose platforms can be configured to the same outcome, but the configuration is non-trivial, and the institution carries the policy risk if the configuration drifts.

Counter-thesis: when the vertical genuinely does change the platform

The argument above is that the vertical label is the least informative axis of the procurement decision for most mid-market chatbot deployments. There are three real cases where that is wrong.

The first is clinical-decision-support chatbots regulated as SaMD. The clearance and post-market surveillance burden is binary: a vendor either has it or does not, and a general-purpose platform almost never does. The vertical-specialist healthcare vendors hold the field there.

The second is regulated investment advice. A chatbot designed to cross the FCA advice perimeter (a true robo-advice surface, not a product-information bot) is a regulated entity in its own right. The platform decision is dominated by the firm's SMCR authorisation, the suitability assessment, and the MiFID II record-keeping rules, none of which a general-purpose chatbot platform is set up to deliver.

The third is education chatbots with high interaction volume with under-13s, where the UK Children's Code, COPPA in the US, and the platform-specific safety-by-design defaults become load-bearing. The vertical specialists who have built around those rules from day one carry a real advantage.

Outside those three cases the vertical badge is mostly procurement comfort. It is worth what the comfort is worth.

How chatbots handle complex or emotional requests, and what that means for selection

A separate question the vertical packaging often answers badly: how does the chatbot handle complex or emotional interactions? Bereavement notifications to a bank. A parent disclosing a child's mental-health crisis to a school. A patient describing chest pain to a triage bot. A customer reporting that a delivery driver was abusive.

The honest answer in 2026 is that no chatbot handles these well on its own, and the vendors that claim otherwise are the ones to drop from the shortlist first. The job is to detect the situation early, suspend the routine flow, and escalate to a trained human with the conversation context attached. The features that decide whether the platform does that job well are sentiment and intent classifiers tuned to the firm's domain, an escalation graph that can route by detected emotion and not just by topic, a context-handover API the agent desktop can actually consume, and a logging model that lets the firm review the handover after the fact.

These are platform-level features. They do not come from the vertical sticker.

Four questions for any chatbot vendor demo

A procurement team that uses the next vendor call to ask these four questions will know within thirty minutes whether the vertical packaging is real.

1. Walk us through the escalation graph for a customer who shows signs of distress mid-conversation. Who is paged, on what SLA, with what context, and how is the handover logged.
2. Name the specific model endpoint, region and version every conversation hits today, and show us the contractual scope (BAA, DPA, sub-processor list) that covers it.
3. Reconstruct a conversation from 30 days ago for a hypothetical compliance request: user identifier, model version, retrieved knowledge-base snippet, prompt, response, escalation outcome. Show us the audit trail in the product.
4. Where is the policy boundary the bot cannot cross even under prompt-injection pressure, and how is that policy enforced (system prompt, retrieval scope, classifier, hard rule)?

A vendor that answers all four clearly is in the running regardless of which vertical it markets to. A vendor that cannot answer them is selling the badge.

Where this leaves a mid-market procurement team in the next 90 days

The runway from May 2026 to the first wave of EU AI Act Article 6 high-risk obligations (deferred under the May 2026 Digital Omnibus political agreement, with Annex III stand-alone obligations now moving toward 2 December 2027 and Annex I medical-device obligations toward 2 August 2028) is the cheap moment to retrofit the chatbot stack. Five steps map to the argument above:

1. Reframe the RFP scoring around escalation, data egress, and audit trail. Make the vertical badge a tie-breaker, not a filter.
2. Inventory every chatbot surface already live, including marketing-page widgets and embedded vendor tools. Map each to the model endpoint, region and contractual scope. The gap is the procurement-team's first action item.
3. Build the escalation graph the firm wants, before evaluating a vendor against it. A vendor demo against a well-specified graph reveals platform fit in one call.
4. Confirm the disclosure and accessibility baseline already meets Article 50 and the European Accessibility Act. These are 2025 obligations the firm is already late on if not already in place.
5. For the regulated cases (SaMD clinical chatbots, robo-advice, under-13 education), accept that the vertical-specialist vendor is the right answer and pay the premium.

The pillar this article sits alongside is the scope-not-category piece on healthcare AI ROI and the three operator floors that decide AI deployment. The chatbot procurement decision is a version of the same problem: the line item the bot is meant to move is more useful than the category label the vendor markets under. Pick that line item, then pick the platform that defends it.

Where Appify fits is in helping mid-market teams build the escalation graph and audit-trail spec before the vendor evaluation starts. Get those right and the platform decision becomes much less expensive.