Переход с Treatwell: как мы перенесли семилетнюю историю салона в SalonRadar

Спросите владельца салона, что он потеряет при смене системы бронирования, и он редко упомянет функции. Он скажет о людях. О клиенте, который реагирует на конкретный продукт. О том, кто в этом году отменил бронирование четыре раза. О постоянных посетителях, по последнему визиту которых можно точно определить, когда ожидать следующего. Эти знания хранятся в многолетних записях о бронированиях и заметках, и именно в этом заключаются реальные издержки перехода.

Когда одна клиника эстетической медицины обратилась с просьбой перейти на SalonRadar, её владелец чётко обозначил условие: история должна перейти вместе с ней. Не просто таблица с именами. А полная история работы.

Что было перенесено	Примерно
Записи о клиентах	15 000
Записей на приём	37 000
История бронирований	7 лет
Сотрудники, бывшие и нынешние	60+

Основные правила

Эти данные принадлежат салону. По указанию владельца и с его разрешения мы экспортировали их из личного аккаунта салона в Treatwell. Прежде чем эти данные попали в SalonRadar, мы согласовали четыре правила:

• Смотрите, но не трогайте. Экспорт работал только в режиме чтения. Салон на протяжении всего процесса продолжал работать в своей существующей системе, и в ней ничего не изменилось.
• Никаких сюрпризов для клиентов. Процесс импорта ни в коем случае не должен отправлять электронные письма, SMS или напоминания. Никто не должен узнать о смене программного обеспечения салоном из-за сообщения, присланного системой в полночь.
• Сначала проведите репетицию. Каждый импорт можно запустить в режиме «сухой репетиции», при котором выполняются все действия, как при реальном импорте, а затем отменяются, чтобы владелец мог увидеть точный результат перед окончательным запуском.
• Возможность вернуться назад. Если после этого что-то покажется не так, одна команда должна удалить всё обратно.

В чём на самом деле заключалась сложность

Копирование строк из одной базы данных в другую — это легкие пять процентов. Остальное заключается в том, что две системы никогда не описывают мир одинаково.

Один визит — это не одна запись

Клиент, пришедший на чистку лица и окрашивание бровей, совершил одно посещение. В исходных данных это были два отдельных сеанса, прошедших один за другим. При импорте данных в исходном виде история каждого клиента выглядела бы более насыщенной, чем на самом деле, а количество посещений было бы завышенным. Мы объединяем сеансы, которые однозначно относятся к одному визиту (один и тот же клиент, один и тот же мастер, один сеанс следует сразу за другим), в одну запись с несколькими услугами, а все остальное оставляем без изменений.

Люди, которые больше не работают в салоне

За семь лет десятки специалистов приходили и уходили, и более половины всех записей на приём принадлежали тем, кто к тому моменту уже уволился. Отказ от этих записей стёр бы большую часть истории; присвоение их владельцу салона привело бы к её фальсификации. Создание учётных записей для бывших сотрудников не входило в наши планы. Поэтому каждому бывшему специалисту присваивается архивная запись: имя в прошлых записях на приём, без логина, без адреса электронной почты, без места в календаре или в публичном профиле. Нынешние сотрудники привязаны к своим реальным учётным записям.

Отмены бронирований тоже остались в прошлом

Во время тестирования мы заметили, что несколько отмененных бронирований незаметно исчезали. Причина заключалась в логике, казавшейся вполне обоснованной: если время уже занято, отклоняй поступающее бронирование как дубликат. Но и отмена, и визит, который позже заполнил то же время, являются реальными событиями, и именно отмена дает представление о надежности клиента. Мы исправили это правило и добавили проверку, чтобы оно оставалось исправленным.

Где искусственный интеллект помог, а где мы его не использовали

Самой неожиданной проблемой оказались названия. Система бронирования запоминает, как называлась услуга в день бронирования, а салон постоянно обновляет своё меню. Спустя семь лет треть всех забронированных услуг не соответствовала ни одной позиции в сегодняшнем меню. Одна из самых популярных в прошлом услуг салона просто больше не существовала под этим названием; она стала более длинной и конкретной.

Ни одно правило сопоставления текста не может этого обеспечить. Это вопрос интерпретации значения, поэтому мы поручили эту задачу модели искусственного интеллекта, созданной именно для принятия таких решений (Jev от TypeSafe): для каждого старого названия услуги выбирать соответствующую услугу из текущего меню или указывать, что ничего не совпадает. Что особенно важно, модель также сообщает, насколько она уверена в своём решении.

• Уверенные ответы принимались автоматически. Одно только это позволило повысить долю старых записей, связанных с текущей услугой, с 67% до 90%.
• Всё, что находилось ниже порога уверенности, попадало в короткий список для проверки владельцем: сначала шли наиболее часто используемые услуги, а рядом — второе предположение модели. Некоторые из этих решений носят коммерческий, а не технический характер: если вы заменили одну процедуру другой, является ли это той же услугой или нет?
• В тех случаях, когда модель не была уверена, она, как правило, оказывалась права. Одна старая услуга представляла собой комбинацию двух текущих, и модель разделила свой ответ почти поровну между ними.

Границы имели такое же значение, как и возможности. В модель поступали названия услуг, их категории в меню, продолжительность и цена, но никаких данных о конкретных людях. Мы также использовали помощника по кодированию на базе ИИ для создания и тестирования конвейера миграции, при этом инженеры проверяли каждое изменение. ИИ не принимал никаких решений относительно записей о клиентах, и ничто не импортировалось без предварительной проверки человеком.

Страховочная сетка

Инпортер считывает экспортные данные в виде потока, а не загружает их целиком, сохраняет данные небольшими партиями, чтобы в случае прерывания процесс можно было просто возобновить, и распознает все, что уже было импортировано, поэтому при повторном запуске дубликатов не возникает. Импорт всей истории занимает около трёх минут.

Затем мы протестировали процесс переноса. На копии учетной записи салона мы импортировали все 15 000 клиентов в режиме реального времени, запустили откат и сравнили базу данных до и после: все данные совпали, вплоть до записей о персонале и назначений ролей. Это полномасштабное тестирование оправдало себя. Оно выявило недостаток, который не удалось обнаружить в ходе небольших тестов: импортер, объединявший дубликат карточки клиента через минуту после её создания, при откате выглядел так, будто кто-то редактировал данного клиента, из-за чего несколько записей были ошибочно защищены. Правило отката заложено намеренно. Оно удаляет то, что записал импортер, но никогда не удаляет то, что кто-то изменил после этого. Просто оно не должно путать свою собственную работу с действиями человека.

Техническая архитектура намеренно проста: небольшой экспортер на Node.js, импортер, встроенный в наше приложение на Laravel с базой данных PostgreSQL, и десятки новых автоматизированных тестов, обеспечивающих соблюдение всех описанных здесь правил, чтобы миграция следующего салона началась с учетом всего опыта, полученного в ходе этого проекта.

Конфиденциальность была ограничением при разработке, а не просто формулировкой в условиях использования

• Согласие на маркетинговые сообщения не переносится. Разрешение, которое клиент когда-то дал на связь через другую платформу, не означает разрешения на связь через нашу. Оно не было перенесено. Клиентам будет задан этот вопрос заново.
• Никому ничего не отправлялось. Ни электронных писем, ни SMS, ни уведомлений — и ничто из этого не загромождало ленту активности салона.
• Салон принимает решение; мы занимаемся обработкой. Владелец выбрал, какие данные перенести и когда. Мы обрабатывали данные от имени салона исключительно для целей миграции и ни для чего другого.

Что это значит, если вы задумываетесь о переходе

Ваша история бронирований — это хроника вашего бизнеса, и она должна перемещаться вместе с вами. В первый же рабочий день салон открыл SalonRadar, имея в своём распоряжении уже семилетнюю историю клиентов, и продолжил работу как ни в чём не бывало.

Если вы используете Treatwell или другую систему, и вас сдерживает то, что придется оставить позади, обратитесь к нам. Мы расскажем, какие данные можно перенести, продемонстрируем пробную перенос ваших собственных данных, прежде чем приступить к окончательной миграции, и сможем отменить перенос, если вы передумаете.

Вопросы, которые задают владельцы салонов

Будут ли мои клиенты уведомлены об импорте их данных?

Нет. При импорте ничего не отправляется (ни электронных писем, ни SMS, ни push-уведомлений), а напоминания о предстоящих записях остаются отключенными, пока вы их не включите.

Перенесётся ли вся моя история целиком?

Клиенты, заметки и записи на приём, включая отмены и неявки, с указанием специалиста и стоимости каждого визита. Небольшое количество записей перенести не удалось: клиентские карточки без имени, телефона или электронной почты не к кому привязать.

А как быть с ушедшими сотрудниками?

Их прошлые бронирования сохраняют своё название. У них нет учётной записи, нет логина и нет места в вашем календаре или в вашем публичном профиле.

Могу ли я продолжать пользоваться своей текущей системой, пока это происходит?

Да. Сначала переносится история, а вы продолжаете работать в обычном режиме. В день перехода за один короткий цикл переносятся все новые данные, включая предстоящие записи на приём.

А что, если что-то пойдет не так?

Вы видите полную репетицию перед тем, как что-либо будет окончательно сохранено, а после этого импорт можно отменить, не затронув ничего из того, что вы добавили или отредактировали за это время.

---

Treatwell является товарным знаком соответствующего владельца. SalonRadar не является аффилированным лицом Treatwell, не поддерживается им и не является его партнёром. Данный перенос был осуществлён по указанию владельца салона с его собственной учётной записи. Цифры округлены.