amoCRM для лазерной студии: что настроить до виджета записи

Виджет записи опирается на структуру портала: на воронки, справочники и поля. Если их нет или они заведены произвольно, установка виджета не улучшит ситуацию, а сделает беспорядок видимым. Разберём минимальный состав настройки amoCRM для лазерной студии, который стоит собрать заранее.

Почему одной воронки недостаточно

Типичная первая настройка выглядит так: одна воронка «Продажи», в неё падают все обращения, там же ведутся визиты. Через два месяца в ней двести сделок в разных состояниях, и понять по ней ничего нельзя.

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

Смешивая их, вы получаете воронку, в которой средний срок сделки не значит ничего, а конверсия считается между несопоставимыми состояниями. Разделение решает это без дополнительных инструментов: одна воронка отвечает на вопрос «как продаём», вторая — «как работаем».

Какие справочники завести до расписания

Расписание бронирует ресурсы, поэтому ресурсы должны существовать как записи, а не как слова в комментарии.

• Кабинеты — с указанием филиала.
• Мастера — с привязкой к филиалам, в которых работают.
• Аппараты — с типом, потому что от него зависит применимость к фототипу.
• Зоны обработки — единым перечнем, а не свободным текстом.
• Филиалы — даже если он пока один: добавить второй позже дешевле, чем переразметить всё.

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

Какие поля нужны в карточке визита

Набор короткий и определяется тем, что от него зависит.

Зона и номер сеанса — по ним считается дата следующего визита. Дата и время — то, что видит расписание. Кабинет, мастер и аппарат — три ресурса, которые проверяются на конфликт одновременно.

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

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

Почему правило завершения визита важнее остальных

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

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

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

В каком порядке всё это внедрять

Порядок имеет значение, потому что каждый следующий шаг опирается на предыдущий.

1. Развести две воронки и договориться об этапах словами, а не в интерфейсе.
2. Завести справочники: филиалы, кабинеты, мастера, аппараты, зоны.
3. Добавить поля визита и поля клиента, обязательными — минимум.
4. Зафиксировать правило завершения визита и правило неявки.
5. Прожить неделю в этой структуре без надстройки и посмотреть, что администраторы заполняют, а что обходят.
6. Только после этого ставить расписание.

Пятый шаг чаще всего пропускают, а он самый информативный: поля, которые обходят, либо не нужны, либо сформулированы непонятно. Как этот порядок ложится в наши этапы внедрения и что делает надстройка после него — на странице eVaLaze.