Ольга Тимошенко: Сегодня в рубрике «Рассказ от первого лица» наш интегратор Максим Бабаев расскажет об экономии кнопок. Вернее, о том, как одной кнопкой заменить сразу несколько. Передаю слово Максиму.

Максим Бабаев: Добрый день! Меня зовут Максим Бабаев, и сегодня я хочу поговорить с вами об одном интересном инструменте, а именно — единой кнопке для движения процесса между 5 статусами, вместо 5 разных кнопок.

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

Сегодня, на примере нашей конфигурации «Отдел холодных/активных продаж» я покажу вам, как обойти это ограничение.

Для начала, немного о логике конфигурации, чтобы вы понимали, о чём речь.

Логика конфигурации

В ней у нас участвует 3 звена:

• Аналитик базы данных, который импортирует контакты (у которого заранее задан плановый показатель по базе);
• Сотрудник Call Center, который прозванивает базу с целью выяснить ЛПР (лицо, принимающее решение);
• Менеджер по активным продажам, который выявляет потенциальный интерес и превращает заинтересованный контакт в заключённый договор.

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

А вот так выглядят его статусы и логика переходов:

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

Техническая подоплёка и логика

Теперь давайте пройдёмся по техническим деталям. Итак, чтобы реализовать алгоритм, нам понадобятся:

• Специальное техническое поле «Номер статуса»;
• По автоматическому сценарию на каждый статус;
• Настройки кнопки по специальной логике.

В основе экономии кнопок лежит достаточно простая логика:

1. Каждому статусу вы присваиваете определённый номер, зависящий от его очерёдности в процессе;
2. Создаёте специальное техническое поле «Номер статуса»;
3. На каждый статус вы делаете автоматический сценарий, который переводит сделку в него, если номер статуса равен нужному значению;
4. Делаете кнопку «Дальше», которая возникает при соблюдении определённых условий, и которая вычисляет значение «Номер статуса +1»

Давайте разберём каждый пункт подробнее.

Нумерация статусов и техническое поле

В нашем случае, работа менеджера по продажам начинается со статуса «Выявление потребностей». Поэтому его статус = 1.

Аналогично, стадии «КП и согласование условий» мы ставим статус = 2, «Заключению договора» = 3, а «Ожиданию оплаты» = 4.

Как мы видим, при переходе сделки на статус «Выявление потребностей» (в нашем случае, это происходит, когда сотрудник Call Center нажал на кнопку «Передать менеджеру») номер статуса меняется на «1»:

Теперь мы можем готовить сценарии, которые через управление этим статусом, будут изменять статусы, не используя много кнопок 😉

Автоматические сценарии

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

Логика работы предельно простая: если задача создана по нужному шаблону и номер статуса равен «…», то установить статус, соответствующий номеру.

Делаем соответствующие наборы сценариев на каждый статус:

Всё, подготовительная работа проведена. Давайте же приступим к самому интересному: настройкам кнопки «Дальше» 😉

Волшебная кнопка «Дальше»

Для начала, давайте подумаем: какие условия должны быть соблюдены, чтобы вы разрешили перевести сделку на следующий статус?

В нашем случае, мы составляем набор следующих требований:

• Чтобы перейти на стадию «Составление и презентация КП», нам нужно, чтобы менеджер зафиксировал потребности;
• Чтобы перейти на стадию «Заключения договора», мы хотим, чтобы менеджер зафиксировал как минимум одну встречу или звонок с клиентом, а также чтобы мы увидели файл Коммерческого Предложения (КП) в сделке;
• Чтобы перейти на стадию ожидания оплаты, мы хотим, чтобы был виден подписанный договор в сделке;
• Чтобы посчитать сделку завершённой, мы хотим или видеть, что предоплата нам не нужна, или что предоплата поступила в полной мере.

Исходя из них, мы программируем кнопку следующим образом:

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

И да, помните, что есть ещё и ограничение по условиям 😉 Мы долго оптимизировали, пока не уложились всего в 13 строчек.

Теперь — вторая часть кнопки. Тут всё проще:

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

Теперь давайте посмотрим, как это работает.

Демонстрация

Мы помним, что условием появления кнопки является заполнение поля «Потребности»:

Как только мы заполняем это поле, возникает кнопка:

При нажатии на неё, мы получаем следующую картину:

• Номер статуса сменился;
• Статус сменился на следующий;
• У нас появились кнопки, которые имеют место быть только с этого статуса.

На следующих статусах всё аналогично.

Минусы

Несмотря на экономию кнопок, у этого варианта есть ряд минусов:

• Подходит только для линейных процессов

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

В подобном случае, не забудьте добавить в условия перехода на статус обнуление полей, от которых возникает кнопка назад (с дублированием в комментарии или специальное поле). Иначе вся логика потеряется!

• Достаточно долгая настройка и тестирование

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

• Требовательность к бизнес-процессам и требованиям к этапа

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

Слева — столбец «Система», справа — «Менеджер по продажам».

Без подобных диаграмм в принципе сложно выстраивать работу сотрудников, ведь они содержат в себе технологию работы — основу для масштабирования и автоматизации бизнеса. Но о ней мы поговорим с вами в другой раз 😉

Надеемся, это было полезно!

С уважением, Максим Бабаев и команда разработчиков-интеграторов Новой Бизнес Среды: Мария Филлипова и Михаил Панеев.

P.S.: Если возникнут вопросы о настройке подобного кейса, или же о том, как систематизировать и автоматизировать работу организации целиком, звоните или пишите мне напрямую: +7 919-726-21-74, meb@new-ben.ru. С удовольствием проконсультируем и поможем!

---

Ольга Тимошенко: Спасибо, Максим, Мария и Михаил. Мне осталось добавить, в наших социальных сетях — Facebook, ВКонтакте, Telegram, Twitter и YouTube-канале регулярно появляются новости о доработках и новинках. Подпишитесь, чтобы ничего не пропустить.