Разработка сайта под бизнес-процессы компании отличается от разработки обычного лендинга тем, что сайт перестаёт быть визиткой и становится частью операционки: сюда стекаются заявки, здесь считается стоимость доставки, отсюда данные уходят в CRM и бухгалтерию. Как только процессов больше двух-трёх и они завязаны друг на друга, шаблонный конструктор начинает трещать по швам, а любая правка превращается в костыль поверх костыля. На одном проекте процесс согласования заявки шёл через три разных сервиса вручную, и после интеграции число ручных операций в отделе продаж упало примерно вдвое. За проекты на Tilda, WordPress и кастомных стеках я вывел для себя более-менее чёткую границу: где шаблон ещё справляется, а где его пора менять на архитектуру под процессы.
Когда шаблонный сайт перестаёт справляться с процессами
На одном проекте для оптового поставщика заявки с сайта на Tilda приходили на почту, менеджер копировал их в Google Таблицу, оттуда вручную считал скидку по объёму и отправлял счёт. При десяти заявках в день это работало, при пятидесяти отдел продаж начал захлёбываться, а часть заявок терялась в переписке. Смотрю на несколько признаков сразу, а не на один: по отдельности каждый терпим, вместе они означают, что сайт держится на честном слове сотрудников.
- Менеджер вручную переносит заявки из формы Tilda в Excel или amoCRM, потому что прямой интеграции нет.
- Статус заказа существует только в голове у сотрудника, в интерфейсе сайта и личном кабинете клиента его не видно.
- Для каждого нового условия скидки или зоны доставки приходится звать разработчика, чтобы дописать ещё одно условие в JS-скрипт на Tilda.
- В компании появляется вторая система, склад, бухгалтерия или служба поддержки, а сайт с ней никак не связан.
Если совпал один пункт, обычно хватает точечной доработки. Если три-четыре, ставка на конструктор уже не отбивается: время сотрудников на ручной перенос данных и ошибки из-за человеческого фактора обходятся дороже, чем нормальная интеграция систем между собой. Даже одна потерянная заявка в неделю при среднем чеке в несколько десятков тысяч рублей окупает интеграцию за один-два месяца.
Из каких процессов складывается техническое задание
Перед тем как писать код, прошу клиента расписать процесс так, как он идёт сейчас, шаг за шагом, а не так, как он должен выглядеть в идеале. На практике процесс почти всегда состоит из одних и тех же звеньев:
- приём заявки: сайт, форма, чат-бот или звонок;
- квалификация и распределение заявки по менеджерам;
- расчёт стоимости и доставки;
- оплата: эквайринг, счёт на юрлицо, рассрочка;
- выполнение заказа и уведомление всех участников;
- отчётность и аналитика по воронке.
Каждый пункт из этого списка превращается в отдельный раздел ТЗ с указанием, какая система отвечает за шаг, что происходит при сбое (не пришёл вебхук об оплате, СДЭК не ответил на запрос) и кто получает уведомление об ошибке.
Как я провожу обследование процесса
Созваниваюсь не только с руководителем, а с менеджером, который каждый день обрабатывает заявки: у него всегда всплывают исключения, которых нет в регламенте, вроде ситуации, когда клиент оплатил на месте, а заявка уже в статусе отмена. Схему процесса рисую в виде шагов со стрелками в Miro или Figma, отдельно отмечаю точки, где сейчас теряются данные или требуется ручное вмешательство, и присылаю клиенту на согласование до того, как перехожу к разделам самого ТЗ.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интеграции, которые чаще всего не влезают в шаблон
Сложнее всего в конструкторе даются не сами интеграции по отдельности, а их совместная работа. Разберу на трёх типовых узлах, с которыми сталкиваюсь чаще всего.
Оплата и статусы заказа
Пример из проекта на WooCommerce: эквайринг T‑Bank принимает оплату, но статус заказа должен одновременно обновиться в CRM, уйти клиенту в Telegram и попасть в СДЭК для расчёта доставки. В Tilda для похожих сценариев обычно пишут отдельный скрипт под каждую интеграцию, и когда их становится больше двух-трёх, скрипты начинают конфликтовать между собой за одни и те же поля формы. Если вебхук от эквайринга не пришёл с первого раза, в ТЗ должно быть прописано, сколько раз и с каким интервалом система повторяет попытку, иначе оплаченный заказ рискует зависнуть в статусе ожидания.
Доставка и расчёт по СДЭК
Расчёт стоимости через API СДЭК в реальном времени, с учётом веса, габаритов и зоны, в конструкторе делается отдельным виджетом. Для типовых сценариев такой уже готов, я публикую подобные решения в библиотеке готовых скриптов для Tilda. Но если зона доставки должна пересчитываться в зависимости от остатков на складе или статуса клиента в CRM, готового блока уже нет, и это задача под кастомную разработку.
Уведомления и автоматизация
Уведомления обычно переводят в Telegram: бот на aiogram получает вебхук от сайта или CRM и рассылает статус заказа менеджеру и клиенту без ручных пересылок. А склейку всех этих систем между собой, без написания отдельного бэкенда, закрываю через n8n: туда стекаются вебхуки с сайта, оттуда уходят запросы в СДЭК, CRM и Telegram, и вся логика видна в одном сценарии, а не размазана по десятку скриптов на сайте.
Tilda, WordPress или кастомная разработка: что выбрать под процессы
Платформу выбираю не по личным предпочтениям, а по тому, сколько логики нужно держать на стороне сайта и сколько ролей участвует в процессе.
| Платформа | Что настраивается без бэкенда | Где упирается в лимит | Когда достаточно |
|---|---|---|---|
| Tilda | формы, блоки, интеграции по API и вебхукам, кастомные скрипты на JS | многошаговые процессы, кастомные статусы, роли пользователей | лендинг, витрина, простая воронка с одной-двумя интеграциями |
| WordPress / WooCommerce | каталог, плагины, кастомные поля заказа, базовые роли | производительность при сложной логике, конфликты плагинов друг с другом | каталог с оплатой и доставкой, блог, стандартные процессы продажи |
| Кастомная разработка (Laravel, React, Next.js) | любая логика процессов, роли, статусы, личные кабинеты, отчёты | требует бэкенда и больше времени на старте | несколько ролей, сквозные процессы через 3+ систем, свои отчёты |
Домен в зоне .ru стоит одинаково что для лендинга на Tilda, что для интернет-магазина на WooCommerce, разница только в зоне: .ru дешевле .com. То же с SSL-сертификатом и комиссией эквайринга: комиссия зависит от тарифа банка, а не от того, на какой платформе стоит сайт.
Гибридный вариант: конструктор спереди, свой бэкенд сзади
Часто нет смысла выбрасывать готовый сайт на Tilda целиком. Оставляю его витриной и точкой входа для заявок, а логику процесса, статусы, роли и расчёты выношу в отдельный сервис, с которым сайт общается через вебхуки и API. Так делал для нескольких клиентов с оптовыми продажами: фронт остаётся на Tilda, а согласование заказов, скидки по объёму и синхронизация со складом живут в отдельном бэкенде на Laravel.
Что обязательно закладывать в ТЗ, чтобы не переделывать
Список ниже собран из реальных доработок, за которые клиенты потом доплачивали, потому что этого не было в исходном ТЗ.
- карта процесса по шагам с указанием ответственной системы на каждом этапе;
- роли и права доступа: менеджер, бухгалтер, склад, клиент в личном кабинете;
- статусы заявки или заказа и допустимые переходы между ними;
- список интеграций с форматом обмена данными: REST API, вебхук, выгрузка по расписанию;
- поведение при сбое интеграции, если СДЭК не ответил или вебхук об оплате не пришёл;
- нагрузка в пике и требования к хранению персональных данных клиентов на серверах в РФ, а не в иностранных облачных таблицах;
- кто вносит изменения в бизнес-логику после запуска и на каких условиях.
Роли и статусы часто недооценивают на старте: заказчик описывает процесс от лица одного менеджера, а по факту в нём участвуют ещё бухгалтер, который видит только оплаченные заказы, и склад, которому нужен список к отгрузке без лишних полей. Если не развести права доступа на этапе ТЗ, потом это делается поверх готовой системы и обходится дороже. Перед запуском отдельно проверяю каждый сценарий сбоя на тестовых данных, а не только основной happy path.Последний пункт часто упускают. Обслуживание системы после старта, будь то доработка правил расчёта доставки или новая роль в CRM, идёт отдельной строкой в договоре, а не молчаливым приложением к разработке.
Сроки и бюджет разработки под процессы
Ниже цены на конкретные задачи, которые чаще всего встречаются в проектах под бизнес-процессы. Итоговая стоимость складывается из числа интеграций, количества ролей и того, насколько процесс уже описан к моменту старта: чем подробнее карта процесса в ТЗ, тем меньше правок на этапе разработки.
| Задача | Цена |
|---|---|
| Доработка скрипта на Tilda под один процесс | от 3 000 ₽ |
| Комплексная интеграция Tilda с CRM, эквайрингом и СДЭК | от 40 000 ₽ |
| Автоматизация процессов в n8n | от 25 000 ₽ |
| Telegram-бот с уведомлениями на aiogram | от 30 000 ₽ |
| CRM или админ-панель на React | от 100 000 ₽ |
| Веб-сервис под сложные процессы, срок от 8 недель | от 300 000 ₽ |
| Техподдержка после запуска | от 15 000 ₽ в месяц |
На рынке за подобные интеграции студии и фрилансеры называют разные суммы, я видел вилки и в 20 000-80 000 рублей за похожую связку CRM и эквайринга, но точная цена всегда зависит от количества систем и от того, насколько процесс уже описан до старта работ.
Частые вопросы
Сколько стоит разработка сайта под бизнес-процессы компании?
Зависит от количества интеграций и сложности логики. Точечная доработка скрипта на Tilda под один процесс начинается от 3 000 ₽, комплексная интеграция CRM, эквайринга и доставки от 40 000 ₽, а отдельный веб-сервис под несколько ролей и сквозные процессы от 300 000 ₽.
Можно ли встроить процессы в готовый сайт на Tilda, не переделывая всё с нуля?
Частично можно: формы, вебхуки и кастомные скрипты закрывают приём заявки, расчёт доставки и уведомления. Как только нужны кастомные статусы, роли пользователей или логика, которая меняется в зависимости от данных из CRM, конструктор упирается в лимит и приходится выносить эту часть на отдельный бэкенд.
Сколько времени занимает разработка сайта под сложные бизнес-процессы?
Доработка существующего сайта под один процесс занимает от нескольких дней до двух недель. Отдельный веб-сервис с несколькими ролями и интеграциями я оцениваю от 8 недель, срок сильно зависит от того, насколько заранее описаны все шаги процесса.
Что делать, если процессы в компании ещё не описаны?
Начинать не с макета сайта, а с описания процесса как он есть сейчас: кто и на каком шаге что делает, какие системы участвуют, где сейчас теряются заявки. Это можно сделать на консультации перед стартом ТЗ, тогда разработка сразу идёт под реальные шаги, а не под догадки.