Согласование 400+ счетов без потерь: единый бизнес-процесс оплаты для медицинского холдинга из 5 юрлиц
Краткая информация о клиенте:
Компания: ГК Приоритет
О компании: медицинский холдинг из Санкт-Петербурга, объединяющий сеть клиник и диагностических центров
Число сотрудников работающих в Битрикс24: 170
Город: Санкт-Петербург
Задачи клиента:
На одном портале сошлись три крупных направления, и в каждом накопился свой узел проблем.
Направление 1. Лидогенерация - поставочное подразделение теряло входящие обращения:
Решение задачи:
Работу разбили на контуры и под каждый собрали свои смарт-процессы Битрикс24 и логику автоматизации бизнес-процессов.
Первый контур - лидогенерация и интеграция сайта с Битрикс24:
Заменили нестабильное приложение на собственную интеграцию.
Отказались от приложения из Маркета и реализовали передачу заявок с сайта через вебхук: на стороне сайта разработчик клиента настроил отправку данных, на стороне Битрикс24 мы приняли их и разложили в смарт-процесс Лиды АМД.
Поток заявок больше не зависит от стороннего приложения.
Настроили маршрутизацию заявок с почты:
каждое письмо с почты заявок автоматически создаёт лид. Учли ограничение Битрикс24 - письма от сотрудников портала нельзя сохранять в CRM - и выстроили корректную схему получения заявок без потери данных.
Доработали смарт-процесс Лиды АМД:
настроили стадии воронки, включая провальные (вышедшая процедура, частное лицо и другие), добавили множественное добавление поставщиков, ссылку на диск, блок авторизации; на второй стадии настроили автоматическую задачу для менеджера.
Связали лид со сделкой без потери данных:
при конвертации наименование и поля переносятся автоматически, зашили маршрутизацию по типу закупки (прямая продажа уходит в воронку Отправлено КП, тендер - в Формирование ТЗ), настроили создание сделки в Прямых продажах и корневой папки клиента на диске с папками по проектам.
Так настроенные воронки продаж Битрикс24 ведут каждое обращение по своему сценарию без ручного разбора.
Привязали переписку к карточке, в том числе через приложение копирования таймлайна: ответные письма подвязываются к тому лиду, из которого отправлены, и история общения хранится в карточке.
Навели порядок в данных - очистили более 1100 устаревших лидов.
Второй контур - сквозной бизнес-процесс согласования заявок на закупку:
Построили смарт-процесс Заявка на закупку со стадиями от запуска заявки до оплаты:
согласование центром затрат, подбор силами снабжения, согласование коммерческого и финансового отделов, согласование гендиректора, создание счетов на согласование, ожидание оплаты, получение товара.
Запуск настроили так, чтобы система всегда фиксировала инициатора.
Добавили обоснование закупки для решения гендиректора:
перед ним встроили два этапа, где коммерческий и финансовый отделы последовательно заполняют файл-шаблон окупаемости и сравнения аналогов.
Шаблон автоматически прикрепляется в задание, поле под сравнительные таблицы сделали множественным, снабжение дополняет итоговый файл перед финальным согласованием. В результате гендиректор получает заявку с готовым обоснованием и комментариями всех участников.
Зашили условную логику маршрутизации:
согласование коммерческого и финансового отделов включается только для нужных типов закупки (оборудование, под пациента, стоматология-оборудование и подобные); для работ, услуг и аренды согласование идёт по структуре снизу вверх.
Если автор заявки сам является согласующим центром затрат, его шаг пропускается, чтобы человек не утверждал заявку сам себе.
Автоматизировали регулярные закупки:
шаблон-планировщик сам создаёт заявку на канцелярию в нужную дату каждого месяца, ставит срок и задачу заявителю заполнить шаблон по активной ссылке; если за срок заявку не отработали, она закрывается.
Связали заявку с реестром ЛУ и навели порядок в правах:
настроили создание записей реестра ЛУ из счетов по заявке, чат для обсуждения с наблюдателями, автоформирование понятного наименования (ID, организация, отделение или специализация, тип заявки, ФИО заявителя, наименование закупки).
Разграничили доступы: каждый видит свои заявки, руководители - все; быстрый доступ к процессу вынесли в левое меню.
Третий контур - сквозной бизнес-процесс Счёт на оплату 2025
который проводит счёт от загрузки до оплаты и сбора закрывающих документов. Главной задачей было настроить согласование счетов в Битрикс24 так, чтобы один процесс закрыл всю разнородную структуру холдинга:
Маршруты согласования по юрлицу и типу оплаты:
процесс сам определяет цепочку согласующих. Для юрлиц с медицинским директором счёт идёт по маршруту центр затрат - медицинский директор - гендиректор, для остальных организаций напрямую к гендиректору;
под каждый из более чем десятка типов оплаты зашиты свои согласующие, а список вынесен так, чтобы его можно было оперативно править.
Порог суммы как настраиваемая константа: счета до заданной суммы уходят сразу на оплату бухгалтеру, минуя гендиректора.
Порог вынесли в отдельную константу - клиент меняет её сам, без обращения к интегратору.
Делегирование и массовое согласование счетов для гендиректора:
руководитель работает с пакетом счетов прямо из списка - массово отклоняет или согласовывает в несколько кликов, по спорным позициям делегирует счёт сотруднику с комментарием, а доработанный счёт возвращается обратно к нему.
Отдельно отработали механику кнопок согласования, чтобы свести к минимуму ошибочные нажатия.
Сбор закрывающих документов с контролем сроков:
после оплаты процесс автоматически ставит задачу на сбор закрывающих, при просрочке напоминает и переставляет задание; заявка закрывается только после подтверждения бухгалтером.
Поддержали сложные сценарии - частичную и полную приёмку, авансы несколькими платежами, отсрочки.
Единое хранение документов на Диске Битрикс24:
процесс сам формирует структуру папок Документы по БП - контрагент - номер документа-основания и складывает туда счёт, платёжку и закрывающие; ссылка выводится в карточке и в задании, а доступ выдаётся через закрытую группу безопасности Согласование счетов.
Понятные названия и прозрачность пути счёта:
автоформирование названий (за что платим, номер и дата счёта, организация, кому платим, сумма) и наглядная дорожка движения в карточке - кто и на каком этапе согласовал.
Поле Утверждён заполняется только после финального согласования гендиректора, и именно по нему бухгалтерия отбирает счета к оплате и в реестр.
Сложности, через которые прошли
В лидогенерации корень проблемы был частично вне Битрикс24: у клиента сменился почтовый сервер, из-за чего часть ящиков переставала работать
а маркетплейс-приложение интеграции стало неактивным - мы ушли от него к собственному вебхуку и отдельно дорабатывали логику привязки писем (входящее связывается с лидом по теме, отправителю и получателю).
В закупках и счетах логика согласования менялась многократно: добавлялись юрлица, типы оплаты, новые согласующие, отдельные правила для маркетинга, аренды и личных поручений руководства, сценарии делегирования сбора документов.
Часть процесса по счетам досталась в наследство от прежнего подрядчика и была плохо сопровождаемой - мы переписали её заново.
Отдельно прорабатывали неудобную механику кнопок согласовать, делегировать, отклонить: системную кнопку Битрикс24 нельзя убрать без снятия прав администратора, поэтому действия переименовали и перенастроили так, чтобы поведение стало предсказуемым.
Именно гибкость автоматизации бизнес-процессов позволила держать систему в рабочем состоянии при постоянных изменениях.
Результат:
Вместо хрупких ручных решений у медицинского холдинга появились три устойчивых автоматизированных контура на одном портале Битрикс24.
По лидогенерации:
Компания: ГК Приоритет
О компании: медицинский холдинг из Санкт-Петербурга, объединяющий сеть клиник и диагностических центров
Число сотрудников работающих в Битрикс24: 170
Город: Санкт-Петербург
Задачи клиента:
На одном портале сошлись три крупных направления, и в каждом накопился свой узел проблем.
Направление 1. Лидогенерация - поставочное подразделение теряло входящие обращения:
- Интеграция сайта с CRM перестала работать. Передача заявок с сайта в Битрикс24 шла через приложение из Маркета, которое в какой-то момент стало неактивным, и заявки переставали попадать в систему - менеджеры узнавали о клиентах с опозданием или не узнавали вовсе.
- Заявки с почты не превращались в лиды - письма приходили в ящик, но лид в CRM заводили руками.
- Лиды были слепыми - не хватало полей для работы (поставщики, авторизация, ссылка на диск), не было автоматического создания сделки и переноса данных при конвертации лида в сделку.
- Переписка терялась - ответные письма не подвязывались к нужному лиду.
- Накопился мусор - больше 1100 старых лидов мешали начать с чистого листа.
- Заявки на закупку жили в ручном режиме: не было единого процесса, который провёл бы потребность от заявителя через все согласования до создания счёта и оплаты.
- Дорогие покупки согласовывались вслепую: по оборудованию руководству нужно было обоснование - окупаемость, сравнение аналогов, - но собрать его в одном месте и довести до гендиректора в готовом виде было нечем.
- Цепочка согласования сложная и разная: в зависимости от типа закупки и организации заявку должны утверждать центр затрат, снабжение, коммерческий и финансовый отделы, медицинский директор и гендиректор - в нужном порядке.
- Регулярные закупки (канцелярия) заводились вручную каждый месяц, про них забывали.
- Не было прозрачности и разграничения прав: сотрудники видели чужие заявки, а инициатор не понимал, на ком зависла его потребность.
- Гендиректор был бутылочным горлышком: в пиковые периоды на согласовании одновременно скапливалось до 400 счетов, по каждому приходилось разбираться вручную, а часть оплат рисковала зависнуть.
- Счета терялись: инициатор видел статус на согласовании, но фактически счёт мог стоять у любого из 2-3 согласующих, и отследить это было невозможно.
- Разные цепочки для разных юрлиц и типов оплаты: по Приоритет Диагностике и Шаврова счёт обязан пройти через медицинского директора, а по Приоритету и ИП Топольсков уходить сразу к гендиректору; плюс десятки типов оплаты (медицинский расходник, ОМС, стоматология, мебель, оборудование, аренда, маркетинг, под пациента, канцелярия, транспортные расходы и другие) со своими согласующими.
- Мелкие счета тормозили так же, как крупные: платежи до порога не имело смысла гонять через гендиректора, но процесс этого не учитывал.
- Документы по счетам были разбросаны, а контроль сбора закрывающих после оплаты отсутствовал - задачи провисали без напоминаний.
Решение задачи:
Работу разбили на контуры и под каждый собрали свои смарт-процессы Битрикс24 и логику автоматизации бизнес-процессов.
Первый контур - лидогенерация и интеграция сайта с Битрикс24:
Заменили нестабильное приложение на собственную интеграцию.
Отказались от приложения из Маркета и реализовали передачу заявок с сайта через вебхук: на стороне сайта разработчик клиента настроил отправку данных, на стороне Битрикс24 мы приняли их и разложили в смарт-процесс Лиды АМД.
Поток заявок больше не зависит от стороннего приложения.
Настроили маршрутизацию заявок с почты:
каждое письмо с почты заявок автоматически создаёт лид. Учли ограничение Битрикс24 - письма от сотрудников портала нельзя сохранять в CRM - и выстроили корректную схему получения заявок без потери данных.
Доработали смарт-процесс Лиды АМД:
настроили стадии воронки, включая провальные (вышедшая процедура, частное лицо и другие), добавили множественное добавление поставщиков, ссылку на диск, блок авторизации; на второй стадии настроили автоматическую задачу для менеджера.
Связали лид со сделкой без потери данных:
при конвертации наименование и поля переносятся автоматически, зашили маршрутизацию по типу закупки (прямая продажа уходит в воронку Отправлено КП, тендер - в Формирование ТЗ), настроили создание сделки в Прямых продажах и корневой папки клиента на диске с папками по проектам.
Так настроенные воронки продаж Битрикс24 ведут каждое обращение по своему сценарию без ручного разбора.
Привязали переписку к карточке, в том числе через приложение копирования таймлайна: ответные письма подвязываются к тому лиду, из которого отправлены, и история общения хранится в карточке.
Навели порядок в данных - очистили более 1100 устаревших лидов.
Второй контур - сквозной бизнес-процесс согласования заявок на закупку:
Построили смарт-процесс Заявка на закупку со стадиями от запуска заявки до оплаты:
согласование центром затрат, подбор силами снабжения, согласование коммерческого и финансового отделов, согласование гендиректора, создание счетов на согласование, ожидание оплаты, получение товара.
Запуск настроили так, чтобы система всегда фиксировала инициатора.
Добавили обоснование закупки для решения гендиректора:
перед ним встроили два этапа, где коммерческий и финансовый отделы последовательно заполняют файл-шаблон окупаемости и сравнения аналогов.
Шаблон автоматически прикрепляется в задание, поле под сравнительные таблицы сделали множественным, снабжение дополняет итоговый файл перед финальным согласованием. В результате гендиректор получает заявку с готовым обоснованием и комментариями всех участников.
Зашили условную логику маршрутизации:
согласование коммерческого и финансового отделов включается только для нужных типов закупки (оборудование, под пациента, стоматология-оборудование и подобные); для работ, услуг и аренды согласование идёт по структуре снизу вверх.
Если автор заявки сам является согласующим центром затрат, его шаг пропускается, чтобы человек не утверждал заявку сам себе.
Автоматизировали регулярные закупки:
шаблон-планировщик сам создаёт заявку на канцелярию в нужную дату каждого месяца, ставит срок и задачу заявителю заполнить шаблон по активной ссылке; если за срок заявку не отработали, она закрывается.
Связали заявку с реестром ЛУ и навели порядок в правах:
настроили создание записей реестра ЛУ из счетов по заявке, чат для обсуждения с наблюдателями, автоформирование понятного наименования (ID, организация, отделение или специализация, тип заявки, ФИО заявителя, наименование закупки).
Разграничили доступы: каждый видит свои заявки, руководители - все; быстрый доступ к процессу вынесли в левое меню.
Третий контур - сквозной бизнес-процесс Счёт на оплату 2025
который проводит счёт от загрузки до оплаты и сбора закрывающих документов. Главной задачей было настроить согласование счетов в Битрикс24 так, чтобы один процесс закрыл всю разнородную структуру холдинга:
Маршруты согласования по юрлицу и типу оплаты:
процесс сам определяет цепочку согласующих. Для юрлиц с медицинским директором счёт идёт по маршруту центр затрат - медицинский директор - гендиректор, для остальных организаций напрямую к гендиректору;
под каждый из более чем десятка типов оплаты зашиты свои согласующие, а список вынесен так, чтобы его можно было оперативно править.
Порог суммы как настраиваемая константа: счета до заданной суммы уходят сразу на оплату бухгалтеру, минуя гендиректора.
Порог вынесли в отдельную константу - клиент меняет её сам, без обращения к интегратору.
Делегирование и массовое согласование счетов для гендиректора:
руководитель работает с пакетом счетов прямо из списка - массово отклоняет или согласовывает в несколько кликов, по спорным позициям делегирует счёт сотруднику с комментарием, а доработанный счёт возвращается обратно к нему.
Отдельно отработали механику кнопок согласования, чтобы свести к минимуму ошибочные нажатия.
Сбор закрывающих документов с контролем сроков:
после оплаты процесс автоматически ставит задачу на сбор закрывающих, при просрочке напоминает и переставляет задание; заявка закрывается только после подтверждения бухгалтером.
Поддержали сложные сценарии - частичную и полную приёмку, авансы несколькими платежами, отсрочки.
Единое хранение документов на Диске Битрикс24:
процесс сам формирует структуру папок Документы по БП - контрагент - номер документа-основания и складывает туда счёт, платёжку и закрывающие; ссылка выводится в карточке и в задании, а доступ выдаётся через закрытую группу безопасности Согласование счетов.
Понятные названия и прозрачность пути счёта:
автоформирование названий (за что платим, номер и дата счёта, организация, кому платим, сумма) и наглядная дорожка движения в карточке - кто и на каком этапе согласовал.
Поле Утверждён заполняется только после финального согласования гендиректора, и именно по нему бухгалтерия отбирает счета к оплате и в реестр.
Сложности, через которые прошли
В лидогенерации корень проблемы был частично вне Битрикс24: у клиента сменился почтовый сервер, из-за чего часть ящиков переставала работать
а маркетплейс-приложение интеграции стало неактивным - мы ушли от него к собственному вебхуку и отдельно дорабатывали логику привязки писем (входящее связывается с лидом по теме, отправителю и получателю).
В закупках и счетах логика согласования менялась многократно: добавлялись юрлица, типы оплаты, новые согласующие, отдельные правила для маркетинга, аренды и личных поручений руководства, сценарии делегирования сбора документов.
Часть процесса по счетам досталась в наследство от прежнего подрядчика и была плохо сопровождаемой - мы переписали её заново.
Отдельно прорабатывали неудобную механику кнопок согласовать, делегировать, отклонить: системную кнопку Битрикс24 нельзя убрать без снятия прав администратора, поэтому действия переименовали и перенастроили так, чтобы поведение стало предсказуемым.
Именно гибкость автоматизации бизнес-процессов позволила держать систему в рабочем состоянии при постоянных изменениях.
Результат:
Вместо хрупких ручных решений у медицинского холдинга появились три устойчивых автоматизированных контура на одном портале Битрикс24.
По лидогенерации:
- Заявки с сайта снова попадают в CRM автоматически - боевые обращения появились уже в первый день после запуска, а поток перестал зависеть от стороннего приложения.
- Ни одно обращение не теряется: письма с почты создают лиды без ручного переноса, переписка хранится в карточке.
- Менеджеры работают с живыми лидами, а не с архивом, - после очистки более 1100 старых записей.
- Лид бесшовно становится сделкой и сам уходит в нужную воронку (прямая продажа или тендер), а по каждому клиенту создаётся структурированная папка с проектами.
- Закупки проходят по единому управляемому процессу - от потребности заявителя до создания счёта и оплаты, с понятным статусом на каждом этапе.
- Гендиректор принимает решение по дорогим покупкам с готовым обоснованием: окупаемость и сравнение аналогов собирают коммерческий, финансовый отделы и снабжение.
- Регулярные закупки больше не требуют ручного контроля - ежемесячная заявка на канцелярию создаётся автоматически в нужную дату со сроком отработки.
- Каждый видит только свои заявки, руководители видят всё, а быстрый доступ к процессу вынесен в меню.
- Накопившиеся до 400 счетов на согласовании у гендиректора удалось расшить, а массовое согласование сократило обработку пакета до нескольких кликов.
- Потерянных счетов больше нет: в карточке виден весь путь счёта и то, на ком он стоит прямо сейчас.
- Один процесс закрыл потребности 5+ организаций холдинга и более десятка типов оплаты без отдельных ручных маршрутов.
- Мелкие платежи перестали отвлекать руководство - счета до порога уходят прямо в оплату, а сам порог клиент меняет через константу.
- Счёт, платёжка и закрывающие складываются в папку контрагента, и бухгалтерия находит документ по прямой ссылке; контроль закрывающих больше не теряется, а сроки оплаты видны заранее.
Название проекта
Согласование 400+ счетов без потерь: единый бизнес-процесс оплаты для медицинского холдинга из 5 юрлиц
Проект партнера
WebMens
Сфера бизнеса
PR, маркетинг, реклама
Тип проекта
Облачный Битрикс24, SRM портал для поставщиков
Год публикации
2026
Узнать стоимость внедрения