Миграция клиентских диалогов заканчивается не тогда, когда импорт показывает 100 процентов. Она заканчивается, когда сотрудник открывает реальное обращение в новой системе и по-прежнему понимает, кто этот клиент, что уже произошло, кто отвечает за следующий шаг и какое сообщение нельзя отправлять повторно.
Обычно план начинается с полей и количества записей. Такие проверки нужны, но они не доказывают, что вместе с данными переехала работа службы поддержки. Статус «решено» может превратиться в «закрыто» с другим смыслом. Тег возврата может сохраниться без правила, ради которого его создали. В новой системе могут быть все сообщения, но не будет связи с клиентом, заказом, согласием или исполнителем, которые делали историю полезной.
Определите что должно остаться верным
До сопоставления полей запишите несколько условий, которые должны выполняться после перехода.
- Каждый диалог связан с правильным клиентом и его идентификатором в канале.
- Сообщения, внутренние заметки, вложения и время событий идут в правильном порядке.
- У открытой работы есть текущий владелец, состояние, срок и следующее действие.
- Согласие, отказ и источник не превращаются в обычные теги.
- Отчеты отделяют перенесенную историю от работы, созданной после запуска.
Это договор приемки. Он полезнее обещания перенести всё, потому что разные системы по-разному определяют это «всё». Текущее руководство Zendesk по экспорту показывает, насколько важен формат. CSV не включает комментарии и описания, а JSON и XML имеют другое покрытие и ограничения. Файл может быть технически исправным, но не подходить для сохранения нужной истории.
Сначала сопоставьте смысл
Не начинайте с таблицы, где статус источника просто приравнен к статусу назначения. Сначала выясните, что каждое значение запускало в прежнем процессе.
Допустим, старая система различает ожидание клиента и ожидание поставщика, а новая предлагает одно состояние «отложено». Формально сопоставление сработает. На деле исчезнет разница между обещанием клиенту и внешней зависимостью. Изменятся напоминания, сроки и отчеты, хотя импорт не покажет ошибки.
Составьте карту смысла для идентификаторов, состояний, приоритетов, тегов, назначений, связей и времени. Зафиксируйте старое и новое определение, ожидаемое поведение и доказательство корректного переноса. Старые ID лучше хранить в отдельном внешнем поле, чтобы любую запись можно было найти в источнике.
Современный объект диалога состоит не только из текста. API разговоров Intercom описывает контакты, состояние, приоритет, исполнителей, теги, пользовательские атрибуты, части диалога и связанные объекты. Документация также указывает лимит в 500 частей при получении разговора. Поэтому полноту нужно проверять явно. Успешный ответ API еще не гарантирует, что в нем вся история.
Разделите активную работу и архив
Закрытая история и текущие обращения требуют разных планов. Исторические записи можно скопировать, проверить и оставить только для чтения. Открытый диалог продолжает получать ответы, менять владельца и приближаться к сроку, пока идет миграция.
Актуальная документация Pylon показывает это на практике. Традиционный перенос через API создает исторические снимки закрытых тикетов, но не переносит открытые, потому что канал связи не переезжает вместе с записью. У другой платформы может быть иной метод, но операционный вопрос тот же. Куда придет следующий ответ клиента во время перехода?
Выберите единственную систему, которая принимает новую активность. Оставьте открытые случаи в старой системе до закрытия, перенесите их по контролируемой процедуре или переключите доставку каналов в определенный момент и сверяйте пересечение. Не позволяйте двум системам отправлять сообщения независимо. Иначе появятся дубли, разделенная ответственность и две противоречивые хронологии.
Соберите сложный набор доказательств
Пилот из аккуратных записей мало что проверяет. Включите длинный диалог с вложениями и внутренними заметками, клиента с несколькими идентификаторами каналов, открытый случай со сроком и владельцем, повторно открытое или переданное обращение, запись с согласием либо отказом и случай, связанный с заказом, компанией или лидом.
Связи проверяйте отдельно. Текущий API тикетов HubSpot рассматривает связи с контактами, компаниями и активностями как явные части записи. Если текст перенесен, а эти связи потеряны, содержание уцелело, но рабочий контекст исчез.
Для каждого примера сравните источник и назначение рядом. Проверьте число и порядок сообщений, авторство, часовые пояса, вложения, клиента, состояние, владельца, связи и следующий шаг. Затем попросите сотрудника выполнить следующую реальную операцию уже в новой системе. Внешнего сходства недостаточно. Запись должна работать.
Переключайтесь поэтапно
На время теста заморозьте определения тегов и статусов, пользовательские поля и правила маршрутизации, но не обслуживание клиентов. Сделайте полный защищенный экспорт. Прогоните набор доказательств. Импортируйте историю. Сверьте количество объектов по типам и периодам. Отдельно обработайте активную работу. Переключите каналы один раз.
В первое рабочее окно следите за ошибками импорта, обращениями без владельца, дублями клиентов, неожиданными уведомлениями и недоступными вложениями. Условие отката определите заранее. Небольшая разница в форматировании может быть допустимой. Потеря активного обращения, неверная связь с клиентом, испорченное состояние согласия или повторная отправка клиенту недопустимы.
Храните только оправданные данные
Миграция одновременно является решением о сроках хранения. Копирование каждой старой записи переносит в новую систему устаревшие персональные данные и сломанные классификации. Руководство британского Управления уполномоченного по информации требует не хранить персональные данные дольше необходимого и уметь обосновать срок.
Решите, что должно остаться в работе, что попадет в ограниченный архив, а что будет удалено по действующей политике. Сохраните обязательства по удалению и юридические запреты на уничтожение. Новая система не должна становиться вечной копией старых ошибок.
Сделайте новую запись рабочей
Польза общего входящего ящика в том, что история, контекст, назначение, заметки и состояние остаются рядом с одной клиентской задачей. Польза связанной карточки клиента в том, что поля, теги, группы, история согласия и владелец продолжают работать, а не превращаются в неподвижный архив.
Если вы оцениваете DripTell или другую платформу, принесите на обсуждение свой набор доказательств. Попросите показать импортированные записи и выполнить на них следующее действие. Убедительная демонстрация миграции выглядит не как полоса прогресса, а как продолжение настоящего диалога без просьбы к клиенту заново рассказывать прошлое.
Часто задаваемые вопросы
Какие данные клиентских диалогов нужно переносить
Переносите содержание и связи, необходимые для продолжения обслуживания, соблюдения сроков хранения, объяснения прошлых решений и точной отчетности. Остальное архивируйте или удаляйте по документированной политике.
Как поступать с открытыми диалогами
Оставьте у новой активности один источник истины. Держите открытые случаи в старой системе до закрытия, переносите их по контролируемой процедуре или переключайте доставку в заданный момент со сверкой пересечения.
Как проверить что контекст не потерян
Сравните на сложном наборе идентичность, хронологию, авторство, вложения, состояние, владельца, связи, сроки и следующий шаг. После этого выполните реальную операцию в новой платформе.
Нужно ли копировать старые теги без изменений
Нет. Сохраняйте тег только после того, как определили его смысл, правила применения и действие, которое новая система должна воспроизвести.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники