Customer Service & Helpdesk
LivePerson
Provenance unknown Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by LivePerson, Inc. · www.liveperson.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.
LivePerson at a glance
- Vendor
- LivePerson, Inc.
- Headquarters
- Not stated on the vendor’s pages as of 3 Nov 2026
- Data hosting
- Not stated on the vendor’s pages as of 3 Nov 2026
- Free plan
- Not stated on the vendor’s pages as of 3 Nov 2026
- Panel verdict
- The AI panel rates LivePerson 3/5, the mean of 6 judges. LivePerson Conversational Cloud earns its strongest scores on integrations and omnichannel, both clustering at 6 to 7. how scores are made
- As of
- Vendor pages captured 3 Nov 2026; evaluated by the panel 4 Nov 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
LivePerson Conversational Cloud earns its strongest scores on integrations and omnichannel, both clustering at 6 to 7. Judges credit out-of-the-box connectors for Facebook Messenger, Google My Business, Apple Messages for Business, LINE and SMS via Twilio, voice with transcripts and recordings in one agent workspace, REST APIs with published rate limits, and a Salesforce package that shows and creates CRM records inside the conversation. Ticketing core sits at 4 to 5 because the queue and wait-time APIs are documented as part of a legacy chat product facing deprecation. The genuine splits are knowledge and self-service and customer data protection, both spanning 4 to 7. On knowledge, higher scores reward articles served to consumers by bots and agent-side recommendations; lower scores rest on captured pages showing no public help centre or deflection reporting. On data protection, the top score of 7 prizes an erasure API documented to unusual depth, while the bottom of 4 weighs unstated guardrails: data processing agreement, retention rules, audit log. Sovereignty scores span 0 to 0 — no hosting, contracting-entity or subprocessor facts were captured.
Speaks for it
- Erasure is documented end to end: a Personal Data Deletion API with four scopes, execution within 30 days and a five-day cancellation window.
- Voice and messaging land in one agent workspace, with transcripts, recordings and context-preserving warm transfers.
- The developer centre documents REST APIs with published rate limits, a webhooks notification service and a connector sample app.
- Agents see and create Salesforce contacts, leads, accounts and opportunities inside the conversation, with transcripts stored in the CRM.
- KnowledgeAI articles carry validity windows and three restorable backup versions, and bots serve them to consumers.
Held against it
- The queue-state and wait-time APIs are documented against a legacy chat product facing deprecation, with a replacement the captured pages do not detail.
- The Salesforce sync runs one way, from Conversational Cloud to Salesforce only, and the widget is not Lightning-ready.
- We found no public information on a data processing agreement, automatic retention rules, an audit log or agent role permissions.
- We found no public information on an email channel or a customer portal where requesters see their own tickets.
- Deletion requests are capped by default at 100 per calendar month, changeable only through the account team, and the API is documented as not meant for mass deletion.
Best for
- You bring voice and messaging together and want transcripts, recordings and context-preserving warm transfers in a single agent workspace.
- You build custom integrations and want documented REST APIs with published rate limits, a webhooks notification service and a connector framework with a sample app.
- You must run GDPR erasure through a documented API with defined scopes, a 30-day execution window and a cancellable grace period.
- Your Salesforce-first agents need to view and create contacts, leads, accounts and cases without leaving the conversation.
Avoid if
- You manage your team against SLA policies with breach warnings, priorities and escalation chains; the captured pages document wait-time histograms against legacy endpoints, not managed SLAs.
- You need two-way CRM sync; the Salesforce integration transfers data one direction only, from Conversational Cloud to Salesforce.
- You expect high volumes of erasure requests; the API is documented as not meant for mass deletion and defaults to 100 requests per calendar month.
- You want voice bots and messaging bots in one bot group; the pages state transfers between them are not supported.
The scores
| Criterion | Panel median |
|---|---|
| Ticketing, queues & SLA | 2.5 of 5 |
| Channels in one queue | 3 of 5 |
| Knowledge base & deflection | 3 of 5 |
| Customer data protection | 3 of 5 |
| Integrations & API | 3 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 — Not a ticketing tool: requests stay in a shared mailbox or chat with no ticket, owner or status of their own.
3 — Tickets with assignment, a status and a conversation history, worked from a shared inbox with views or filters.
5 — Tickets routed by rules or automations to teams or agents, priorities and statuses, SLA targets or response-time reporting, and search across tickets.
8 — Business-hours-aware SLA policies per queue or customer with breach warnings and escalation, macros and triggers, merge and split, skills- or load-based assignment, 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
Conversations route by skill and operational APIs report current queue size, available slots and maximum wait time per skill, with a histogram of visitor wait time before an agent replies — but both wait-time APIs are flagged as belonging to a legacy chat product with limited support and future deprecation, and the ticketing system itself is described as a legacy feature. I found no public information on priorities, breach warnings, escalation, or first-response and resolution reporting by agent and queue, which is what I would need to hold my team to an SLA. 2 3 8 10 11
The Agent Advocate
Skill-based routing is real — conversations transfer to a skill, and current queue size, available slots and the wait time before an agent replies are exposed per skill — but the captured pages themselves flag both queue APIs as legacy chat facing deprecation, and the ticketing system is described as a legacy feature for legacy accounts. I found no public information on macros, merge and split, escalation on breach, or first-response and resolution reporting by agent and queue. What is documented is wait-time histograms, not managed SLAs. 2 3 8 9 11
The Data Protection Officer
Work is routed and measured around skills: conversations transfer between skills, agents resume and close them, queue size and maximum wait are reported per skill, and a histogram gives the distribution of wait time before an agent replies — though the captured pages state those queue and SLA APIs belong to a legacy chat product with a recommended replacement. Conversation search via the Engagement History and Messaging Interactions APIs is documented. I found no public information on priorities, escalation chains or business-hours SLA policies. 2 3 8 11
The Shop Operator
Conversations are routed by skill — agents transfer to a different skill, and knowledge rules are scoped to skills and agent groups — with response-time reporting in the form of a queue-wait histogram by skill and group plus live queue metrics like queue size, available slots and max wait. But those queue and SLA endpoints are documented against a legacy chat product slated for deprecation, and we found no public information on SLA policies per queue, breach warnings, or merge and split of conversations. 2 3 7 11
The Integrator
Conversations are routed and worked by skill — transfer to a different skill, open/closed states, read and typing indicators — and the developer pages expose queue depth, max wait time and a wait-time histogram per skill. But both queue-measuring APIs are described as part of a legacy chat product that receives limited support and will be deprecated, with a replacement messaging metrics API the captured pages do not detail. We found no public information on priorities, escalation, or merge and split; "ticketing" itself appears only as a legacy-account feature. 2 3 5 9 11
The Skeptic
Routing to skills is real — conversations transfer to a skill, rules are scoped by skill, and queue depth plus wait-time histograms exist per skill and agent group — but the documentation itself states the queue-state and SLA-histogram endpoints relate to a legacy chat product that will be deprecated, and the ticketing system is valid only in legacy accounts. We found no public information on SLA policies with breach warnings, escalation, merge and split, priorities, or agent-facing ticket search. 2 3 5 9
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 — No customer channel of its own; the product only works on tickets entered by hand or by another system.
3 — Email turned into tickets, with a web form or one further channel.
5 — Email, a web form or portal and live chat or a messenger landing as tickets in one inbox, with the customer's earlier conversations visible to the agent.
8 — The above plus telephony integration with call logging, at least one messenger (WhatsApp or similar) with its consent handling stated, social channels, and a customer portal where a requester can see their own tickets — all in one history.
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
Voice and messaging meet in one agent workspace, with real-time and post-call transcripts and recordings alongside messaging, warm transfers that preserve context, and out-of-the-box connectors for Facebook, Apple Messages for Business, Google, LINE and SMS via Twilio plus a connector API for more. I found no public information on email or a customer portal as channels, or on messenger consent handling. 1 4 5 11
The Agent Advocate
Facebook Messenger, Apple Messages for Business, LINE, Google, SMS via Twilio and voice all land in Conversational Cloud, with voice transcripts and recordings in the agent workspace and warm transfers that preserve context. But the pages also state voice bots and messaging bots cannot transfer to each other, and I found no public information on an email channel, a customer portal where a requester sees their own tickets, or messenger consent handling. Channels converge impressively, yet not into one seamless conversation. 1 4 5 11
The Data Protection Officer
Facebook, Google My Business, Apple Messages for Business, LINE and SMS connectors land in the same Conversational Cloud, and voice is genuinely in one history — call recordings and text transcripts are available in the Agent Workspace and warm transfers to human agents preserve context. I found no public information on email as a channel, a customer portal where a requester sees their own tickets, or stated consent handling for messengers. 1 4 5 11
The Shop Operator
Plenty of channels land in Conversational Cloud — Facebook Messenger, Google, Apple Messages for Business, LINE and SMS via Twilio out of the box, plus voice with transcripts and recordings in the agent workspace, and a Connector API to build more — and context survives a warm transfer from voice bot to human, including a Transfer to Messaging step. But we found no public information on WhatsApp, email, or a customer portal where a requester sees their own history, and voice and messaging bots cannot be mixed in one bot group, so channel is not yet an implementation detail. 1 4 5 11
The Integrator
Messengers land as conversations via out-of-the-box connectors — Facebook Messenger, Google My Business, Apple Messages for Business, LINE, SMS via Twilio — and voice runs through the same Agent Workspace with real-time and post-call transcripts and recordings, plus a voice-to-messaging transfer. Agents work one conversation with message state and typing indications. We found no public information on an email channel, a customer portal where a requester sees their own tickets, or how messenger consent is handled. 1 4 5 11
The Skeptic
Out-of-the-box connectors for Facebook, Google My Business, Apple Messages for Business, LINE and SMS via Twilio, plus a Connector API for WeChat, Viber and Slack, land in Conversational Cloud, and voice conversations with transcripts and recordings appear in the same Agent Workspace with context preserved on warm transfer. We found no public information on a customer portal, an email channel, or consent handling for any messenger, and no statement that all channels share one queue and one history. 1 4 5 11
Knowledge base & deflection
panel disagrees
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 or self-service of any kind; the product is a ticket inbox only.
3 — A knowledge base or FAQ with articles, internal or public, that agents can link in replies.
5 — A searchable public help centre with categories and its own branding, draft and publish states, and agents able to insert or suggest an article in a reply.
8 — Article suggestions to the customer before they submit and to the agent while they answer, multilingual articles, review dates or versioning 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
Articles carry titles, summaries, categories and tags with validity windows and automatic version backups, agents receive inline recommendations scoped by skill and agent group, and bots serve articles to consumers including LLM-enriched answers on voice. I found no public information on deflection reporting, multilingual articles, or review dates for stale content, so I cannot tell which articles actually prevent tickets. 5 6 7
The Agent Advocate
Articles carry titles, summaries, categories and tags, sit disabled until enabled, can be scheduled with valid-from and valid-to dates, and keep three restorable backup versions; Conversation Assist recommends answers to agents mid-conversation, and bots serve articles straight to consumers. That is genuine deflection machinery. I found no public information on multilingual articles, article-level deflection reporting, or a branded public help centre, and query enrichment is documented as English-only. 5 6 7
The Data Protection Officer
KnowledgeAI treats articles as managed content: categories, tags and intent qualifiers, AI search across all article fields, automatic back-up versions that can be restored, validity windows in UTC, and knowledge bases that can be public or private; Conversation Assist recommends articles to agents mid-conversation, including generatively enriched answers. I found no public information on multilingual articles or on reporting that shows which articles actually deflect tickets. 5 6 7
The Shop Operator
Knowledge is a managed asset here: articles with categories, tags and intents, automatic back-up versions you can restore, validity dates, recommendations surfaced to agents mid-conversation via Conversation Assist, and articles served to consumers by bots before an agent is ever involved — that is deflection working on both ends. We found no public information on a branded public help centre or on reporting that says which articles actually deflect, so I cannot see December's ticket count fall against a number. 5 6 7
The Integrator
KnowledgeAI offers articles with categories, tags, enabled/disabled states, valid-from scheduling and a three-version restore history, and Conversation Assist recommends articles to agents inside conversations, scoped by skill and agent group, with LLM-enriched answers. Everything captured serves the agent side. We found no public information on a public help centre with its own branding, suggestions to a customer before they submit, or reporting on which articles deflect contacts. 6 7
The Skeptic
KnowledgeAI is documented in detail: articles with categories, tags and intents, activation windows, automatic version backups with restore, and search across all content fields; Conversation Assist then recommends articles to agents inside conversations, optionally enriched by a large language model. We found no public information on a branded public help centre, suggestions to the customer before they submit, multilingual articles, or reporting on which articles deflect. 6 7
Customer data protection
panel disagrees
Show reasoningHide reasoning
How this is scored
A ticket archive is personal data written by the data subject. Retention, deletion, access control, subject rights under DSGVO, and what the vendor does with attachments — judged on what the product documents it executes.
0 — The vendor's own terms state that ticket content is used for purposes beyond providing the service, or that a data processing agreement is not offered.
3 — A privacy policy and a data processing agreement (DPA) offered, with agent roles that limit what an agent can do.
5 — A DPA published or signable online, agent roles and group- or queue-level visibility, and deletion of tickets or of a requester's data documented in the help centre.
8 — Automatic retention or deletion rules per queue or data category, attachment handling stated, an audit log of agent access or changes, documented support for access and erasure requests, and 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
Erasure is properly engineered: a documented right-to-be-forgotten API deletes transcripts, attachments and survey free text within thirty days with a five-day cancellation window, ticket metadata is masked rather than deleted, and PII and PCI can be redacted from voice transcripts and recordings. I found no public information on a data processing agreement, agent roles, automatic retention rules, or an audit log, so the guardrails around the archive itself are unstated. 5 8 9
The Agent Advocate
The erasure story is documented down to the API call: deletion by chat engagement, messaging conversation, consumer or ticket, a five-day cancellable grace period, execution within 30 days, masking rather than deletion for legacy tickets, and PII and PCI redaction of voice transcripts and recordings. It is capped at 100 requests a month by default and redaction is set up through your representative. I found no public information on a data processing agreement, agent role permissions, retention rules, or an audit log. 5 8 9
The Data Protection Officer
The erasure machinery is documented to a standard I rarely see: an API built for the GDPR right to be forgotten with four scopes (chat engagement, messaging conversation, consumer, ticket), a five-day cancellable grace period, execution within 30 days, permanence stated outright, attachments and hosted files in scope, and ticket metadata masked rather than deleted — a limitation the documentation itself discloses; PII and PCI can additionally be redacted from transcripts and recordings via a representative. What the captured pages do not show me is retention rules that execute on a schedule, an audit trail of which agent read which conversation, a published processing agreement, or support for access requests as opposed to erasure. 5 8 9
The Shop Operator
Erasure is genuinely built: a Personal Data Deletion API for the GDPR right to be forgotten that removes transcripts, hosted files, survey free text and PII within 30 days, with a five-day cancellation window, ticket metadata masked and attachments deleted. PII and PCI redaction from transcripts and recordings is documented, though set up through a representative. We found no public information on a data processing agreement, agent roles and visibility, audit logs, or automatic retention rules. 5 8 9
The Integrator
Erasure is documented end to end: a Personal Data Deletion API covering chat engagements, messaging conversations, consumers and legacy tickets, deletion within 30 days, a five-day cancellation window, exact masking semantics, attachment handling and a monthly request limit. PII and PCI redaction of voice transcripts and recordings is available, set up through the LivePerson representative. We found no public information on a published data processing agreement, agent role visibility, automatic retention rules or an audit log. 5 8 9
The Skeptic
Erasure is documented to a depth few reach: a Personal Data Deletion API covering conversations, chat engagements, consumers and legacy tickets, executing within 30 days with a cancellable grace period, masked fields, deleted attachments and a stated monthly request limit of 100. Redaction of personally identifiable and payment card information from voice transcripts exists but is only set up via a LivePerson representative, and we found no public information on a data processing agreement, retention rules, or an audit log. 5 8 9
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 — A closed tool with no API and no integrations; context is copied in by hand.
3 — A handful of named integrations or a connector service such as Zapier, or an API with basic documentation.
5 — Named integrations for common CRM, shop or collaboration tools, a documented REST API, and webhooks or triggers that call other systems.
8 — An app marketplace with maintained bidirectional integrations, customer context from other systems shown inside the ticket, SSO and 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
The Salesforce package shows CRM records inside the conversation and pushes transcripts into Salesforce on a documented sync cadence, the Connector API with webhooks, a sample app and developer guides reaches external systems, and rate limits with retry guidance are published. I found no public information on SSO, SCIM provisioning, an app marketplace, or a sandbox, and the Salesforce sync runs one direction only. 2 3 10 11
The Agent Advocate
A real Salesforce integration lets agents see and create contacts, leads, accounts and cases inside the conversation and stores transcripts in the CRM, though the sync is documented one-way, the widget is not Lightning-ready, and it caps at five widgets. The REST APIs are documented with authentication, webhooks, rate-limit behaviour and a sample connector app, and the Connector API and Web View integration open payment systems and channels like WeChat. I found no public information on SSO, SCIM provisioning, or an app marketplace. 2 5 10 11
The Data Protection Officer
A public developer centre documents a Salesforce integration that surfaces contact, lead, account and opportunity data inside the conversation and stores transcripts in the CRM, plus a Connector API with a webhooks notification service, a sample app, and rate limits with retry guidance spelled out. The Salesforce sync is stated as one-way from Conversational Cloud to Salesforce, and I found no public information on an app marketplace or on SSO and SCIM provisioning. 3 10 11
The Shop Operator
Salesforce context sits inside the conversation — agents see and create contacts, leads, accounts and opportunities right from Conversational Cloud and the transcript is stored back in the CRM, which is my order-in-front-of-the-agent test. The REST APIs are documented with webhooks, stated rate limits and a connector sample app. But the CRM sync is explicitly one-way into Salesforce on a 24-hour data SLA, the package is not Lightning-ready, and we found no public information on an app marketplace or SSO and SCIM provisioning. 2 10 11
The Integrator
The developer center is the real thing: multiple documented REST APIs with parameters, response codes, authentication options and explicit rate limiting (HTTP 429 with a one-second retry recommendation), a webhooks notification service, a connector framework with sample app and demo tool, out-of-the-box channel connectors, and a vendor-maintained Salesforce package that shows and creates CRM records inside the conversation. The sync into Salesforce is explicitly one-way from Conversational Cloud, and we found no public information on retry behaviour for webhook deliveries, SSO or SCIM provisioning, a sandbox environment or an app marketplace. 2 3 5 10 11
The Skeptic
The developer documentation is deep: a Salesforce integration with records visible and creatable inside conversations (the sync itself one-way from Conversational Cloud to Salesforce), a Connector API with required webhooks for messaging channels, and rate limits published with throttle codes and retry advice. We found no public information on an app marketplace, SSO or SCIM provisioning, or a sandbox. 2 10 11
European sovereignty
panel opinion
n/r
n/r
n/r
n/r
n/r
n/r
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. Dimensions the evidence does not establish are unknown, not non-EU.
0 — Proven non-EU on every dimension the evidence covers: non-EU vendor and contracting entity and non-EU hosting, with no EU option stated.
3 — One European element proven — an EU hosting option, an EU contracting entity or EU representative, or a published DPA — with the rest of the chain unstated.
5 — EU hosting stated as standard or selectable and an EU contracting entity or EU representative, with a DPA offered; the subprocessor chain is unstated or partly non-EU.
8 — EU or DACH hosting with a named data-centre provider, EU contracting entity, subprocessor list published with locations, 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 not rated — no public information
I found no public information on where the conversation archive is hosted, which entity contracts, or which subprocessors touch the data. The sole European element in the captured pages is a statement that the Voice feature and architecture is GDPR-compliant, which does not establish hosting, contracting-entity or subprocessor facts. 1 5
The Agent Advocate not rated — no public information
We found no public information on where the conversation archive is hosted, the contracting entity, the subprocessor chain, or whether vendor support can read customer data — no sovereignty attributes were on record for this vendor. The only adjacent facts are a GDPR-compliance statement for the voice architecture and an acquisition by SoundHound AI, which prove no dimension either way. I am reporting this as unevidenced rather than guessing. 1 5
The Data Protection Officer not rated — no public information
I found no public information establishing where the conversation archive is hosted, which entity the customer contracts with, or which subprocessors touch the data — no sovereignty attributes were on record from the captured pages. The GDPR compliance statement for the voice feature and the right-to-be-forgotten API address data protection behaviour, but neither proves a hosting location, an EU entity or a subprocessor chain, so no dimension is established. 1 5 8
The Shop Operator not rated — no public information
We found no public information on where the ticket archive is hosted, the contracting entity, subprocessor locations, or whether vendor support can read customer data — the sovereignty record is empty. The only European references in the captured pages are a GDPR-compliance statement for a voice feature and a deletion API built for the right to be forgotten, which is compliance capability, not proof of EU hosting or an EU contracting entity. 1 5 8
The Integrator not rated — no public information
No sovereignty attributes are on record for this vendor: the captured pages state nothing about where the conversation archive is hosted, which entity the contract sits with, or which subprocessors touch the data. The GDPR compliance statement for the voice feature and the erasure API speak to data handling, not to the chain of custody. We found no public information on hosting location, contracting entity or subprocessor locations. 1 5 8
The Skeptic not rated — no public information
We found no public information on where the conversation archive is hosted, which entity a buyer contracts with, or which subprocessors touch the data; the only statement in the captured pages is that the voice feature is GDPR-compliant, and the acquisition by SoundHound AI is noted without any location detail. Reported as unknown rather than non-European. 1 5
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 public "from" price or one priced tier, per agent or flat.
5 — Per-agent prices public for the main tiers with the billing period stated and the main features per tier listed.
8 — Every tier and add-on priced publicly with per-agent maths, telephony or messenger costs and light-agent or contact limits given, 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
A pricing page exists and is linked from the homepage, but the captured material gives no price figures, tier names, billing periods or per-agent maths. I cannot compute an annual invoice for my twelve agents from the public pages I read. 1
The Agent Advocate
A public pricing page is linked from the homepage, but no price figure, tier, billing period, or agent-count maths was captured anywhere. Several capabilities — redaction set-up, the monthly deletion-request threshold, the Voicebase product — route through your account team or representative. I could not begin to compute an annual invoice from the captured pages. 1 5 9
The Data Protection Officer
The captured homepage shows only a 'Pricing' link with no figures — no tiers, per-agent costs, billing periods or VAT treatment appear anywhere I read — and documented capabilities such as PII redaction and post-call analysis route the buyer to a LivePerson representative. A support lead cannot compute an annual invoice from the captured pages. 1 5
The Shop Operator
The captured homepage carries a Pricing link, but we found no public information on any price figure, tier, feature list or billing term in the captured pages, so a support lead cannot compute an annual invoice for their agent count. Configuration items such as PII redaction are also routed through a representative conversation. 1 5
The Integrator
The site carries a "Pricing" link, but the captured pages contain no price figures, per-agent maths, billing periods or tier feature lists. A support lead cannot compute an annual invoice for their agent count from the public information we hold. 1
The Skeptic
The captured homepage carries a Pricing link and states a pricing page exists, but we found no public information on any price, tier, per-agent figure, billing period or add-on cost in the pages read, and redaction of voice transcripts is likewise arranged via a representative. A support lead cannot compute an annual invoice from these pages. 1
Questions about LivePerson
Is LivePerson European?
Not determined: the vendor’s pages as captured do not say where LivePerson is based.
Where does LivePerson store data?
Not stated on the vendor’s pages as of 3 Nov 2026.
Does LivePerson have a free plan?
Not stated on the vendor’s pages as of 3 Nov 2026.
What are the best alternatives to LivePerson?
As of 4 Nov 2026, the panel rates Zendesk (3.5/5), HubSpot Service Hub (3.5/5) and Deskpro (3.5/5) highest among the other 35 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: LivePerson alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 3 Nov 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- 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.
- 2 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
- 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
Sources (11)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor page www.liveperson.com Checked 3 Nov 2026 Details →
- 2 Ticketing, queues & SLA — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 3 Ticketing, queues & SLA — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 4 Channels in one queue — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 5 Channels in one queue — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 6 Knowledge base & deflection — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 7 Knowledge base & deflection — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 8 Customer data protection — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 9 Customer data protection — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 10 Integrations & API — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →
- 11 Integrations & API — found from sitemap developers.liveperson.com Checked 3 Nov 2026 Details →