Customer Service & Helpdesk
Unblu
Provenance unknown Report an errorPanel rating · 6 judges · How to read the stars
Category median
Sovereignty: 1 of 4 dimensions proven
0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Unblu Inc. · www.unblu.com
Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Unblu at a glance
- Vendor
- Unblu Inc.
- Headquarters
- Not stated on the vendor’s pages as of 27 Oct 2026
- Data hosting
- Not stated on the vendor’s pages as of 27 Oct 2026
- Free plan
- Not stated on the vendor’s pages as of 27 Oct 2026
- Panel verdict
- The AI panel rates Unblu 3/5, the mean of 6 judges. Unblu Inc., a Basel-based customer-service platform whose integrations cluster in banking, scores highest on customer data protection, 7 to 8, and integrations, a flat 7. how scores are made
- As of
- Vendor pages captured 27 Oct 2026; evaluated by the panel 27 Oct 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Unblu Inc., a Basel-based customer-service platform whose integrations cluster in banking, scores highest on customer data protection, 7 to 8, and integrations, a flat 7. Judges credit retention that executes — per-category intervals, a garbage-collection job, deletion sweeping messages, files and recordings, audit logs storing the requesting IP — and an openly documented web API with OpenAPI in JSON and YAML, versions v2 to v4, webhooks, and native integrations into Avaloq, Backbase, Temenos, Finnova and Salesforce. Weakest are ticketing core and knowledge and self-service, both flat at 4: routing is genuine — automatic dispatch, up to four priority bands, forwarding to teams — but no public information exists on SLA timers, breach warnings or response-time reporting, and knowledge is a ChatGPT-fed bot corpus with no editorial workflow or deflection reporting. Judges split on omnichannel and sovereignty, both spanning 5 to 7: lower scores weigh missing email, requester portal and WhatsApp consent handling, plus jurisdiction and residency recorded as unconfirmed against the imprint's Basel entity; higher scores credit the named Swiss cloud and ISO 27001. No public prices exist.
Speaks for it
- Retention that executes — per-category intervals, a garbage-collection job, and conversation deletion that sweeps messages, files, recordings and participations
- Audit log entries storing the requesting IP of each change, alongside granular role-based permissions by conversation sensitivity
- Chat escalating mid-issue to voice, video or co-browsing without the customer starting over, with WhatsApp native through the WhatsApp Business Cloud API
- An openly documented web API — OpenAPI in JSON and YAML, versions v2 to v4, webhooks, Java libraries on Maven Central — plus native Avaloq, Backbase, Temenos, Broadridge, Finnova and Salesforce integrations and queue delegation to a third-party ACD
- A Swiss sovereign cloud hosted by T-Systems Schweiz AG in Zollikofen and Bern, an on-premise option, and downloadable ISO 27001 and SOC 2 Type 2 certificates
Held against it
- No public information on SLA timers, breach warnings, escalation chains or first-response and resolution reporting
- Knowledge resources immutable once the database is created, with no editorial workflow, versioning, review dates or deflection reporting
- No public information on inbound email as a channel, a requester-facing portal, or stated consent handling for WhatsApp
- No published subprocessor list, with US Cloud Act exposure flagged for the GCP and IBM Financial Services Cloud deployment options
- No public prices of any kind — a contact email and a whitepaper behind a request form are the only paths
Best for
- You run a bank or wealth platform and want native embedding in Avaloq, Backbase, Temenos, Broadridge, Finnova or Salesforce
- You must host in Switzerland — the sovereign cloud names T-Systems Schweiz AG in Zollikofen and Bern — or deploy on-premise
- Your auditors need retention and deletion machinery you can demonstrate: per-category intervals, deletion notices, audit logs storing requesting IPs
- You already run a third-party ACD and want to delegate the queue rather than replace your telephony stack
Avoid if
- Your operation runs on SLA clocks — ticketing core scored 4, and no public information exists on timers, breach warnings or response-time reporting
- You need a managed knowledge base your editors can version and review — resources are immutable once the database is created and no deflection reporting backs the up-to-80% resolution claim
- You must avoid US-provider exposure — ask the vendor: the public pages we read do not show it
The scores
| Criterion | Panel median |
|---|---|
| Ticketing, queues & SLA | 2 of 5 |
| Channels in one queue | 3.5 of 5 |
| Knowledge base & deflection | 2 of 5 |
| Customer data protection | 3.5 of 5 |
| Integrations & API | 3.5 of 5 |
| European sovereignty | 3.5 of 5 |
Ticketing, queues & SLA
Show reasoningHide reasoning
How this is scored
The engine: how work is routed, prioritised, escalated and measured — and whether an agent can find the ticket they need among ten thousand.
0 — A shared mailbox with labels; no ownership, no status model, no history beyond the thread.
3 — Tickets with assignment and open/closed status, but routing is manual, there are no SLA timers and search covers subject lines only.
5 — Queues with rules-based routing, priorities, a working status model, SLA timers with breach warnings, and full-text search across ticket bodies.
8 — Business-hours-aware SLA policies per queue or customer, escalation chains, macros and triggers, merge and split, and reporting on first-response and resolution time by agent and queue.
10 — The workload is managed rather than merely tracked: capacity-aware assignment, SLA per contract with reporting an account manager could show a customer, audit of every status change, and search that finds the ticket from a half-remembered phrase.
The Support Lead
The dispatch engine is genuine: reservations routed to available agents, up to four priority bands with their own busy limits, a timer on how long an agent has to accept a reservation, forwarding to agents, teams or named areas, and configurable limits on concurrent sessions. The SLA half I live by is absent from the evidence — I found no public information on breach-warning timers, escalation chains, merge and split, or reporting on first-response and resolution time by agent and queue. It routes the work; I can't yet measure it for a quarterly review. 4 5 11
The Agent Advocate
The dispatch engine is genuine: automatic assignment with a timer for accepting or declining reserved conversations, up to four priority bands, forwarding to teams and named areas, and canned responses in the API surface. But I found no public information on SLA timers, breach warnings, escalation chains, first-response and resolution reporting, or agent-side search across conversation bodies — routing without the clocks and the paper trail a helpdesk lives on. 4 5 11
The Data Protection Officer
The queue engine is real — automatic dispatch with reservation timeouts, up to four priority bands, forwarding to another agent, team or named area — but we found no public information on SLA timers, breach warnings, escalation chains, macros, or agent-side search across conversation text. The workload is dispatched and prioritised, yet nothing on the captured pages shows it measured against a promised response time. 4 5
The Shop Operator
Conversations land in a genuine queue with automatic dispatching, reservation timeouts, up to four priority bands, language and area filters, and forwarding to another agent or team — that is real routing, not manual triage. But I found no public information on SLA timers, breach warnings, escalation chains, macros, or first-response and resolution reporting, and no agent-facing full-text search across history, so this stays a chat engine rather than a managed ticket engine. 4 5
The Integrator
The queue is real and well documented — automatic dispatching at agent, team or account level, up to four priority bands with per-band busy limits, chronological fallback order, forwarding to agents, teams or named areas, and even delegation of the queue to a third-party ACD. But I found no public information on SLA timers, breach warnings, first-response and resolution reporting, or macros, triggers and merge and split — a helpdesk I cannot measure against response targets stays below the middle of the scale for me. 4 5 11
The Skeptic
Automatic dispatch with reservations, four priority bands, priority-based queue sorting and forwarding to agents, teams or named areas make the routing real, and canned responses exist in the API. But I read for where SLA timers and breach warnings begin and found no public information on them, nor on business-hours-aware policies, full-text search across conversation bodies, or first-response and resolution reporting by agent and queue. 4 5 11
Channels in one queue
Show reasoningHide reasoning
How this is scored
Email, chat, phone, portal, messengers and social — judged on what actually lands in the same queue with the same history, not on how many channel logos the marketing page carries.
0 — Email only.
3 — Email plus one more channel, but the second lives in its own inbox: no shared history, and a customer who switches channel starts again.
5 — Email, a web form or portal and live chat all landing as tickets in one queue, with the customer's history visible whichever channel they used.
8 — The above plus telephony integration with call logging, at least one messenger (WhatsApp, Signal or similar) with its consent handling stated, and a customer portal where a requester can see their own tickets.
10 — Channel is an implementation detail: every channel including voice and messengers writes to one conversation with one history, agents answer from one screen, and the customer can move between channels mid-issue without repeating themselves.
The Support Lead
Live chat, voice and video sit in one conversation with one-click escalation between them, WhatsApp is integrated natively with its messaging window and templates documented, and agents see full chat history whichever channel the client used. What holds it back: I found no public information on inbound email as a channel, a customer portal where requesters see their own tickets, or stated consent handling for WhatsApp. 1 6 7
The Agent Advocate
Live chat, WhatsApp through the native Business Cloud API, voice and video, co-browsing and secure messaging all become conversations with one history, and a chat can escalate to a call or shared screen mid-issue without the customer starting over — the unification I actually want. I found no public information on email arriving in that queue, a customer portal where requesters see their own conversations, or consent handling for the messenger channel. 1 6 7 11
The Data Protection Officer
Live chat, native WhatsApp, voice and video all land in the same queue with shared history, and a chat can escalate to video, voice or co-browsing mid-issue without the client starting over. We found no public information on inbound email as a ticket channel or on a portal where requesters see their own conversations, and WhatsApp consent handling is not stated in the captured pages. 6 7
The Shop Operator
Live chat, WhatsApp through the native Business Cloud API, and one-click voice or video escalation all write into one conversation with one history, and a customer can move from chat to call mid-issue without repeating themselves — the part I judge omnichannel by. We found no public information on email as a channel, on a portal where requesters see their own conversations, or on consent handling for the messenger, so the channel coverage stops short of the top band. 1 6 7
The Integrator
Channel unification is evidenced rather than logo-deep: live chat, video and voice in one in-app conversation, a native WhatsApp integration over the Business Cloud API with encryption from the customer's device to the server, external messengers with their own API endpoints, and one Agent Desk with full chat history and summaries. What is missing is the customer's own view — I found no public information on a requester-facing portal where a customer sees their own conversations, nor on stated consent handling for WhatsApp. 1 6 7 11
The Skeptic
The channel logos mostly share one queue: WhatsApp arrives through the same conversation templates as chat, agents work one Agent Desk with the full history, and a conversation escalates mid-issue to video, voice or co-browsing. I found no public information on email arriving as a conversation (the secure messenger is pitched as its replacement), on stated consent handling for WhatsApp, on call logging for telephony rather than delegation to a third-party ACD, or on a portal where a requester sees their own tickets. 7 6 4 1
Knowledge base & deflection
Show reasoningHide reasoning
How this is scored
Whether the product reduces the number of tickets as well as organising them: public help centre, article workflow, suggestions to agents and to customers.
0 — No knowledge base; answers live in agents' heads and old tickets.
3 — A basic article list, public or internal, with no editorial workflow, no versioning and no link between articles and tickets.
5 — A searchable public help centre with categories, draft and publish states, and agents able to insert an article into a reply.
8 — Article suggestions to the customer before they submit and to the agent while they answer, multilingual articles, review dates that flag stale content, and reporting on which articles deflect.
10 — Knowledge is a managed asset: gaps identified from unanswered tickets, article performance measured against ticket volume by topic, versioned content with approval, and deflection reported as a number the team can act on.
The Support Lead
Knowledge here means a database built from uploaded files and scraped URLs that a ChatGPT-based bot answers visitors from, with personas, a test mode and AI-suggested replies that agents at BPER reportedly send unchanged. That is deflection in principle, but "up to 80% of routine queries resolved instantly" is a claim I would have to check against my own queue on a Monday morning. I found no public information on editorial workflow, versioning, review dates, or reporting on which content actually deflects. 6 8 9
The Agent Advocate
The knowledge bot answers from a corpus of scraped files and URLs inside the conversation, with personas, tone controls and a test view, and the vendor claims up to 80% of routine queries resolved instantly. But that corpus is bot fuel, not a managed asset: I found no public information on a public help centre, editorial workflow, versioning, review dates for stale content, multilingual articles, or reporting on which content actually deflects. 1 6 8
The Data Protection Officer
The knowledge bot queries a knowledge database built from uploaded resources with a configurable persona and hands off to a human, and the vendor claims up to 80% of routine queries resolved by the AI agent — but we found no public information on article editorial workflow, versioning, review dates or deflection reporting. Knowledge here is consumed by a bot, not managed as an asset, and the 80% figure is a marketing claim rather than a number a team can act on. 6 8
The Shop Operator
Deflection is attempted through a ChatGPT-powered knowledge bot fed from uploaded files and scraped URLs, plus AI-suggested replies for agents, so answers reach both the customer and the agent. But we found no public help centre, no draft-and-publish editorial workflow, no versioning, and no reporting on which content actually deflects — the 'up to 80%' resolution claim is a marketing figure, not a December dashboard my team could act on. 1 6 8
The Integrator
The knowledge side is an AI answering machine rather than a managed asset: uploaded files and scraped URLs feed a ChatGPT-backed knowledge bot with configurable persona and tone, and the marketing page claims the AI agent resolves up to 80% of routine queries. I found no public information on an editorial workflow, versioning, review dates or deflection reporting a team could act on, and the documentation states resources cannot be updated once the database is created. 1 6 8
The Skeptic
Deflection machinery exists — a knowledge bot querying a scraped corpus of URLs and files through ChatGPT, an up-to-80% resolution claim, and AI-suggested replies for agents — but I found no public information on an article list, editorial workflow, versioning, review dates, multilingual articles or deflection reporting. Resources are immutable once created, one knowledge database is live at a time, and the only guidance is to add publicly shareable content. 8 6 1
Customer data protection
Show reasoningHide reasoning
How this is scored
A ticket archive is personal data written by the data subject. Retention, deletion, access control, subject rights, and what the vendor does with attachments — judged on what executes rather than what is promised.
0 — No retention policy stated, no deletion path, agents all see everything, and no DPA is published.
3 — A DPA on request and coarse roles; deletion is described as something the customer arranges, and there is no stated retention period.
5 — A signable DPA published, configurable agent roles and queue-level visibility, a stated retention period, and deletion of a requester's data that can actually be executed.
8 — Automatic retention rules per queue or data category, attachment handling stated, an audit log of who opened which ticket, documented support for access and erasure requests, and pseudonymisation or redaction of ticket content.
10 — Built for a data-protection audit: retention executed and evidenced per category, field-level redaction, full audit trail, subprocessor list published, and the vendor's own support access to customer instances documented and consent-gated.
The Support Lead
Retention is executed machinery, not a promise: configurable intervals per record type with floors and ceilings, a garbage-collection job that deletes conversations together with their messages, files and recordings, deletion notices, and an audit log that stores the IP address behind every change. Granular role-based permissions down to conversation sensitivity and a DLP interceptor for messages and files are documented. What I didn't find is pseudonymisation or redaction of stored content, or a documented path for a subject access request. 3 6 10
The Agent Advocate
Retention here is something that executes: per-category intervals set in an interface or by API, garbage collection behind them, and conversation deletion that sweeps messages, files, recordings and participations together, with an audit log that stores the IP behind each change. Granular roles by conversation sensitivity, a DLP interceptor before content enters chat, encryption at rest and a named data protection officer round it out. I found no public information on redaction of content, a documented path for access and erasure requests, or an audit of who opened which conversation, which I would need to call it audit-ready. 3 6 10
The Data Protection Officer
Retention that actually executes: per-entity policies set in the UI or via the record retention API, a garbage-collection job that marks and deletes, deletion notices before execution, and conversation deletion that sweeps messages, files, recordings, sessions and participations together — backed by a stated processor role, an appointed DPO, one-year default retention, granular role-based permissions, an audit log storing the IP of each logged change, and a message-and-file interceptor for external DLP. What holds it back: we found no public information on field-level redaction of conversation content, a published subprocessor list, documented support for subject access requests, or the vendor's own support access to customer instances. 3 6 10
The Shop Operator
Retention actually executes: configurable intervals per entity type set in the account interface or via API, deletion notices before removal, and a deletion scope that sweeps in messages, files, recordings and bot threads. Roles can restrict access by conversation sensitivity and audit entries record the requesting IP address; we found no public information on documented access and erasure request handling or field-level redaction, which keeps it off the top band. 3 6 10
The Integrator
Retention actually executes: per-category policies for conversations, audit logs, presences and webhook call logs, configurable through the account interface or a documented API endpoint, one year default for conversations, minimum intervals, a garbage-collection mechanism, and deletion that sweeps messages, files, recordings and sessions with the conversation. Roles and conversation-sensitivity permissions are stated and every audit log entry stores the IP of the change. I found no public information on a published signable DPA, documented access and erasure request support, or redaction and pseudonymisation of conversation content. 3 6 10 12
The Skeptic
Retention executes rather than promises: per-category intervals with stated minimums, an automatic mark-and-collect deletion job, a conversation deleted with every message, file, bot thread and recording attached to it, and an audit log storing the requesting IP of each change. Granular role-based permissions, a DPO, a published AI policy and a stated one-year conversation default round it out; I found no public information on field-level redaction or pseudonymisation of content, on a published subprocessor list, or on how the vendor's own support access to instances is gated. 10 3 1 6
Integrations & API
Show reasoningHide reasoning
How this is scored
The systems a helpdesk has to reach — CRM, shop, order management, identity — and whether the API is documented for building or gated behind a partner conversation.
0 — No API and no named integrations; context is copied in by hand.
3 — A handful of native integrations and a read-mostly API, with no webhooks and no documented rate limits.
5 — Named integrations for common CRM and shop systems, a documented REST API with keys, webhooks for the core ticket events, and SSO.
8 — Maintained bidirectional integrations, customer context from other systems shown inside the ticket, SCIM provisioning, documented rate limits and a sandbox.
10 — A component rather than a destination: versioned API with a deprecation policy, event streaming both directions, an app framework for in-ticket extensions, and integrations the vendor maintains rather than lists.
The Support Lead
A versioned web API with a published OpenAPI specification, full create-read-update-delete, webhooks in both directions, Java libraries on Maven Central, and vendor-built integrations into Avaloq, Backbase, Finnova, Temenos and Salesforce — plus the option to delegate the queue to a third-party ACD, which is exactly how I would keep my existing telephony stack. I found no public information on SCIM provisioning, documented rate limits or a sandbox environment. 4 11 12 6
The Agent Advocate
The web API is documented the way I wish every vendor's was: an OpenAPI specification in JSON and YAML served by the server itself, search operators, pagination, optimistic locking, secret masking, Java libraries on Maven Central, and webhooks for conversation, queue and entity events. Salesforce, Avaloq, Backbase, Temenos and Finnova appear as maintained native integrations, and OIDC identity providers are in the API surface. I found no public information on documented rate limits, SCIM provisioning, or a sandbox, which is the difference between a serious API and a partner conversation. 6 11 12
The Data Protection Officer
A genuinely documented API — OpenAPI specification, four versions with v2 and v3 deprecated for backward compatibility, rich search operators, pagination, secret masking, optimistic locking — plus webhooks in both directions and vendor-maintained native integrations into Avaloq, Backbase, Broadridge, Finnova, Temenos and Salesforce. We found no public information on SCIM provisioning, documented rate limits or a sandbox, which keeps this short of the top band. 6 11 12
The Shop Operator
This is a builder's API — versioned with older versions deprecated, OpenAPI self-served from the server, full CRUD with rich search operators, eight webhook types, and a Java client on Maven Central — plus named integrations for Salesforce and the banking cores. We found no public information on shop or order systems, SCIM provisioning, documented rate limits, or a sandbox, and customer context arrives by embedding inside other platforms rather than order data shown inside the conversation. 1 6 11 12
The Integrator
This is an API I would actually build against: full create, read, update and delete across the data model, OpenAPI in JSON and YAML served from the server itself, versions v2, v3 and v4 with the old ones deprecated for backward compatibility, Java clients on Maven Central and GitHub, webhooks configurable through the interface or their own API endpoints, and propagated authentication values so a bot can call third-party systems on the user's behalf. Named integrations cluster in banking — Avaloq, Backbase, Salesforce, Finnova, Temenos — plus ACD delegation, but I found no public information on documented rate limits, SCIM provisioning, a sandbox, or any shop or e-commerce system, and those are exactly the gaps that bite mid-project. 4 6 9 11 12
The Skeptic
The API is documented for building, not gated behind a partner conversation: OpenAPI in JSON and YAML, versions two to four with the older ones declared backward-compatibility-only, webhooks across conversation, queue and CRUD events, search endpoints with operators, and Java libraries on Maven Central, alongside named native integrations for Salesforce, Avaloq, Backbase, Temenos, Broadridge and Finnova. I found no public information on documented rate limits, SCIM provisioning or a sandbox. 12 11 6 9
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where the ticket archive lives, who the contracting entity is, which subprocessors touch it, and whether vendor support can read customer data. Independently sourced by the sovereignty pipeline; scored here as this buyer weighs it.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed.
3 — EU hosting offered as an option while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — support tooling, analytics, AI features — are non-EU without an explained safeguard.
8 — EU or DACH hosting with a named data-centre provider, EU contracting entity, full subprocessor list published, and any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor in the EU, certification published, and a self-hosted or private-cloud option for buyers who need the archive on their own infrastructure.
The Support Lead
A Swiss company in the Basel commercial register with a Frankfurt subsidiary, a sovereign Swiss cloud hosted by T-Systems Schweiz AG in named data centres in Zollikofen and Bern, on-premise as an option, and ISO 27001 and SOC 2 Type 2 published for download. Two things hold it back from the top: the Financial Cloud options run on Google and IBM infrastructure where the research flags US CLOUD Act exposure without a stated legal basis, and I found no public information on a published subprocessor list. 2 3 6
The Agent Advocate
The Swiss sovereign cloud names its host — T-Systems Schweiz AG in Zollikofen and Bern — the imprint puts the contracting entity in Basel with a second entity in Frankfurt, on-premise is offered, and the ISO 27001 certificate is downloadable. But I found no public information on a published subprocessor list, or on the legal basis for the non-EU pieces of the chain: the Google Cloud and IBM deployment options and the knowledge bot's use of ChatGPT. 2 3 8
The Data Protection Officer
A Swiss headquarters entity with a German GmbH carrying register and VAT numbers, a Swiss sovereign cloud hosted by named provider T-Systems Schweiz AG in Zollikofen and Bern, an on-premise option, and a directly downloadable ISO 27001 certificate. Against that, there is no published subprocessor list, and the US-provider exposure of the Google Cloud and IBM deployment options is flagged without a stated legal basis or safeguard on the captured pages. 2 3 6
The Shop Operator
The imprint shows a Swiss contracting entity in Basel with a German subsidiary, a named sovereign hosting option at T-Systems Schweiz in Zollikofen and Bern, an on-premise option, and a downloadable ISO 27001 certificate. But we found no published subprocessor list, the Financial Cloud deployments run on US hyperscalers with US Cloud Act exposure, and the independently sourced attributes left jurisdiction and residency unconfirmed — the chain is not sovereign end to end. 2 3 6
The Integrator
The Swiss option is concrete rather than a checkbox: hosting by T-Systems Schweiz AG in the named Zollikofen and Bern data centres, an on-premise option, a Basel headquarters with a Swiss commercial register number and VAT ID, and ISO 27001 and SOC 2 Type 2 certificates published for direct download. It stops short of the top because there is no published subprocessor list, the GCP and IBM Financial Services Cloud options carry US Cloud Act exposure, and the pages do not name the contracting legal entities behind them. 2 3 6
The Skeptic
The imprint names a Swiss contracting entity with a Basel commercial register number, the Swiss sovereign cloud names T-Systems Schweiz AG with data centres in Zollikofen and Bern, an on-premise option is offered, and the ISO 27001 certificate is downloadable. I found no public information on a published subprocessor list, the US hyperscaler deployment options are named without a stated legal basis for that exposure, and the independent sovereignty assessment records the contracting jurisdiction as unconfirmed against the imprint's Swiss registration. 2 3 6
Pricing transparency
not rated — the vendor publishes no price
Show reasoningHide reasoning
How this is scored
Whether a support lead can compute the real annual invoice for their agent count — including the channels and features they actually need — from public pages alone.
0 — No public prices at all; every tier is a sales conversation.
3 — A per-agent headline exists, but the tier where the needed channel or SLA feature begins is unstated, or light-agent and contact limits are not mentioned.
5 — Per-agent prices public for the main tiers with billing period stated, but at least one commonly needed capability (telephony, messengers, SLA policies) sits in an unpriced bundle.
8 — Every tier and add-on priced publicly with per-agent maths, billing period, minimum term and VAT treatment stated; only genuinely custom enterprise work lacks a number.
10 — Complete price computability: a calculator or table producing the annual invoice for a given agent count and channel selection, including usage-metered channels and overage.
The Support Lead
I found no public information on prices anywhere in the captured pages — no per-agent figure, no tiers, no add-ons, only a contact email and a whitepaper behind a request form. For my twelve agents I cannot compute even a rough annual invoice. 2 3 6
The Agent Advocate
I found no public information on pricing of any kind — no per-agent figures, tiers, billing periods or VAT treatment on the captured pages — and the detailed cloud whitepaper sits behind a request form with a contact email as the only way in. A support lead cannot compute any part of the annual invoice from public pages; the first number arrives in a sales conversation. 2 3
The Data Protection Officer
We found no public information on prices: no per-agent figure, no tier names, no billing period on any captured page, and the cloud whitepaper sits behind a request form. A support lead cannot compute even a rough annual invoice from these pages alone. 3
The Shop Operator
We found no public pricing of any kind: no tiers, no per-agent price, no billing period — only a contact email and a gated deployment whitepaper. A support lead cannot compute any annual invoice from the captured pages; every tier is a sales conversation. 3 6
The Integrator
I found no public pricing of any kind — no per-agent figure, no tier names, no billing period — and the only substantive document on deployment options is a whitepaper gated behind a request form. For my agent count the annual invoice is uncomputable; it is a sales conversation. 2 3 6
The Skeptic
No captured page shows a price of any kind — no per-agent figure, no tier names, no billing period — and every path ends at an email address or a whitepaper behind a request form. A support lead has nothing to compute an annual invoice from, and I found no public information on where channels, SLA features or the AI capabilities begin or what they cost. 2 3 6
European sovereignty — proven facts
1 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined ⚠ unverified | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined ⚠ unverified | — | uncited Report an error |
| Subprocessors | US CLOUD Act reach ⚠ unverified | 0/2 pts | 3 Report an error |
Questions about Unblu
Is Unblu European?
Not determined: the vendor’s pages as captured do not say where Unblu is based.
Where does Unblu store data?
Not stated on the vendor’s pages as of 27 Oct 2026.
Does Unblu have a free plan?
Not stated on the vendor’s pages as of 27 Oct 2026.
What are the best alternatives to Unblu?
As of 27 Oct 2026, the panel rates Zendesk (3.5/5), HubSpot Service Hub (3/5) and Crisp (3/5) highest among the other 32 Customer Service & Helpdesk products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is Zammad (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Unblu alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 27 Oct 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Legal entity, Data residency. Not confirmed on the vendor’s own pages as captured.
- Weak sourcing — Subprocessors. US-provider exposure applies to the GCP and IBM Financial Services Cloud deployment options, while the Swiss sovereign option is hosted by T-Systems Schweiz AG; the pages do not name the contracting legal entities of the US parents.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- We found no public information on pricing on the pages we read (unblu.com, unblu.com/en/imprint, unblu.com/en/security-compliance, docs.unblu.com/latest/knowledge-base/guides/conceptual/queue-dispatching.html, docs.unblu.com/latest/knowledge-base/configuration/conversations/queue-configuration.html, unblu.com/en/platform/live-chat and 6 more). If the vendor publishes it somewhere else, send us the page. Know more? Tell us
- 17 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 7 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 data facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 1 hosting fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 1 integrations fact could not be confirmed on the vendor’s page as captured and was left out of this page and of the panel’s material. Know more? Tell us
- 2 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
Sources (12)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page www.unblu.com Checked 27 Oct 2026 Details →
- 2 Imprint — found from the homepage www.unblu.com Checked 27 Oct 2026 Details →
- 3 Security / trust page — found from the homepage www.unblu.com Checked 27 Oct 2026 Details →
- 4 Ticketing, queues & SLA — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →
- 5 Ticketing, queues & SLA — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →
- 6 Channels in one queue — found from sitemap www.unblu.com Checked 27 Oct 2026 Details →
- 7 Channels in one queue — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →
- 8 Knowledge base & deflection — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →
- 9 Knowledge base & deflection — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →
- 10 Customer data protection — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →
- 11 Integrations & API — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →
- 12 Integrations & API — found from sitemap docs.unblu.com Checked 27 Oct 2026 Details →