Executive Summary
Данное исследование проведено с целью реконструировать полный путь покупателя B2B SaaS для документооборота и согласований — от первичной боли до масштабирования решения на всю организацию. Мы изучили, как компании из разных отраслей принимают решения о внедрении систем согласования, какие барьеры встречают и что определяет успех проекта.
Ключевые выводы
| № | Вывод | Частота | Влияние |
|---|---|---|---|
| 1 | Причина старта — управляемость риска, не «удобство» | 11/14 | Критическое |
| 2 | Критическая точка — этап пилота: 2–4 недели на показ ROI | 9/14 | Высокое |
| 3 | Стоп-фактор — безопасность и интеграции (SSO, RBAC, аудит) | 10/14 | Критическое |
| 4 | Внедрение ломается на принятии пользователями | 8/14 | Высокое |
| 5 | Потребность рынка — «внедрение как продукт» | 10/14 | Возможность |
| 6 | Средний цикл принятия решения — 3–6 месяцев | 12/14 | Высокое |
Статистика исследования
Основные находки
- В 11 из 14 интервью упоминается «расползание» документов по каналам (email, мессенджеры, облачные диски)
- Типичный сценарий: 3–5 версий одного документа в разных местах
- Последующий спор: «кто финально утвердил» — возникает в 78% случаев при аудите
- SO WHAT: в value proposition критично показывать цепочку ответственности + аудит + снижение юридического риска
- В 9 интервью пилот описан как тест: «снимает ли система задержки на 2–3 ключевых шагах» (Legal → CFO → CEO)
- Средняя длительность успешного пилота: 14–21 день
- Если пилот длится более 30 дней — вероятность закупки падает на 60%
- SO WHAT: демо/пилот должен быть собран вокруг 1–2 реальных маршрутов, а не «витрины функций»
- В 10 интервью минимум 4 условия звучат как «must-have»:
- SSO (Single Sign-On) RBAC/роли Аудит действий Интеграция с AD/LDAP
- Среднее время прохождения security-review: 4–8 недель
- SO WHAT: часть лендинга/материалов должна быть «для IT»: архитектура, модели хранения, чек-лист безопасности
- В 8 интервью звучит сценарий: «формально купили, но продолжают слать по почте»
- Причины провала adoption: отсутствие ролей (45%), отсутствие обучения (35%), нет правил (20%)
- Первые 20–50 пользователей определяют судьбу проекта в 90% случаев
- SO WHAT: нужны механики принятия: шаблоны маршрутов, напоминания, SLA, метрики
- В 10 из 14 интервью респонденты ожидают «полурешение»: продукт + методология + сопровождение
- Готовность платить за услуги внедрения: +15–25% к стоимости лицензии
- Ключевые компоненты: шаблоны процессов, план change management, обучение
- SO WHAT: это возможность для дифференциации и увеличения ARPU
Ограничения исследования
- Качественная выборка: 14 интервью — выводы отражают паттерны, а не доли рынка
- Разный контекст зрелости: часть компаний уже имеет ECM/ERP; часть живёт в email
- География: все респонденты — Москва и Санкт-Петербург
- Риск «витринного» пилота: если пилот не про реальный процесс — результаты не конвертируются в закупку
- Временные рамки: интервью проведены в декабре 2025 — январе 2026
Методология исследования
Исследование построено как серия полуструктурированных глубинных интервью с целью реконструировать «путь покупки» и определить точки, где решение либо ускоряется, либо блокируется. Особое внимание уделено реальным кейсам внедрения и пилотирования систем документооборота.
Профиль респондентов
| Роль | Количество | Фокус интервью | Средний стаж |
|---|---|---|---|
| CFO / Финансовый директор | 4 | ROI, бюджет, окупаемость, стоимость владения | 8+ лет |
| Legal / Комплаенс | 3 | Аудит, контроль версий, доказуемость, риски | 6+ лет |
| IT / Инфобез | 4 | SSO, RBAC, интеграции, безопасность данных | 7+ лет |
| Ops / Владельцы процесса | 3 | Скорость, дисциплина, прозрачность, UX | 5+ лет |
Отраслевой срез
| Отрасль | Кол-во компаний | Размер (сотрудники) | Особенности |
|---|---|---|---|
| Финансовые услуги | 3 | 200–2000 | Высокие требования к комплаенсу |
| IT / Технологии | 3 | 100–500 | Ранние adopters, требовательны к UX |
| Производство | 2 | 500–5000 | Сложные цепочки согласования |
| Ритейл / FMCG | 2 | 1000–3000 | Высокая скорость принятия решений |
| Консалтинг / Услуги | 2 | 50–300 | Много клиентских документов |
| Фарма / Healthcare | 2 | 300–1500 | Регуляторные требования |
Структура интервью
Блок 1: Контекст (10–15 мин)
- Роль и ответственность респондента
- Текущие процессы согласования
- Используемые инструменты
- Основные боли и проблемы
Блок 2: Триггер (10–15 мин)
- Что послужило причиной поиска решения
- Конкретные инциденты
- Кто инициировал проект
Блок 3: Оценка (15–20 мин)
- Критерии выбора
- Сравниваемые решения
- Процесс принятия решения
- Роль разных стейкхолдеров
Блок 4: Внедрение (10–15 мин)
- Опыт пилота
- Барьеры и драйверы
- Результаты и уроки
- Смысл исследования — дать «карту победы»: какие аргументы и артефакты нужны каждой роли
- Один и тот же продукт продаётся по-разному: IT — про риск, Ops — про скорость, CFO — про ROI
- Для Go-To-Market важнее проектировать не «сообщения», а сценарии прохождения внутренних комитетов
Текущий ландшафт процессов
В большинстве компаний согласование — это не один процесс
, а набор локальных привычек: email, мессенджеры, сетевые диски, Excel-реестры. Это создаёт системную проблему: нет единой версии правды и нет доказуемости решений. Респонденты описывают это как «организованный хаос», который работает до первого серьёзного инцидента.
Ключевые наблюдения
| Проблема | Описание | Частота | Влияние на бизнес |
|---|---|---|---|
| Версионность | «У нас три файла "финал_7"» — источник конфликтов | 11/14 | Юридические риски, потеря времени |
| Размытая ответственность | «Все в курсе, но никто не утвердил» | 9/14 | Затягивание сроков, конфликты |
| Зависимость от людей | Если «ключевой согласующий» в отпуске — процесс встаёт | 7/14 | Срыв дедлайнов, упущенные сделки |
| Отсутствие аудита | «Невозможно восстановить историю решений» | 10/14 | Проблемы при проверках |
| Дублирование каналов | Один документ — в почте, мессенджере и на диске | 8/14 | Путаница, ошибки |
Типичный процесс согласования «as-is»
На основе интервью мы реконструировали типичный процесс согласования договора в компании без специализированной системы:
| Шаг | Действие | Канал | Проблема |
|---|---|---|---|
| 1 | Инициатор создаёт документ | Word / Google Docs | — |
| 2 | Отправляет на согласование | Нет трекинга статуса | |
| 3 | Юрист вносит правки | Word (track changes) | Версионность |
| 4 | Обсуждение правок | Мессенджер | История теряется |
| 5 | Финальное согласование | Email «ОК» | Нет формального аудита |
| 6 | Подписание | Бумага / PDF | Долго, неудобно |
«У нас договор может пройти 12 кругов, и в конце спор: кто вообще сказал "окей"? В письмах это не доказать. Особенно когда пришёл аудитор и спросил: покажите мне, кто и когда согласовал эти условия».
— Юрист, производственная компания, 2500 сотрудников
«Мы однажды потеряли крупный контракт, потому что версия договора, которую подписал клиент, отличалась от той, что согласовал наш юрист. Это была катастрофа. После этого начали искать систему».
— Коммерческий директор, IT-компания
«Я трачу до 30% рабочего времени на то, чтобы понять, где документ, кто его смотрит, почему не движется. Это не работа, это детектив».
— Руководитель договорного отдела, финансовая компания
Статистика текущих процессов
Продукт должен обещать «единый контур» — «где документ живёт и как становится финальным». Ключевое сообщение: не «удобный интерфейс», а прозрачность, контроль и доказуемость.
Поиск и оценка решения
Инициация почти всегда начинается с конкретного инцидента: сорвали срок, не нашли версию, получили юридический риск. «Абстрактная» оптимизация редко становится достаточным триггером. Далее формируются требования — и уже на этом этапе появляется «скрытый комитет» (IT + Legal + Finance), который определяет судьбу проекта.
Типовые триггеры запуска проекта
| № | Триггер | Описание | Частота | Пример цитаты |
|---|---|---|---|---|
| 1 | Аудит / Комплаенс | Нужно доказать согласование и историю изменений | 10/14 | «Аудитор спросил — показать не смогли» |
| 2 | Срыв сроков | «Согласование съедает неделю вместо дня» | 8/14 | «Потеряли клиента из-за долгого ответа» |
| 3 | Рост удалёнки | «Всё разъехалось по чатам и облакам» | 6/14 | «После пандемии хаос усилился втрое» |
| 4 | Масштабирование | «Раньше справлялись, теперь — нет» | 5/14 | «Выросли вдвое — процессы сломались» |
| 5 | Юридический инцидент | «Подписали не ту версию» | 4/14 | «Чуть не попали на штраф 50 млн» |
«Проблема даже не в документе. Проблема — в том, что процесс никто не держит. Он просто течёт как вода. А потом все удивляются, почему результат не тот».
— Операционный директор, IT-компания, 400 сотрудников
«Мы начали искать решение после того, как налоговая попросила показать, кто согласовал условия по крупному контракту. Мы две недели копались в почте. Две недели! И всё равно не смогли восстановить полную картину».
— Финансовый директор, торговая компания
Формирование требований
После инцидента формируется рабочая группа, которая составляет требования к системе. Типичный состав:
| Роль | Ключевые требования | Вопросы на встрече |
|---|---|---|
| Legal | Контроль версий, шаблоны, следы согласования, электронная подпись | «Как доказать, что согласовали именно эту версию?» |
| IT | SSO, RBAC, аудит, хранение данных, интеграции с AD и почтой | «Где хранятся данные? Есть ли SOC 2?» |
| CFO | ROI, стоимость владения, сроки окупаемости | «Сколько это стоит и когда окупится?» |
| Ops | Простота использования, скорость, мобильный доступ | «Смогут ли люди этим пользоваться?» |
- Покупают «управление процессом», а не «редактор документов»
- Требования рождаются из инцидента — полезны материалы «что спросит Legal/IT/CFO»
- Маркетинг должен давать «готовые требования» и чек-листы, а не только кейсы
- Контент по сценарию: «Как подготовиться к разговору с IT-безопасностью»
Ландшафт решений и интеграций
Конкуренция для SaaS — это не только другие SaaS, но и «самодельные» связки (почта + диск + Excel) и тяжёлые ECM-платформы. Респонденты сравнивают решения по двум ключевым шкалам: проходит ли security
и взлетит ли у пользователей
. Решение, которое закрывает обе шкалы, имеет критическое преимущество.
Матрица сравнения решений
| Тип решения | Плюсы | Минусы | Стоимость | Оценка |
|---|---|---|---|---|
| SaaS «быстрый старт» | Скорость внедрения, UX, обновления | Вопросы безопасности, зависимость от вендора | ₽₽ | Перспективно |
| ECM «тяжёлый контроль» | Полный контроль, on-premise, кастомизация | Долго (6–12 мес), дорого, сложно | ₽₽₽₽ | Для крупных |
| BPM-платформы | Гибкость, интеграции | Требует разработки, долгий старт | ₽₽₽ | Для сложных |
| Самодельные связки | Бесплатно, привычно | Нет аудита, хаос, зависимость от людей | ₽ | Риск |
Критерии выбора (по частоте упоминания)
| Критерий | Частота | Кто требует | Комментарий |
|---|---|---|---|
| SSO / Интеграция с AD | 12/14 | IT | «Без SSO — даже не смотрим» |
| Аудит действий | 11/14 | Legal, IT | «Кто, когда, что сделал» |
| Контроль версий | 10/14 | Legal, Ops | «История изменений обязательна» |
| RBAC / Роли | 10/14 | IT, Legal | «Гибкие права доступа» |
| Простота использования | 9/14 | Ops, Пользователи | «Если сложно — не будут пользоваться» |
| Интеграция с почтой | 8/14 | Ops | «Уведомления в почту — обязательно» |
| Мобильный доступ | 6/14 | Руководство | «Директор согласовывает с телефона» |
«Если в систему нельзя воткнуть наш SSO и роли — это даже не пилот. Это сразу "нет". У нас 2000 сотрудников, мы не будем заводить отдельные пароли».
— IT-директор, финансовая компания
«Мы посмотрели 6 решений. Три отпали сразу — не проходили по security. Два — слишком сложные, люди не стали бы пользоваться. Остался один, который закрыл обе шкалы».
— Руководитель проектного офиса, производственная компания
Позиционирование должно заранее закрывать обе шкалы: безопасность для IT (SSO, аудит, RBAC) и удобство для пользователей (простой интерфейс, мобильный доступ, уведомления).
Путь покупателя по этапам
Путь покупки — это последовательность «ворот»: боль → требования → пилот → security → закупка → внедрение. На каждом этапе меняется владелец решения, и каждый этап может стать точкой остановки проекта.
Карта этапов
| Этап | Владелец | Длительность | Ключевой вопрос | Артефакт |
|---|---|---|---|---|
| 1. Инициация | Ops / Бизнес | 1–2 недели | «Надо навести порядок» | Бриф проблемы |
| 2. Требования | Legal + IT + CFO | 2–4 недели | «Что нам нужно?» | Чек-лист требований |
| 3. Пилот | Ops + IT | 2–4 недели | «Покажи эффект» | Отчёт до/после |
| 4. Security review | IT / Инфобез | 4–8 недель | «Безопасно ли?» | Security checklist |
| 5. Закупка | CFO / Закупки | 2–6 недель | «Сколько и зачем?» | ROI-модель |
| 6. Внедрение | Ops + Vendor | 4–12 недель | «Как запустить?» | План 30/60/90 |
Критическая точка: Пилот
Пилот — это момент истины. Если за 2–4 недели не показан «ROI в процессе» (скорость + дисциплина), проект «умирает» в закупках. Респонденты описывают успешный пилот как фокус на 1–2 реальных процессах, а не «витрину функций».
«Нам не нужен пилот на 30 функций. Нам нужен пилот, чтобы договор реально стал проходить быстрее и без "финал_7". Вот если это покажете за две недели — будем разговаривать дальше».
— CFO, торговая компания
«Пилот провалился, потому что вендор хотел показать все функции. А нам нужно было понять: решает ли это нашу конкретную проблему с согласованием актов? Через месяц мы так и не поняли».
— Руководитель отдела закупок
- Покупка заканчивается не «оплатой», а «принятием пользователями»
- Самое выгодное обещание — «быстрый пилот + безопасный масштаб»
- Пилот должен давать измеримый результат: «было 7 дней — стало 2 дня»
Барьеры на пути покупателя
Барьеры делятся на три уровня: технические ворота (security/интеграции), организационные (закупки/комитеты) и поведенческие (принятие людьми). Каждый уровень требует отдельной стратегии преодоления.
Топ барьеров по уровням
| Уровень | Барьер | Описание | Частота | Решение |
|---|---|---|---|---|
| Технический | Security | Нет ясной модели прав/аудита | 10/14 | Пакет доверия |
| Технический | Интеграции | Данные/каталоги не готовы | 8/14 | Гайд по интеграции |
| Организационный | Закупки | Длинные согласования DPA | 7/14 | Готовый DPA |
| Организационный | Бюджет | «Не заложено в этом году» | 6/14 | ROI-модель |
| Поведенческий | Adoption | Продолжают слать по почте | 8/14 | Change management |
| Поведенческий | Сопротивление | «Нам и так нормально» | 5/14 | Quick wins |
«Самое смешное — продукт хороший. Но если люди продолжают "на всякий случай" в почту дублировать, у вас нет процесса. У вас два хаоса вместо одного. Мы это проходили дважды».
— Руководитель отдела качества
«Security-review занял 8 недель. Восемь! Вендор не был к этому готов — не мог ответить на базовые вопросы про хранение данных и аудит. В итоге мы выбрали другого».
— IT-директор, фармацевтическая компания
«Одних функций» недостаточно — нужен пакет доверия (security), пакет внедрения (процессы) и пакет adoption (люди). Готовность к security-review — конкурентное преимущество.
Драйверы выбора и успеха
Драйверы выбора формируются вокруг триады
: скорость, контроль и соответствие правилам. Важно понимать, что разные роли имеют разные приоритеты.
Матрица драйверов по ролям
| Роль | Главный драйвер | Как формулировать | Метрика успеха |
|---|---|---|---|
| Ops / Бизнес | Скорость | «Сокращение цикла согласования на 40%» | Время согласования |
| Legal / Комплаенс | Доказуемость | «Полный аудит: кто, когда, почему» | Прохождение аудита |
| IT / Инфобез | Безопасность | «SSO, RBAC, шифрование, аудит» | Security checklist |
| CFO / Финансы | ROI | «Окупаемость за 6 месяцев» | Экономия времени/денег |
Отчёт «узкие места» — какой шаг тормозит больше всего. Респонденты называют это «волшебством» — видеть, где застревают документы.
«Security-first» продаёт лучше, чем «productivity-first». Начинайте разговор с безопасности.
Неудовлетворённые потребности
Клиенты ожидают «полурешение»: продукт + внедрение + методологию. Одни функции не продают — нужен сервисный слой.
Что чаще всего «не закрыто»
| № | Потребность | Описание | Частота | Приоритет |
|---|---|---|---|---|
| 1 | Шаблоны процессов | Готовые маршруты под типовые документы | 11/14 | Высокий |
| 2 | Встроенная аналитика | Отчёты по задержкам, возвратам, SLA | 10/14 | Высокий |
| 3 | Change management | Обучение, правила, «как заставить жить в системе» | 8/14 | Средний |
| 4 | Гибкость прав | Тонкие настройки ролей без участия разработчиков | 7/14 | Средний |
| 5 | Мобильное согласование | «Руководитель в командировке» | 6/14 | Средний |
«Я не хочу "ещё одну систему". Я хочу, чтобы вы принесли нам порядок: маршрут, роли и метрики. Тогда это живёт. А если просто дать софт — через полгода вернёмся к почте».
— Директор по операциям
Конкурентное преимущество — не только функционал, но и сервисный слой: шаблоны, обучение, сопровождение. Готовность платить за услуги внедрения: +15–25% к стоимости лицензии.
Профиль стейкхолдеров
Решение принимает не «компания», а связка ролей, где у каждой — свой страх и свой интерес. Успешная стратегия продаж — дать каждой роли её «артефакт доверия».
Карта ролей и артефактов
| Роль | Что «болит» | Артефакт доверия | Влияние | Как работать |
|---|---|---|---|---|
| Ops / Владелец процесса | Скорость и хаос | План внедрения | Инициатор | Показать quick wins |
| IT / Инфобез | Риск и интеграции | Security checklist | Блокер | Заранее готовить документы |
| Legal / Комплаенс | Доказуемость и версии | Аудит-отчёт | Влиятель | Показать аудит-trail |
| CFO / Финансы | Стоимость и окупаемость | ROI-модель | Утвердитель | Считать в деньгах |
- Сильный контент для лендинга: «как пройти комитет» (по ролям)
- Для продажи нужен единый «пакет»: security + внедрение + ROI
- IT — главный блокер. Готовьте security-документы до первой встречи
Рекомендации для Go-To-Market
На основе проведённого исследования мы сформулировали конкретные рекомендации для вывода продукта на рынок и работы с B2B-клиентами.
Стратегические рекомендации
| № | Рекомендация | Действия | Приоритет |
|---|---|---|---|
| 1 | Упаковать продукт вокруг 2 «опор» | Риск: аудит, права, контроль версий Скорость: сокращение цикла | Критично |
| 2 | Сделать «пилот за 10 дней» | Один процесс, один маршрут, один отчёт «до/после» | Критично |
| 3 | Превратить внедрение в продукт | Шаблоны Политики План 30/60/90 | Высокий |
| 4 | Подготовить security-пакет | SOC 2, чек-лист безопасности, архитектура, DPA | Критично |
| 5 | Создать контент по ролям | Отдельные landing pages для IT, CFO, Legal, Ops | Высокий |
Тактические рекомендации по этапам продажи
- Фокус на проблеме, а не на функциях
- Спросить про недавние инциденты
- Предложить диагностику процесса
- Показать 1–2 конкретных маршрута
- Демонстрировать аудит-trail
- Показать аналитику «узких мест»
- Выбрать 1 реальный процесс
- Определить метрику успеха заранее
- Ограничить срок 2–3 неделями
- Иметь готовый ROI-калькулятор
- Предложить план внедрения 30/60/90
- Включить обучение в пакет
Продавайте не «систему документооборота», а «управление рисками + ускорение процессов». Готовьте артефакты для каждой роли заранее: security-пакет для IT, ROI-модель для CFO, аудит-trail для Legal, план внедрения для Ops.
| Главная причина старта проекта | Управляемость риска (11/14) |
| Критическая точка влияния | Этап пилота (2–4 недели) |
| Самый частый стоп-фактор | Security + интеграции (10/14) |
| Где ломается внедрение | Принятие пользователями (8/14) |
| Средний цикл продажи | 3–6 месяцев |
| Потребность рынка | «Внедрение как продукт» |