CRM в стиле Agile: как быстро конструировать необходимую отчетность в продажах

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

Наглядность отчетности очень сильно зависит от Ваших бизнес-процессов. Например, если Вы продаете канцелярские товары, то все будет зависит от интенсивности обзвона и массовости обхвата. Если Вы имеете длительный цикл продажи и продаете, скажем, турбины для электростанций, то количество в качество простой конверсией не преобразуешь. Недостаточно периодически позванивать и спрашивать как дела. Нужно четко отслеживать стадию подготовки к сделке у Заказчика. Маршрут прохождения решения также будет зависеть от сферы бизнеса. Например, в строительстве он не такой как в энергетике. Распространенной является бизнес-модель, в которой основная битва за клиента (конверсия) разворачивается при продаже оборудования, которое отдается “в ноль”, а деньги зарабатываются на расходниках. Встречаются и иные вариации бизнес-процесса продаж. Последнее время стала популярной схема привлечения клиентов с помощью контента в сети — эффективность таких каналов тоже надо контролировать. Поэтому надеяться на какие-то типовые отчеты коробочной CRM наивно, Вы серьезно потеряете в конкурентноспособности на рынке. Продажи — креативный бизнес-процесс, все время требующий новых решений. А значит предъявляющий повышенные требования к аналитике.

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

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

Электронные таблицы не только инструмент представления, но еще имеет мощный инструментарий по преобразованию данных. Надо загружать в них не выборки, а весь исходный объем данных. Это можно сделать обычным копированием (CtrlC+CtrlV). Этот вариант быстрый и не позволяет “забыть” или “ошибиться” в каких-либо данных. А на отдельном листе делать сводную таблицу. Что ГуглТаблицы, что Эксель предоставляют для этого широкий набор формул. В частности, в ГуглТаблицах есть функции многофакторного суммирования SUMIFS(), функции фильтрования данных FILTER(), импорта из других таблиц IMPORTRANGE() и даже функция для формирования SQL-запросов QUERY().

Связка БД+ЭТ (Firebase+Google Таблицы) позволила нам внедрять CRM в режиме Agile. Мы сразу не парились отчетностью, а просто наладили регулярную выгрузку реестра активностей в Google Таблицу. И там уже на разных листах экспериментировали с отчетностью. Как только мы понимали, что какой-либо отчет очень удобен в повседневном применении и мы достаточно отшлифовали его бизнес-логику — мы делали под него отдельный веб-интерфейс (чтобы можно было открывать даже со смартфона) и он становился частью CRM. Сэкономили на этом кучу денег на разработке.

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

Эта функция имеет один минус. Если у нас добавится новый менеджер нам надо будет руками добавить его на лист “Воронка” и протянуть на него все формулы. На листе “Сводка” показан пример работы функции QUERY — полноценного SQL-запроса. Эта функция таких минусов не имеет. С ее помощью мы можем работать с диапазоном как с обычной базой данных. На листе “Сводка” можно увидеть как автоматически получать сводку по выставляемым счетам и среднему чеку. В пакете Microsoft Excel такой функцией еще не обзавелись.

Также, по сравнению с Экселем в ГуглТаблицах есть функция ARRAYFORMULA — это очень удобный инструмент, позволяющий не протягивать формулы на весь диапазон. Например, если мы хотим посмотреть сколько счетов выставляют менеджеры по дням, то нам сначала надо выделить в списке счетов из даты день. Это делается на листе “Реестр счетов из 1С” в ячейке H1 формулой

=ARRAYFORMULA(DAY(A:A)).

Как Вы можете убедится, в остальных ячейках столбца формул нет, а нужные нам значения есть. И нам не надо заботиться о том, протянули ли мы формулы на все строки диапазона. Далее мы опять применяем функцию QUERY. На листе "Дневные" можно посмотреть как работает этот пример.