Ко мне обратился клиент с запросом что ему нужна база знаний и оргструктура компании. Ранее он нашел в интернете профильный кейс и в целом начальный запрос выглядел «хотим как в кейсе».

По текущей ситуации (на момент написания статьи) в компании было около 10 человек и планировался в ближайшем будущем поиск сотрудника в отдел продаж и двоих сотрудников в отдел исполнения. И хотелось создать структурированную базу знаний, на базе которой проводилось бы обучение.

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

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

Встал вопрос с чего начать работу. С оргструктуры или с разработки базы знаний. Что касается базы знаний там нужно в первую очередь разработать материалы для отдела продаж и отдела исполнения (так как в оба отдела планировалось скоро найти новых сотрудников).

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

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

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

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

Построение базы знаний того или иного отдела начинается всегда с разбора бизнес-процессов отдела. В отделе продаж бизнес-процессы — это наши воронки продаж. Соответственно вместе с владельцем и РОПом начали погружаться в логику воронок и начали с аудита воронок в CRM (клиент работает в Битрикс24).

При аудите воронок в CRM было обнаружено:

1. Наличие ненужных этапов на основных этапах воронки. Некоторые были недействующие, некоторые этапы отображали скорее статус клиента по причине отказа (например «недозвон свежие лиды», «недозвон старые лиды») при этом такие этапы были действующими этапами воронки. 
2. Огромное количество сделок на этапах. Это в основном касалось как раз тех сделок, которые были на ненужных этапах и по хорошему должны были бы быть заведены в отказ или в отдельную воронку по ним. На некоторых этапах находилось по несколько тысяч сделок, которые обрабатывались по остаточному принципу если у менеджеров оставалось время. Выстроить какую-либо аналитику из текущего состояния воронки также не представлялось возможным.
3. Отсутствие единогласности при переводе сделок на следующий этап. В воронках некоторые этапы имели неочевидное название. Из-за разного трактования порой возникала путаница, когда нужно или не нужно переводить сделку на следующий этап воронки. В частности основная воронка была поделена на две — лиды и сделки. И не всегда сделки переводились в другую воронку когда нужно было их перевести и наоборот. 
4. Отсутствие сегментации. Так как в воронке на некоторых этапах были залежи сделок, которые нужно было бы отправить в отказ, а сам отказ при этом не был указан трудно было разобрать с какой сделкой больше шансов на реанимацию лида, а с кем их уже и вовсе нет и не нужно на такую сделку тратить время менеджера. Были и неуспешные этапы с каким-то количеством сделок, но по названию этапа (например «Отказ после консультации») невозможно было понять, а в чем именно причина отказа и как дальше с такой сделкой работать.  Ведь может быть несколько причин почему клиент ушел в отказ и в зависимости от причины работа с каждым из таких сегментов ведется по разному. При текущем состоянии работа на таких этапах будет занимать кратно больше времени, так как будет требовать более длительного погружения менеджера в историю каждой сделки. Либо же эта работа вообще не будет производится из-за бесконечного количества сделок на этапе и потенциальные клиенты, которых можно было бы еще вернуть по итогу таковыми и останутся. 

То есть даже при первом взгляде на состояние дел в CRM стало понятно, что сначала нужно привести здесь все в порядок, и только потом уже создавать базу знаний.

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

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

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

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

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

Схематично логика работы выглядит как показано на картинке выше. В более крупных компаниях с большим количеством менеджеров в отделе продаж такая схема скорее всего не подойдет и нужна будет более сложная версия с бОльшим количеством воронок.

Но в данный момент времени усложненная логика скорее будет мешать эффективной работе менеджеров отдела продаж. Соответственно показал варианты как можно «усложнить» логику для наиболее эффективной работы отдела продаж в будущем при росте компании.

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

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

Это удобно в том плане что делится весь текущий функционал менеджера отдела продаж и получается что «продажники продают», а "квалификаторы квалифицируют" и проще найти сотрудников на тот или иной конкретный функционал. Тоже самое можно заложить и для менеджеров реанимации базы и т. д.

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

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

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

Итого по структуре отдела продаж мы утвердили, что в данный момент кроме РОПа будет только менеджер отдела продаж, который пока что будет работать со всей базой (в дальнейшем мы пропишем порядок приоритетности работы менеджера отдела продаж с какими клиентами он работает в первую очередь, с какими во вторую и так далее). Но при этом рассмотрели варианты как можно будет в будущем пересмотреть структуру отдела продаж при росте компании.

Во всех воронках в ТЗ прописали какие есть этапы.

Сделали:

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

Соответственно никаких лишних этапов, только необходимые для продвижения по воронке. В частности в воронке новых продаж (ВНП) осталось лишь 6 этапов (не считая системные этапы успешной или неуспешной сделки). Ранее их было 8 суммарно на 2 воронки. Убрали 3 лишних, добавили 1 недостающий. 

Сами этапы также переименовали чтобы не возникало разночтений при работе менеджера. 
Описанные в ТЗ «стадии продаж» и «алгоритм обработки лидов» можно также скопировать и вставить в поля с подсказками в самом CRM.

Далее разобрали какие могут быть причины отказа почему сделка завершилась неудачей.

Выявили 16 причин по которым менеджер может отправить сделку в отказ. При этом структурировали их по группам:

• отказы до коммуникации
• отказы после начала коммуникации
• отказы по завершению первичной консультации
• отказы на этапах заинтересованности в услуге

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

После проработки всех причин отказа по которым сделка может быть закрыта далее проработали сегменты клиентской базы.

Если логически обобщить их, у нас получились следующие группы сегментов:

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

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

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

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

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

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

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

Приведу пару примеров необходимости такой автоматизации.

/ пример 1

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

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

На этот случай заложено несколько автоматических задач на этапе. То есть если сделка находится на этапе сутки - поставить автоматическую задачу менеджеру с пометкой «Проверь поступление документов от клиента!". И так можно сделать еще несколько раз, например через двое суток, через трое и так далее.

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

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

/ пример 2

Воронка “Хранилище”. Этап/сегмент “Передумали оформлять банкротство”. Из названия понятно, что данный сегмент отказавшихся рассматривал услугу БФЛ как вариант решения своей проблемы, но в итоге оказался. После заведения в отказ с указанием соответствующей причины отказа сделка попадет на этот этап.

Далее через определенное время (например 2 месяца) менеджеру поставится задача "Свяжись спустя 2 месяца с передумавшим делать банкротство". Менеджер попытается связаться с клиентом и узнать о ситуации отказавшегося спустя указанные 2 месяца.

При этом при заведении в отказ ему не нужно ставить такую задачу, система поставит ее сама (для каждого сегмента через определенное время).

По регламенту менеджер ограничивается такой попыткой связаться 1 раз. То есть не нужно потом пытаться это делать в течение еще полугода, например. А через некоторое время (спустя 2 недели после постановки такой задачи менеджеру) сделка переместится на этап “Холодная база”, где никакие автоматические задачи ставиться уже не будут.

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

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

Помимо поля с причиной отказа, мы проработали и все другие необходимые поля для заполнения менеджером. Сделали минимальные изменения к текущим, прописав в ТЗ что необходимо добавить еще 1-2 поля.

Также проработали обязательность заполнения полей на каждом этапе воронок. Как и в случае с задачами, это инструмент подстраховки при работе менеджера в CRM.

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

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

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

Также очень важный момент в работе менеджера по продажам - понимать из списка предстоящих задач, какие из них наиболее важные, и что нужно обрабатывать в первую очередь.

Забегая вперед добавлю, что при работе над документацией был разработан регламент приоритетности взятия задач для менеджера по продажам.

У нас получился список из 11 пунктов с точки зрения последовательности взятия тех или иных задач в работу в CRM. При этом мы выделили, что некоторые из пунктов при постановке задачи должны содержать в обязательном порядке определенные эмодзи (в нашем случае мы выбрали ⚡️и 🔥).

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

Компания уже работала со своим специалистом по Битрикс24, соответственно техническая настройка производилась его силами. В процессе работы с ним было проведено 2 встречи.

На момент написания статьи, мой практический опыт работы сводился к внедрению CRM на базе amoCRM. Я собственноручно настраивал его и сам себе для ведения собственной клиентской базы, разрабатывал ранее ТЗ для клиентских проектов (настройка потом производилась уже силами технических специалистов) на базе amoCRM.

То есть насмотренность возможностей работы в amoCRM уже достаточно большая. С Битрикс24 с точки зрения технической настройки я работал уже очень давно (хотя в ближайших планах есть необходимость погрузиться в него чуть глубже в рамках другого проекта). Потому в процессе разработки ТЗ возникла необходимость уточнить некоторые технические моменты по возможностям Б24, чтобы убедиться что задуманная автоматизация, которую я знаю как реализовать в амо, также будет возможна и в Б24.

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

Итого на первой встрече со специалистом Б24 мы убедились что все задуманное мною можно реализовать и на базе битрикса, что еще раз подтвердило универсальность подхода при разработке технического задания для любой CRM-системы.

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

Соответственно специалист приступил к настройке CRM (сделать все по новому, не ломая старое, чтобы потом по отмашке отдела продаж уже перенести работу в новые воронки), а мы, наконец, приступили к разработке документации для базы знаний.

В результате разработки ТЗ для внедрения CRM:

• Утвердили логику отдела продаж с необходимым для работы количеством воронок
• Утвердили структуру текущего отдела продаж с пониманием, как его масштабировать в будущем
• Прописали все причины отказа которые у нас могут быть на всех этапах воронки, чтобы отделить тех, с кем мы хотим в будущем еще работать от тех, с кем не хотим
• Прописали все сегменты нашей клиентской базы, чтобы удобно работать только с теми с кем нужно, и задали алгоритм работы с каждым сегментом
• Разработали необходимые триггеры автоматизации CRM для облегчения работы менеджера, а также для подстраховки во избежание человеческого фактора (например, если забыл поставить задачу по следующему шагу по сделке)
• Прописали обязательные для заполнения поля сделки при смене этапов для подстраховки работы менеджера
• Заложили статусы задач для понимания приоритетности взятия задач менеджерами при работе с задачами, чтобы самые важные задачи были обработаны обязательно в назначенный срок
• Проработали права доступов для сотрудников отдела продаж и отдела исполнения, чтобы каждый видел только то, что должен видеть
• Передали готовое ТЗ специалисту компании по Битрикс24 без каких-либо дополнительных вопросов по разработанному документу

Процесс разработки ТЗ занял ровно 2 недели с интенсивностью 3−4 встречи в неделю с владельцем компании и руководителем отдела продаж и небольшими промежуточными работами по докрутке ТЗ между встречами.

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

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

Например, если мы ориентируемся на департаменты, то корневые разделы у нас будут логически содержать в названии: «построение», «коммерция», «финансы», «производство» и т. д. («коммерческий департамент», «направление коммерции», «отделение коммерции"и т.п., это уже как вам больше нравится/как у вас принято с точки зрения названия) если брать за основу построение оргсхемы из 7 департаментов.

Если же мы идем на подчинение ниже, как основу для разделов, то там будет суммарно около 21 раздела из логики что каждый департамент содержит у нас как минимум 3 отдела (естественно исходя из бизнес-процессов компании это может быть не так). И корневые разделы уже будут у нас называться «отдел маркетинга», «отдел продаж» и так далее.

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

Далее утвердили один из предложенных вариантов логики хранения документации уже внутри папки того или иного отдела и отдела продаж в частности. Утвердили что в корне папки отдела продаж у нас будут следующие вложенные папки: воронки продаж, регламенты, скрипты, шаблоны сообщений клиентам, шаблоны документов, сотрудники, обучающие материалы, целевая аудитория, цены/прайс-листы.

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

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

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

Сервис удобен тем, что если единожды выстроить всю логику в плане оргструктуры и должностей — можно управлять необходимыми доступами буквально в пару кликов. Например, поставил человека на должность на структуре — ему открылись все необходимые доступы для его работы (разделы в базе знаний, курсы для его должности, доски для совместной работы и т. д.). Убрал его со структуры — он сразу все доступы потерял.

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

Чтобы разработать базу знаний, необходимые регламенты и прочую документацию необходимо двигаться от общего бизнес-процесса, детализируя его в дальнейшем на шаги/подпроцессы и их шаги и т.д. То есть двигаться от бОльшего к меньшему, пока не детализируем выполнение того или иного шага до необходимых подробностей.

Бизнес-процессы в отделе продаж это как раз наша воронка продаж и для начала нам нужно сделать документ (один или несколько) с описанием этой самой воронки.

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

Соответственно первым делом мы разработали описание документа с логикой работы всех воронок в CRM, чтобы дать общее понимание, как все взаимосвязано между собой. Помимо текстового описания сделал наглядную блок-схему текущей логики работы отдела продаж (с учетом всех изменений, что мы разработали) и добавил картинку с ней в документ с описанием.

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

Очень помогало при создании документации описания бизнес-процессов/воронок (а также описаний этапов и некоторых регламентов в дальнейшем) ранее проделанная объемная работа над созданием ТЗ для CRM. Можно было брать информацию из него и адаптировать уже под разработку документа с описанием.

Если документы с описанием логики всех воронок (и каждой, в частности) давали общее представление о происходящем в отделе продаж, то описание работы каждого этапа уже погружало в конкретику. То есть в описании этапа мы прописали:

• результат всех действий на этапе
• последовательность шагов которые необходимо проделать для получения результата
• альтернативные варианты развития событий, при необходимости, которые могут произойти если ход событий пойдет не по идеальному сценарию (например, мы должны провести первичную консультацию, но помимо успешного сценария, у нас может быть еще 4 неуспешных)
• критерии перевода сделки менеджером на следующий этап
• должность, ответственную за актуальность документа

В описании документа этапа «Закрыто и нереализовано» сгруппировали все причины отказа. Добавили описание каждой причины отказа, чтобы у менеджера не было разночтений при выборе причины отказа.

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

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

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

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

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

Всего было разработано 14 регламентов, в которых были детально описаны:

• необходимые действия при квалификации лида
• порядок действий менеджера при проведении первичной консультации, а также порядок действий в случае неуспешных сценариев развития событий при проведении консультации
• порядок действий менеджера после проведения консультации менеджером при принятии решения клиентом (как положительном, так и отрицательном) о сотрудничестве
• правила проведения оффлайн-встречи
• особенности работы на стадиях заключения договора и оплаты
• особенности работы с клиентом, который ранее был отправлен в отказ, но решил самостоятельно вернуться к сотрудничеству
• правила работы с задачами в CRM с точки зрения приоритетности

и так далее.

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

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

• записать видеоскринкасты с комментариями — например если необходимо объяснить какие-то технические особенности работы в CRM
• добавить необходимые картинки для более легкой усвояемости материала — такие картинки, например, могут содержать в себе скриншоты с примером диалога с клиентом или скриншот из интерфейса какого-либо сервиса
• добавить верстку в текст — чтобы документ был разделен логически смысловыми разделами, сам текст внутри раздела документа был логично разбит на смысловые блоки, а не единой текстовой простыней. Выделить цветом какие-то важные тезисы из документа. Добавить содержание, чтобы легко было ориентироваться внутри документа
• добавить визуальные элементы — например картинки в тему в шапку текста или между смысловых разделов

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

Некоторые регламенты получались достаточно объемными по содержимому. Чтобы новому сотруднику было проще ориентироваться в том, что он изучает придерживались привычного правила «от бОльшего к меньшему» при создании материала. То есть прежде чем погружать в детализацию той или иной подзадачи внутри регламента в начале давалось общее представление по тому, что мы будем делать через описание или через нумерованный список — чтобы изучающий сразу увидел общую картину.

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

Еще одна важная деталь при разработке регламента — кто будет ответственен за актуальность документа.

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

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

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

Резюмируя, по разработке каждого регламента, что было сделано:

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

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

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

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

и другие.

Таким образом мы заложили суммарно более 30 ссылок в теле регламентов на тот или иной скрипт в зависимости от ситуации, который необходимо будет разработать в будущем. 

Те скрипты, которые уже имелись у клиента (проведение встречи, отработка некоторых возражений), добавили в необходимые сценарии.

Отдельной задачей было разложить большой по объему документ (10 страниц, горизонтальное размещение, 11 шрифт) со скриптом проведения консультации в удобный для навигации и обучения формат. 

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

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

Предложил клиенту два варианта решения задачи с точки зрения визуала (через таблицу и через выделение цветом). Утвердили второй вариант.

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

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

Получилось объемно, но клиенту понравилось :)

Также утвердили моменты, которые необходимо будет реализовать в данном блоке позднее на следующем этапе работ, такие как:

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

Шаблоны сообщений необходимы, чтобы оптимизировать работу менеджера по набору текста клиенту в той или иной ситуации. Их можно прописать в отдельном документе для быстрого копипаста. Также их можно потом заложить в CRM-систему в качестве преднабранного текста, вызываемого по команде. Но чтобы было что преднабирать или копипастить — нужно сначала разобраться, какие именно сообщения нам нужно сделать.

По аналогии со скриптами, по мере разработки регламентов, мы также закладывали и все сценарии, при которых может быть отправлено то или иное сообщение клиенту. Как правило, каждая попытка связаться с клиентом по определенному скрипту также предусматривает отправку сообщения в мессенджере.

В процессе разработки регламентов, заложили более 30 видов шаблонов сообщений, которые мы можем отправлять клиенту в той или иной ситуации. Сгруппировали их по 6 группам:

• Отправленная информация после консультации
• Сообщения догревы
• Сообщения по оформлению договора
• Сообщения отказникам в хранилище
• Сообщения бывшим клиентам
• Сообщения по партнерке

В процессе работы совместно с РОПом было разработано около половины шаблонов сообщений, которые мы разместили в соответствующих для этого местах в базе знаний.

Учитывая необходимость введения в должность нового сотрудника в отделе продаж, было решено как-то логически доделать необходимый минимум для обучения сотрудника, а все необходимые улучшения оставить уже на следующий этап работ. В том числе поэтому некоторые моменты по доделкам в регламентах (в меньшей степени) и скриптах/шаблонах (в большей степени) были оставлены на будущее.

Также оставили на следующий этап работ разработку материалов неразобранных папок в отделе продаж — сотрудники, обучающие материалы (продукту/продажам), целевая аудитория, цены. Дал рекомендации по каждой папке, что желательно включить в материалы.

Например, содержимое папки «сотрудники» наполнить материалами основных документов для должностей отдела продаж (сейчас РОП и менеджер ОП) — такими как ГФД (главный файл должности/должностная инструкция), план адаптации, нормы по конверсии, отчетность. А обучение по продукту обязательно сопроводить жизненными примерами, как понимать ту или иную услугу в противовес обучения через сложные нормативные нормы.

После утверждения логики содержимого всех папок отдела продаж, утвердили также примерную последовательность онбординга сотрудников.

Одна из задач, которую решает база знаний — существенное уменьшение времени опытных сотрудников/руководителей на персональное обучение нового сотрудника. Усиливает это решение в Platrum инструмент «Академия», который позволяет создавать автоматизированные курсы для сотрудников.

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

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

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

Разработка материалов общего курса это, как правило, задача владельца компании. Утвердили видение будущего раздела «для всех сотрудников» и далее владелец забрал чеклист себе в работу.

Также решили вынести в материалы общей папки обучение по работе в Битрикс24, хотя оно будет нужно и не всем сотрудникам, но большинству. Тем должностям, кому оно будет нужно в работе — мы позднее назначим отдельный курс в академии.

Итого логика обучения у нас будет состоять из двух частей:

1. Общий курс о компании (подходит для всех должностей)
2. Материалы профильной должности (уже для конкретной должности)

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

Если мы создаем отдельные курсы (например, отдельный курс знакомство с компанией, отдельный курс регламенты менеджера отдела продаж, отдельный курс по работе с Битрикс24 и т. д.), то когда сотрудника назначают на должность на структуре ему становятся доступны к прохождению одновременно все курсы, которые необходимы для его должности. Соответственно сотрудник, при желании, может начать проходить их в любом порядке.

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

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

Пока же сделали «обычное» обучение для менеджера отдела продаж с курсами, где большинство (или часть) материалов уже были разработаны — знакомство с компанией, воронки, регламенты, скрипты, шаблоны. При добавлении нового материала в тот или иной материал в базе знаний система подтянет его в обучение автоматически.

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

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

В результате работ по разработке основы базы знаний для отдела продаж мы:

• Утвердили логику разделов базы знаний компании и папок отдела (в частности отдела продаж) для быстрого ориентировании в материалах базы знаний
• Сделали описание логики работы всего отдела продаж, описание логики работы каждой воронки и каждого этапа по отдельности для понимания сотрудниками «что мы делаем»
• Разработали необходимое количество (в данный момент 14) регламентов, охватывающих все необходимые действия в текущих процессах отдела продаж для понимания сотрудниками «как мы это делаем». Сделали текстовое описание, подсветили моменты, где необходимо будет добавить графические материалы, как сверстать документ, где нужно добавить ссылки в нужных местах которые будут вести к другим документам (другим регламентам, описаниям процессов, скриптам, шаблонам сообщений и т. д.)
• Заложили логику для всех необходимых скриптов, которые нужно будет создать, которые будут учитывать все сценарии взаимодействия с клиентом
• Заложили логику для всех необходимых отправляемых сообщений клиентами, которые нужно будет создать, которые будут учитывать все сценарии взаимодействия с клиентом в мессенджерах
• Выбрали автоматизированную платформу для хранения материалов и обучения сотрудников
• Произвели перенос разработанных материалов в сервис автоматизации менеджмента Platrum, согласно разработанной логике
• Адаптировали и перенесли существующие материалы клиента в базу знаний, включая объемный основной скрипт проведения консультации с множеством вариаций развития диалога
• Добавили все необходимые перекрестные ссылки ведущие на другие документы или на конкретные разделы данных документов (например, из регламента на конкретные скрипты/шаблоны отправляемых сообщений или на другие регламенты)
• Произвели верстку перенесенных документов с формированием автоматического содержания для перемещения по документам
• Согласовали программу обучения с логикой последовательности выдачи материалов онбординга для любой должности и менеджера отдела продаж в частности
• Создали обучающие курсы и назначили их на менеджера отдела продаж
• Согласовали необходимые улучшения в базе знаний для будущих этапов работ

Процесс разработки основы базы знаний отдела продаж занял около 2 месяцев с интенсивностью 2−3 встречи в неделю с владельцем компании и руководителем отдела продаж и промежуточными работами по созданию и переносу документации между встречами.