CRM для тендеров в Битрикс24: как построить воронку от заявки до контракта

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

Тендерный процесс выглядит простым, пока его не начинают описывать подробно:
Найти тендер -> Подать заявку -> Узнать результат -> Подписать контракт

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

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

Какие состояния тендера руководителю действительно важно видеть и контролировать?

Стадии фиксируют эти состояния. Задачи, сроки и автоматизация работают между ними.

Коротко

Базовый маршрут может выглядеть так:

Новый тендер
     |
     v
Принят в работу
     |
     v
Решение об участии
     |
     v
Заявка подготовлена
     |
     v
Заявка подана
     |
     v
Результат получен

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

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

Получить тендер в CRM и вести тендер в CRM - разные задачи

Новый тендер может появляться вручную или приходить из внешней системы. В экосистеме Битрикс24 есть приложения для СБИС, Seldon, Контур.Закупки и других тендерных сервисов. В зависимости от решения закупка может создавать лид или сделку и передавать в CRM данные тендера. Подробнее варианты интеграций перечислены в официальной справке Битрикс24.

Но загрузка тендера решает только первую часть задачи. После появления карточки всё равно нужно определить:

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

Поэтому интеграция с источником тендеров и автоматизация тендерного отдела - это два разных контура.

Стадия должна показывать результат, а не действие

Вместо стадии: Посмотреть тендер
лучше состояние: Принят в работу

Вместо: Подать заявку
лучше: Заявка подана

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

Какие данные нужны в карточке тендера

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

• сотруднику нужно принять решение;
• автоматизация использует это значение;
• руководитель анализирует показатель позже.

В карточке могут понадобиться:

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

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

До подготовки заявки нужно принять решение об участии

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

До неё можно проверить:

• соответствие требованиям;
• экономику;
• доступные ресурсы;
• сроки;
• стоимость участия;
• возможность выполнить обязательства.

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

Самая полезная автоматизация часто связана со сроками

У тендера есть бизнес-даты. Например: Дата окончания подачи заявок. От неё можно строить контрольные действия:

• проверить комплект документов;
• закончить расчёт;
• получить внутреннее согласование;
• подтвердить участие;
• подать заявку.

Роботы Битрикс24 позволяют автоматически ставить задачи сотрудникам при работе с CRM и задавать им крайний срок. Возможности роботов для задач описаны в официальной справке Битрикс24.

Конкретное правило зависит от компании.
Одной нужно завершить расчёт за несколько дней до подачи.
Другой требуется отдельная юридическая проверка.
Третьей нужно заранее подтвердить обеспечение.

Поэтому важен не конкретный срок, а модель:

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

После подачи заявки начинается ожидание результата

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

• контроля даты подведения итогов;
• постановки задачи проверить результат;
• фиксации новых дат;
• запуска следующего сценария.

И здесь появляется важная условная ветка.

Переторжка - не обязательная стадия

Если добавить Переторжку в линейную воронку, получится, что через неё должна пройти каждая заявка. В реальности это не так. Логика ближе к такой:

Заявка подана
     |
     v
Назначена переторжка?
   /           \
 нет            да
  |              |
  |              v
  |       Задача на нужную дату
  |              |
  +--------------+
         |
         v
Ожидание результата

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

Если событие происходит не всегда, оно не обязано становиться обязательной стадией воронки.

Проигрыш и победа запускают разные сценарии

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

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

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

При победе ситуация сложнее. Тендер выигран ещё не обязательно означает, что работа тендерного отдела завершена.

После победы начинается работа с контрактом

После победы могут оставаться:

• получение проекта контракта;
• проверка условий;
• обеспечение исполнения;
• проверка разногласий;
• подготовка протокола;
• получение новой редакции;
• подписание;
• контроль подписи заказчика.

Поэтому воронка: Заявка подана -> Выиграли -> Успех для некоторых компаний окажется слишком короткой. Конечный результат лучше определять из реальной ответственности тендерного отдела. Например: Контракт подписан обеими сторонами и готов к передаче в исполнение. Это гораздо точнее технической стадии Успешная сделка.

Разногласия лучше проектировать как цикл

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

Проект контракта
       |
       v
Есть разногласия?
   /           \
 нет            да
  |              |
  v              v
Подписание    Протокол
                 |
                 v
           Новая редакция
                 |
                 v
          Проверка снова

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

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

После подписания контракта возникает следующий вопрос: кто отвечает за фактическое исполнение? Если дальше появляются:

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

Мы подробно разбирали этот принцип в статье про несколько воронок и связанные процессы в Битрикс24. Сам Битрикс24 в описании одного из готовых отраслевых решений по тендерам также показывает отдельные процессы Тендер и Исполнение контракта. Это не универсальное правило для каждой компании, но такой вариант архитектуры технически возможен. Подробнее - в официальном описании решения.

Сделка или смарт-процесс

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

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

Смарт-процессы Битрикс24 позволяют создавать собственные поля и стадии, настраивать права и связывать элементы с другими объектами CRM. Подробнее - в официальной справке по смарт-процессам.

Выбирать сущность лучше после описания процесса, а не наоборот.

Что автоматизировать в первую очередь

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

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

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

Восемь вопросов перед настройкой

Перед настройкой CRM для тендерного отдела стоит ответить хотя бы на восемь вопросов:

1. Откуда появляется новый тендер?
2. Кто принимает решение об участии?
3. Что обязательно нужно заполнить до подачи заявки?
4. Какие даты нельзя пропустить?
5. Какие события возникают только при определённых условиях?
6. Какие причины отказа или проигрыша нужно анализировать?
7. Что должен сделать тендерный отдел после победы?
8. В какой точке ответственность тендерного отдела заканчивается и начинается исполнение?

Ответы на эти вопросы обычно важнее первоначального списка роботов.

Главное

Хорошая CRM для тендеров - это не просто карточки закупок в одной воронке.
Она должна отвечать на три вопроса:

Что уже произошло с тендером?

Что сотрудник должен сделать дальше?

К какому сроку?

Если процесс ветвится, CRM должна отражать эти ветки.

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

Если после подписания начинается самостоятельное исполнение, нужно отдельно определить границу между двумя процессами.

Тогда Битрикс24 становится не ещё одним местом, куда сотрудник вручную переносит информацию, а рабочим контуром тендерного отдела.