Changing customer service systems: what to check before you move

Changing customer service systems is almost never a purely technical decision. It usually begins with frustration: conversations go missing, reports cannot answer management’s questions, the price has risen or the team simply dislikes the interface. The problem is that material about choosing a tool is written almost exclusively by vendors, and each one arranges the criteria to favour its product. We are a vendor too, so this article is a list of questions to ask everyone—including us. A lack of a clear answer to any one of them is information in itself.

When changing tools will help—and when the process is the problem

The most expensive migration is one in which a company moves its data, teaches the team a new interface and discovers three months later that something entirely different was hurting. Before comparing vendors, separate two things: a missing feature and a missing working rule. A tool can fix only the first.

• Changing tools will helpThere is no shared inbox, thread history or search, so the context exists only in private accounts.
• Changing tools will helpA channel customers genuinely expect is missing, or you cannot export your own data.
• The process is the problemCases stall because nobody has assigned responsibility or cover during absences.
• The process is the problemResponse times are poor because staffing misses peak hours—they will be identical in a new interface.

Here is a simple test: list five cases from the past month that went badly and add a sentence to each beginning ‘we failed because…’. If three of the five sentences end with a word describing a person, calendar or missing decision, migration is not the first step. We explain how to organise responsibility in the guide to customer service ticketing systems.

This distinction is not an excuse made by vendors. Sometimes the opposite is true: a company spends years using process to patch a tool that cannot assign cases or retrieve a six-month-old thread, in which case changing systems genuinely relieves the team. The point is simply to know which of the two situations you face.

Questions for the vendor before you decide

A demo usually shows the product at its best: a clean interface, one conversation and everything in place. The questions below deliberately concern situations absent from a demo—the end of a contract, an employee’s departure and data that must be handed over. ‘It depends’ is a reasonable answer when specific details follow.

↔ Scroll the table sideways to see all columns.

Also ask for something simple: trial access for a few days so you can perform an export yourself before signing. Ten minutes with a real file tells you more than an hour-long presentation. If the data will flow into other systems, run the same trial on the integration—we explain the practical pitfalls in the article about integrating chat with a CRM.

Add questions about the cost structure to this list, because the subscription is rarely the largest item. We break it down in the guide to how much live chat costs.

What you can migrate—and what you can never recreate

This is where vendors become most vague. The rule is simple: you can migrate anything that can be saved to a file and loaded at the other end. Anything that forms part of a running system—relationships, permissions, counters and session playback—ends with the old tool.

↔ Scroll the table sideways to see all columns.

Two things cause the most surprise. First, an export is usually a set of tabular files, not a copy of the interface—the content remains, but its order and clickable relationships disappear. Second, two systems may define first-response time differently, so comparing a pre-migration chart with a post-migration chart can be misleading. It is safer to close the old reporting period and begin a new one.

The practical conclusion: before closing the old account, download the export, open it and check whether you can read a year-old conversation without access to the interface. This is also the time to decide what you deliberately will not migrate. Migration is a good opportunity not to copy data you have no purpose or right to retain—we explain how to organise this in the article about live chat and the GDPR.

For clarity: Meetlead does not import conversation history from other tools. We assume the pre-migration archive remains with you as an export and a new history begins in the new system. We would rather say that plainly than promise an import that, in practice, would amount to pasting in a table without context.

The transition period: two tools at once

Both systems will usually operate for several weeks. That is sensible because it leaves room to retreat, but it creates one specific risk: a case everyone believes belongs to somebody else. A customer writes through the new channel, somebody replies through the old one, notifications arrive twice and the thread splits into two halves.

1. Establish one source of truth.Write down which system governs new cases and from what time. Without a date and time, the rule does not work.
2. Separate channels, not people.Move one channel at a time, not one team at a time. The same customer channel will then never be handled differently in two places.
3. Disable duplicate notifications.Keep alerts only in the authoritative system. Put the old interface into observation mode so nobody replies there out of habit.
4. Assign somebody to boundary cases.Each day, one person reviews both systems and closes threads that began before the change but returned afterwards.
5. Set a shutdown date and enforce it.A transition without a deadline can last a year. Record the day the old system becomes read-only.

Tell customers with open cases in advance too. One sentence—saying that their case will continue in the new system and giving its number—removes most misunderstandings. The widget and its copy also need a review, which we discuss in the guide to live chat on your website.

Plan your exit when you begin

The best time to agree the rules for leaving is the day before you sign a contract, not the day after deciding to cancel. At that point you still have leverage and the vendor has a reason to answer precisely. Record four things in your meeting notes.

• ExportWhich data, in what format, how often and whether you can export it yourself without contacting the vendor.
• RetentionHow long data is kept by default, whether you can shorten the period and exactly what disappears when it ends.
• DisconnectionWhat remains in the system and on your website—keys, scripts and secrets in plugin configuration.
• PermissionsWho can perform an irreversible operation and what confirmation is required.

We can answer these questions about our own product to show what specificity looks like. In Meetlead, conversation data is isolated per website and message retention is configurable. Report exports are audited, so an administrator can see who exported what. When an application is uninstalled, we show an explicit list of deleted and retained data; the operation requires a website administrator role and the current password, while the history of some channels remains read-only. On uninstall, the WordPress plugin attempts to revoke the connection remotely and removes local secrets. This isolation also means that a team supporting several brands always works in the context of one website; we explain how to organise that in our guide to supporting several websites with one team.

We do not offer this as proof that we meet every need. We offer it as an example of the level of detail you should expect from every vendor—including us. If the answer to ‘what remains after disconnection?’ fits into one vague sentence, nobody has thought it through. Ask for a written supplement before your team begins entering data into the new system.

The available features, including retention settings and exports, depend on the Meetlead plan and website configuration. Before deciding, confirm which ones your option includes—that is, after all, another question from the list above.

Migration checklist

The following list assumes the decision to move has already been made. Follow it in the order shown—the most common mistake is leaving the export from the old system until the end, when the account has already been closed.

• The reason for changing is written in one sentence and is not solely a description of an internal process.
• The export from the old system has been created, opened and checked against a year-old conversation.
• Attachments and files were downloaded before the links in the export expired.
• You know which data you are deliberately not migrating and why.
• The old reporting period is closed and differences in metric definitions are documented.
• A date and time have been set from which the new system becomes the source of truth for new cases.
• Notifications in the old tool are disabled and one person monitors boundary cases.
• Customers with open cases received a short message about the change and their ticket number.
• The new vendor’s export, retention and disconnection rules are recorded in the meeting notes.
• A date has been set for the old system to become read-only.

A successful change of systems is not one in which the new interface looks better. It is one in which, after the move, you still know who owns each case, where the pre-migration history lives and how to leave the new tool. Record those three answers before signing the contract.