Every question, answered in full.

It overlaps with one, and that is not how it is built. A helpdesk organises messages into tickets. Resolivo models the situation behind the message — who the customer is, what they bought, what was promised, what is broken, who internally owns it and whether the relationship is holding up. If what you need is a shared inbox with ticket numbers, there are cheaper products that do exactly that well.

Roughly five to a hundred people, with anywhere from two to twenty handling customers. Below that a shared mailbox genuinely works. Above it you will start wanting things this deliberately does not do — workforce management, call-centre routing, enterprise ITSM. The sweet spot is a company that has outgrown the mailbox and does not want a contact centre.

No. You connect the shared mailbox they already write to, with its history. Asking customers to learn a new address is a migration cost paid entirely by them, and it is the most common reason a helpdesk rollout stalls.

An afternoon. Connect the mailbox, bring in your customers from whatever you have — a CRM, a CSV, a spreadsheet — point it at your existing help content, and say who handles what. Customer health needs a few weeks of history before it says anything honest, and the product shows it as insufficient rather than guessing.

The connected model underneath: a customer has contacts, conversations, cases, purchases, invoices, promises, entitlements and a health state, and each of those is a real record with a real relationship to the others. It is what lets the product answer a question nobody thought to record the answer to, such as which customers renewing this quarter have an unresolved complaint.

Only if you turn that on, only for categories you choose, and never for refunds, cancellations, contract changes, account access, complaints or anything involving sensitive data — those are excluded structurally rather than by a setting. The recommended starting point is suggestions only, and before you widen it you can see how it would have handled real past cases.

It answers from records and verified knowledge rather than from its own recollection. Facts like a renewal date or a payment status are read from fields with sources, every answer names the records behind it, and when it finds conflicting information it says so and escalates instead of picking a side. Confident invention about a real customer is the worst possible failure in this category and the design is arranged around preventing it.

No. Questions run with the identity of whoever is asking, through the same permission checks as every screen, so there is no separate AI permission model to drift out of step. In the customer portal it answers as that customer — their own account and published knowledge only.

Content is treated as data, never as instruction. Text inside an inbound message, an attachment or an imported article describes the situation; it cannot change how the assistant behaves. This matters more here than in most products, because in a support system anybody who can email you can put text into it.

No, and doing so would be a mistake. Contacts, companies, relationships and opportunities belong to your customer record system. Resolivo owns cases, issues, resolutions and service health, references the rest, and writes service health back so your commercial team sees support reality on the record they actually use.

No. It can raise an approval request to the right person with the amount and evidence attached, and once approved the financial action happens in your finance system where it is recorded properly. Resolivo never moves money, and that boundary is not configurable.

Related cases are grouped into an incident, so you communicate once rather than fourteen times, and when it is fixed one action updates every affected case. If the same underlying fault causes several incidents, that becomes a problem with a countable cost — which is usually what it takes to get a root cause prioritised.

No. There is no keystroke tracking, no time-online, no idle detection and no hidden per-person scoring, and none of it is built. Measurement is on service outcomes — commitments kept, problems resolved, workload carried — and the acceptable use policy forbids using the product for surveillance.

Because in our experience customers rarely leave over a difficult problem. They leave because somebody said Friday and Friday passed in silence. A commitment made in a reply is usually the least tracked thing in a support system, so here it is a first-class object with an owner and a due time — and it shows on the customer's portal, which most companies find uncomfortable and which is exactly why it works.

No configuration of any software makes an organization compliant with anything, and a product claiming otherwise would be doing you harm. What Resolivo gives you is the machinery — retention that actually expires, an audit trail, sensitive-case handling, consent respected rather than assumed, and a clear controller-processor split. The obligations remain yours.

You are. The people who contact your support team are your data subjects; we process their data on your instructions. That split decides who has to answer a subject access request from one of your customers, and the answer is you. We will help you produce what you need to answer it.

Per team member per month — somebody who works cases. Customers, their contacts and colleagues who only approve the occasional internal action are never counted. Nothing is charged per conversation, per ticket, per AI request or per automation.

No, on any tier. Charging per AI request means your team rations asking, which defeats the purpose, and it means a busy month costs more precisely when you can least afford it. Which model handles which task is our problem and is not a line on your bill.

Yes, as a matter of course rather than as a negotiation. Cases, conversations, customer records and knowledge are exportable on every tier, throughout the term and during any wind-down. A support platform that makes leaving difficult has made its problem into yours.

Not in the product. Telephony is a genuinely different system with genuinely different complexity, and a shallow version would make this worse for the companies it is for. You can record that a call happened and what was promised on it, which is the part that matters for the case.

It will work, and it is not what this is built for. This is shaped around external customers — entitlements, renewals, relationships, commercial value. Internal service management has different priorities, and enterprise ITSM is explicitly not something we are trying to be.

Conversation history from the mailbox comes with the connection. Migrating years of closed tickets from another helpdesk wholesale is usually not worth doing — the value is in the current conversations and the customer history, and a large import of stale tickets mostly makes search worse.

No. It renders inside your own site, under your domain and your design. A customer bounced to a vendor-branded support site is a customer wondering who they are actually dealing with, and for a small company that impression is expensive.

That is the real risk with any support tool, and it is a usability question rather than a feature one. The product is arranged so that the path of least resistance — replying, assigning, promising — is inside it, and so that the daily view shows seven customers who need you rather than a queue of 247.