Customer Service & Helpdesk
Dixa
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 Dixa ApS · dixa.com
Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Dixa is a customer service and helpdesk product from Dixa ApS. Its strongest showing is omnichannel, scoring 6-8: the vendor states that chat, email, phone, WhatsApp and social conversations land in one place with full history so customers never repeat themselves. Ticketing core scores a uniform 4 — no-code routing by skill, language, priority and VIP status is stated, alongside automatic QA scoring, but the judges found no public information on SLA timers, escalation chains or ticket search. Knowledge and self-service sits at 4-5: the Mim AI agent's round-the-clock deflection is evidenced, though not as a number. Weakest are pricing transparency, a flat 0 with no per-agent price or tier published, and customer data protection at 0-1, with no public information on retention, deletion paths or a data-processing agreement. Integrations scored 2-3 on the one named partner, Shopify; the vendor's sovereignty attributes are listed as none on record; and the judges' scores sit in narrow bands on every criterion.
Speaks for it
- Chat, email, phone, WhatsApp and social conversations are stated to land in one place with full history so customers never repeat themselves
- Routing rules by skill, language, priority, VIP status and custom rules are built visually without code
- Conversations are scored automatically against your QA criteria, with trends and coaching opportunities surfaced
- The Mim AI agent resolves routine chat and email inquiries 24/7, handling refunds, tracking and order changes in 30+ languages
- Shopify orders are handled directly by the AI agent, with orders, past conversations and loyalty status on one agent screen
Held against it
- No per-agent price, tier, billing period or add-on figure appears in the public information
- We found no public information on retention periods, deletion paths, audit logs or a data-processing agreement
- We found no public information on SLA timers, escalation chains or search across ticket bodies
- Shopify is the one named integration, with no public information on a documented API, webhooks or SSO
- The vendor's sovereignty attributes are listed as none on record, with no public information on hosting location or subprocessors
Best for
- You run a Shopify store and want an AI agent handling refunds, tracking and cancellations with order context on the agent's screen
- Your team works across chat, email, phone, WhatsApp and social and needs every conversation in one history
- You want routine chat and email inquiries resolved 24/7 in 30+ languages, with handoff to humans in full context
- You want reply suggestions, on-the-fly translation and knowledge surfacing built into the agent's conversation screen
Avoid if
- You need public per-agent prices to compute an annual invoice or compare tiers before engaging sales
- Your procurement requires published retention periods, a deletion path and a signable data-processing agreement before adoption
- Your security review requires a stated hosting location or subprocessor list, and the sovereignty attributes on record are none
- Your operation depends on SLA timers, breach warnings and escalation chains, for which we found no public information
The scores
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
No-code routing by skill, language, priority and VIP status is evidenced, and automatic conversation scoring gives a form of performance reporting. But I found no public information on SLA timers, breach warnings, escalation chains, or search across ticket bodies — without those I can route the work but not manage it against a promise. 1
The Agent Advocate
Routing is the strong suit — skill, language, priority and VIP rules built visually beat manual triage — but we found no public information on a status model, SLA timers, breach warnings, or search across ticket bodies. I judge a queue engine by whether I can find the old thread on the hundredth reply, and none of that is evidenced. 1
The Data Protection Officer
Routing is genuinely rules-based — skill, language, priority, VIP status and custom rules built visually — which is past manual triage. I found no public information on SLA timers, the status model, escalation chains, merge and split, or search across ticket bodies, which is what separates a managed queue from a labelled inbox. 1
The Shop Operator
Routing is the strong part: rules by skill, language, priority and VIP status built without code, plus automated conversation scoring — but nothing captured shows SLA timers, breach warnings, a status model, or search. In December I need to pull the ticket from a half-remembered order number, and we found no public information on SLA policies, escalation chains, or ticket search. 1
The Integrator
No-code routing by skill, language, priority and VIP status with custom rules is evidenced, and every conversation is scored automatically against QA criteria. We found no public information on SLA timers, queue management, escalation chains, macros, or ticket search, so this sits partway between manual triage and a full queue engine. 1
The Skeptic
Rules-based routing by skill, language, priority and VIP status with no-code automations is stated on the vendor page, alongside automatic QA scoring of conversations. But the engine's measurement side is invisible to a buyer: we found no public information on SLA timers, business-hours policies, escalation chains, macros, ticket merge and split, full-text search, or reporting on first-response and resolution times. 1
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
Chat, email, phone, WhatsApp and social are all stated to land in one conversation with full history, with orders, past conversations and loyalty status on a single agent screen. I found no public information on call logging, consent handling for WhatsApp, or a customer portal where a requester sees their own tickets. 1
The Agent Advocate
Chat, email, phone, WhatsApp and social are all stated to land in one conversation with one history on one screen, with the customer never repeating themselves — exactly the claim I look for. It stops short of the top because we found no public information on call logging, WhatsApp consent handling, or a customer portal where a requester sees their own tickets. 1
The Data Protection Officer
Chat, email, phone, WhatsApp and social are stated to land in one conversation with full history so customers never repeat themselves — the one-history claim is exactly what matters. I found no public information on a customer portal where requesters see their own tickets, on call logging, or on consent handling for the WhatsApp channel. 1
The Shop Operator
Chat, email, phone, WhatsApp and social are all claimed to land in one place with one full history, and the line about customers never having to repeat themselves is exactly what I judge by — WhatsApp in the same queue as everything else. What holds it back: nothing on WhatsApp consent handling, and we found no public information on a customer portal where a requester can see their own tickets. 1
The Integrator
Chat, email, phone, WhatsApp and social are stated to land in one conversation with full history, agents work from one screen, and customers are said never to repeat themselves. We found no public information on messenger consent handling or a customer portal where a requester can see their own tickets, which is what keeps this below the top. 1
The Skeptic
Five channels — chat, email, phone, WhatsApp and social — are claimed to land in one place with full history so customers never repeat themselves, which is the right shape rather than a logo wall. Still, the claim is where the page stops: we found no public information on a requester-visible portal, on consent handling for the WhatsApp channel, or on call logging for the phone channel. 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
Agent-facing knowledge surfacing is evidenced and the AI agent learns from the knowledge base across 30+ languages, but I found no public information on a public help centre, draft and publish workflow, review dates for stale content, or reporting on which articles deflect. An AI agent resolving routine inquiries implies deflection happens; whether it is a number the team can act on, the captured page does not show. 1
The Agent Advocate
Knowledge exists as fuel for the machine — articles surfaced to agents while they answer, and an AI agent that learns from the knowledge base — but we found no public information on a customer-facing help centre, editorial workflow, versioning, or reporting on which articles deflect. Organising answers is not the same as reducing tickets, and only the AI-agent claim touches the second. 1
The Data Protection Officer
A knowledge base evidently exists — the AI agent learns from it and the copilot surfaces articles to agents while they answer — and routine inquiries are resolved without human intervention, which is deflection in effect. I found no public information on a searchable help centre customers browse themselves, editorial workflow, stale-content review, or deflection reporting. 1
The Shop Operator
Deflection is evidenced where I care most: the Mim agent resolves refunds, tracking and order changes on chat and email around the clock and hands off with full context, meaning tickets that never get created. But the knowledge base appears only as fuel for the AI — we found no public information on a public help centre, article workflow and versioning, or reporting on which content actually deflects. 1
The Integrator
Knowledge articles are surfaced to agents while they answer, and the Mim AI agent learns from the knowledge base to resolve routine inquiries without human intervention, which is genuine deflection-adjacent behaviour. We found no public information on a customer-facing help centre, editorial workflow, versioning, or reporting on which articles deflect. 1
The Skeptic
The knowledge base is evidenced only from the inside out: Co-Pilot surfaces relevant articles to agents while they answer, and the Mim agent learns from the knowledge base and resolves routine chat and email inquiries around the clock — deflection in fact, though never reported as a number. We found no public information on a public help centre, editorial workflow with review states, stale-content flagging, or deflection reporting a team could act on. 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
The captured page shows nothing that executes on data protection: I found no public information on retention periods, deletion of a requester's data, agent roles or queue-level visibility, audit logging, or a published data-processing agreement. 1
The Agent Advocate
The captured pages carry no retention period, no deletion path, no agent roles or queue-level visibility, no audit log, and no published data-processing agreement. A ticket archive is personal data written by the data subject, and on what executes rather than what is promised, we found nothing here that executes. 1
The Data Protection Officer
This is where a ticket archive becomes a liability and I found no public information on any of it: no retention period, no executable deletion path, no published DPA, no role or queue-level visibility model, no audit log of who opened which ticket, and nothing on attachment handling or vendor support access to customer instances. 1
The Shop Operator
We found no public information on retention periods, deletion of a requester's data, agent roles and queue visibility, a DPA, or audit logging — the capture shows none of it. A ticket archive is customers writing about themselves, and with this much silence I cannot evidence any protection that actually executes. 1
The Integrator
We found no public information on retention periods, deletion paths, agent roles and queue-level visibility, audit logs, attachment handling, or a published data-processing agreement. Nothing this criterion needs is visible on the captured page, which by the treatment of absence maps to the lowest anchor value. 1
The Skeptic
Nothing on the captured page touches this: we found no public information on retention periods, a deletion path for a requester's data, agent roles or queue-level visibility, audit logs of who opened which ticket, attachment handling, or a signable data-processing agreement. By the published definitions for this criterion, that state of the evidence is the floor. 1
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
Shopify is a named integration, with the AI agent handling Shopify orders directly and the agent screen pulling in orders and loyalty status — real context from order systems inside the conversation. I found no public information on an API, webhooks, SSO, or rate limits, so beyond Shopify it is unclear what a buyer can connect without a sales conversation. 1
The Agent Advocate
Shopify is the one named integration, and order context surfacing inside the agent's screen is genuinely useful. We found no public information on an API, webhooks, SSO, CRM systems, or documented rate limits, so the integration story is one partner and everything else unstated. 1
The Data Protection Officer
Shopify is named — the AI agent handles Shopify orders directly — and the agent screen shows orders and loyalty status pulled from other systems. I found no public information on a documented API, webhooks, SSO, rate limits, or any integration beyond Shopify. 1
The Shop Operator
The order in front of the agent without a second login is claimed directly — orders, past conversations and loyalty status in one screen, with Shopify orders handled natively by the AI agent. Beyond Shopify nothing else is named, and we found no public information on API documentation, webhooks, SSO, provisioning, or rate limits. 1
The Integrator
Shopify order handling is named and orders, loyalty status and past conversations appear inside the agent screen, which is the customer-context piece I need when wiring in a shop. We found no public information on a documented API, webhooks, rate limits, SCIM provisioning, a sandbox, or CRM connectors — everything required to integrate Dixa into systems that predate it. 1
The Skeptic
Shopify is the one named integration, with Mim handling Shopify orders directly, and the agent screen shows orders, past conversations and loyalty status as in-ticket customer context. Beyond that single thread we found no public information on a documented API, webhooks, rate limits, SCIM provisioning or SSO — a buyer building anything around this product is guessing. 1
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
There are no sovereignty attributes on record: I found no public information on where the conversation archive is hosted, the contracting entity, named subprocessors, or vendor support access to customer data. With the subprocessor list absent from public information and hosting unstated, a buyer takes the chain on trust. 1
The Agent Advocate
Only the vendor's Danish company form suggests an EU contracting entity; hosting location, data-centre provider, subprocessors, and vendor support access to customer data are all without public information on the captured pages. For an archive full of customer conversations, that blank is not something I can weigh in the buyer's favour. 1
The Data Protection Officer
The contracting entity is Dixa ApS, a Danish company form, which points to Europe, but no sovereignty attributes are on record. I found no public information on where the archive is hosted, who the subprocessors are, or whether vendor support can open a customer ticket. 1
The Shop Operator
The contracting entity is named as Dixa ApS, but nothing captured states where the conversation archive is hosted, names a data-centre provider, or lists a single subprocessor — no sovereignty attributes are on record at all. We found no public information on hosting location, certification, or any self-hosted or private-cloud option. 1
The Integrator
The contracting entity is Dixa ApS, a Danish company form, which points to an EU footing, and no sovereignty attributes are on record either way. We found no public information on hosting location, data-centre provider, subprocessors, or whether vendor support can read customer data. 1
The Skeptic
The contracting entity is Dixa ApS, a Danish company, which is the one encouraging datum — but that is where the evidence ends. We found no public information on hosting location, the data-centre provider, any subprocessor list, certification, or whether vendor support can read customer conversations. 1
Pricing transparency
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
We found no public information on pricing of any kind — no per-agent price, no tiers, no billing period, no VAT treatment. Budgeting twelve agents against this page cannot be done; the annual invoice is a sales conversation from the first click. 1
The Agent Advocate
No tier, per-agent price, billing period, add-on, or VAT treatment appears anywhere on the captured pages. A support lead cannot compute even a rough annual invoice from this, and every tier is a sales conversation. 1
The Data Protection Officer
The captured pages carry no prices whatsoever — no per-agent figure, no tiers, no billing period. A support lead could not compute even a rough annual invoice from what is public. 1
The Shop Operator
The captured page shows no prices — no per-agent figure, no tiers, no billing period, no add-on numbers. I cannot compute an annual invoice for my agent count from anything public here. 1
The Integrator
We found no public information on per-agent prices, tier boundaries, billing periods, minimum terms, or add-ons for the channels and AI features described. A support lead has nothing on the captured page from which to compute an annual invoice. 1
The Skeptic
No price, tier, billing period, minimum term or add-on figure appears anywhere in the record; we found no public information on what an agent seat costs, which tier the AI copilot and the Mim agent belong to, or how channels like phone and WhatsApp are metered. A support lead cannot compute any part of the annual invoice from what is published here. 1
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 | Incorporated in DK ⚠ unverified | 3/3 pts | 2 Report an error |
|---|---|---|---|
| Ownership | Not determined | — | uncited Report an error |
| Data residency | Not determined | — | uncited Report an error |
| Subprocessors | Not determined | — | uncited Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 29 Sep 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. This clause names Dixa ApS as the contracting party only when the Services are used without a duly accepted Order Form; for contracted customers the excerpt does not spell out which entity signs, though no other entity is named.
- 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.
- 49 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
- 13 pricing 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
- 6 support 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
- 5 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
- 4 integrations 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
- 3 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
- 3 legal 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
- 2 hosting 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
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (11)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page dixa.com Checked 29 Sep 2026 Details →
- 2 Terms of service — found from the homepage www.dixa.com Checked 30 Sep 2026 Details →
- 3 Ticketing, queues & SLA — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 4 Ticketing, queues & SLA — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 5 Channels in one queue — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 6 Channels in one queue — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 7 Knowledge base & deflection — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 8 Knowledge base & deflection — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 9 Customer data protection — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 10 Integrations & API — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →
- 11 Integrations & API — found from sitemap www.dixa.com Checked 1 Oct 2026 Details →