GETPROFF
Сайт начинает приносить пользу бизнесу не в момент публикации, а когда каждая заявка попадает в понятный рабочий процесс. Менеджеру нужно увидеть обращение, понять, какой продукт интересует клиента, связаться с ним, при необходимости сформировать ссылку на оплату и не пропустить подтверждение платежа. В этом уроке мы соберём такой процесс внутри Chatium: создадим CRM для заявок с сайта, подключим платёжного провайдера и настроим уведомления в Telegram.
Это не набор трёх независимых функций. Мы строим одну цепочку: посетитель заполняет форму, заявка появляется в CRM, дальше система либо сразу ведёт его к оплате, либо оставляет решение менеджеру, а ответственному человеку отправляет уведомление в Telegram. В итоге сайт, CRM, платежи и мессенджер работают как единая система.
В начале страницы размещается полное видео урока. Ниже — подробная текстовая инструкция со скриншотами, готовыми промптами и проверками после каждого этапа.
Что получится после урока
После настройки на сайте появится рабочая CRM. В ней будут храниться заявки, контакты клиентов, выбранные продукты, суммы, статусы и комментарии менеджера. Заявки можно будет смотреть таблицей или на канбан-доске, фильтровать по этапам и открывать в отдельных карточках.
К CRM будет привязан реальный платёжный провайдер. Для дорогих услуг и консультаций менеджер сможет сначала обсудить задачу с клиентом, согласовать состав работ и только затем создать ссылку на оплату из карточки заявки. Для продукта с фиксированной ценой, например онлайн-курса, система сможет формировать платёж автоматически сразу после заполнения формы.
Наконец, новые обращения и события оплаты будут дублироваться в Telegram. Это нужно не вместо CRM, а в дополнение к ней: CRM остаётся источником данных и рабочим местом менеджера, а Telegram помогает быстро заметить событие и не потерять клиента.
Вся схема выглядит так: форма на сайте создаёт заявку; CRM сохраняет и показывает её; платёжный провайдер отвечает за приём денег; Telegram-бот доставляет оперативное уведомление. Если один из элементов ещё не настроен, остальные можно проверить отдельно, а затем провести сквозной тест всей цепочки.
Что подготовить до настройки
Работу удобнее выполнять в уже созданном workspace с сайтом и формами. Если сайт ещё не готов, сначала закончите базовую структуру и убедитесь, что формы открываются и принимают данные. Ботану проще дорабатывать существующий проект, когда в нём уже определены услуги, курсы и сценарии обращения.
Для реальных платежей потребуется аккаунт у платёжного провайдера. В уроке показан GetPlatinum, но общий принцип тот же и для другого сервиса: понадобится идентификатор терминала, API-ключ и имя аккаунта либо другие реквизиты, которые выдаёт провайдер. Аккаунт должен быть оформлен на подходящий юридический статус, а условия приёма платежей, кассы и чеков нужно сверить с самим провайдером.
Для Telegram подготовьте обычный пользовательский аккаунт. Через официального бота BotFather мы создадим отдельного бота, получим токен и подключим его к Chatium как транспорт. Токены, API-ключи и внутренние идентификаторы нельзя публиковать в статьях, пересылать посторонним или вставлять в открытые чаты.
Создаём CRM для заявок с сайта
Первый этап — попросить Ботана добавить в существующий workspace CRM. Важно описать не просто страницу со списком контактов, а рабочий процесс: откуда приходят заявки, какие данные должны сохраняться, какие статусы нужны менеджеру и что он должен уметь делать из карточки клиента.
В уроке используется готовый промпт со страницы занятия. Если вы собираете систему для собственного проекта, его можно адаптировать под ваши формы и продукты. Чем точнее вы перечислите поля и сценарии, тем меньше исправлений понадобится после первой сборки.
Как поставить задачу Ботану
Ниже — рабочий вариант промпта. Он сохраняет логику урока, но формулирует результат так, чтобы Ботан не ограничился декоративным интерфейсом.
Продолжи работу внутри текущего Workspace. В нём уже созданы публичный сайт интегратора и защищённая админка `/admin` с единым левым сайдбаром и разделами «Услуги», «Кейсы», «Готовые решения» и «Отзывы». Не создавай отдельное приложение, новый Workspace или вторую админку. Сначала изучи существующую архитектуру, таблицы, маршруты, формы, компоненты, стили и права доступа. Затем органично расширь текущую систему: добавь в левый сайдбар пункт **«Заявки»** и создай внутри существующей админки полноценную CRM, связанную со всеми формами публичного сайта. ## Подключение форм сайта Сейчас формы работают только на уровне интерфейса. Подключи каждую из них к защищённому серверному созданию заявки, не меняя их внешний вид и сценарии успешной отправки: 1. Форма внутри конкретной услуги. 2. Форма «Хочу такой же результат» внутри кейса. 3. Форма внутри готового решения. 4. Форма консультации после расчёта в калькуляторе. 5. Форма покупки курса. 6. Общая форма консультации внизу сайта. Форма отзыва не является заявкой и продолжает работать через существующий раздел «Отзывы». Проведи аудит всех перечисленных форм. В каждой форме должны быть обязательные поля **«Имя»**, **«Email»** и **«Телефон»**. Если email или другое обязательное поле сейчас отсутствует, аккуратно добавь его, сохранив текущий дизайн формы. Проверяй корректность email и телефона как в интерфейсе, так и на сервере. Email сохраняй в заявке отдельным полем: он понадобится для идентификации клиента, создания платёжной ссылки и отправки платёжных документов. Не передавай персональные данные через URL. Для каждой заявки сохраняй: - уникальный ID; - дату создания и последнего изменения; - имя, телефон, email, компанию и комментарий клиента — в зависимости от полей конкретной формы; - понятный тип обращения; - точный источник: услуга, кейс, готовое решение, калькулятор, курс, общая консультация или ручное создание; - название формы и адрес страницы; - ID связанной услуги, кейса или готового решения, если он есть; - название выбранного объекта на момент отправки; - стоимость и срок, если они относятся к обращению; - для калькулятора — выбранную услугу, все дополнения, итоговую стоимость и рассчитанный срок; - текущий статус заявки; - статус оплаты; - внутренние заметки, следующий шаг и дату следующего контакта. Сохраняй одновременно ссылку на актуальную сущность и неизменяемый снимок значимых данных на момент отправки. Если администратор позднее переименует услугу или изменит её цену, старая заявка должна сохранить первоначальное название, состав и расчёт. Не доверяй стоимости, пришедшей из браузера. Для услуги, готового решения, курса и калькулятора повторно определяй или проверяй цену на сервере по существующим данным админки. Валидируй поля, защищай публичные endpoint от повторной отправки одной формы и не записывай персональные данные в URL или клиентские логи. После успешной отправки сохрани текущий визуальный ответ формы. Новая заявка должна сразу появляться в CRM со статусом **«Новая»**. Не создавай тестовые или вымышленные заявки для наполнения списка. ## Раздел «Заявки» Сохрани текущий каркас админки, левый сайдбар, шапку, цвета, шрифты и компоненты. В рабочей области раздела покажи: ### Быструю аналитику - всего заявок; - новые заявки; - требуют ответа; - ожидают оплаты; - потенциальная сумма сделок. Все показатели рассчитывай по реальным данным. Если заявок нет, показывай нули и понятное пустое состояние. ### Поиск и фильтры Добавь поиск по имени, телефону, email, компании и названию услуги или решения. Предусмотри фильтры по периоду, статусу, источнику, типу обращения и статусу оплаты, а также быстрые переключатели «Все», «Новые», «Нужен ответ» и «Ожидают оплаты». Источник должен быть хорошо заметен и в фильтрах, и в списке. Используй понятные подписи: - «Услуга: …»; - «Кейс: …»; - «Готовое решение: …»; - «Калькулятор: …»; - «Покупка курса»; - «Общая консультация»; - «Добавлено вручную». ### Таблицу и канбан Добавь переключение между двумя представлениями. В таблице покажи дату, клиента и контакты, источник обращения, выбранный продукт или услугу, стоимость, оплату и статус заявки. Разреши сортировку по дате, клиенту, стоимости и статусу. В канбане используй этапы: 1. Новая; 2. Связались; 3. Предложение отправлено; 4. Ожидает оплаты; 5. Оплачено; 6. В работе; 7. Завершено; 8. Отказ. Карточка канбана должна показывать имя клиента, источник, связанный продукт, стоимость и время последнего изменения. Разреши перетаскивать карточки между колонками, сразу сохраняй новый статус и фиксируй изменение в истории. Фильтры должны одинаково работать в таблице и канбане. Для большого списка используй серверную фильтрацию, сортировку и пагинацию, а не загрузку всей базы в браузер. ## Карточка заявки По клику на строку или карточку канбана открывай справа панель во всю высоту экрана — в том же формате, в котором уже редактируются услуги и готовые решения. Не используй отдельную страницу или центральную модалку. На мобильном панель занимает весь экран. Сгруппируй данные внутри панели: ### Основное - имя клиента; - дата и тип обращения; - редактируемый статус; - источник с названием связанной услуги, кейса, решения или курса; - быстрые действия: позвонить, написать на email и скопировать контакт. ### Контакты - имя; - телефон; - email; - компания; - комментарий клиента. ### Запрос - исходная форма; - выбранная услуга, кейс, решение или курс; - для калькулятора — полный состав выбранных дополнений; - первоначальная стоимость и срок; - редактируемая текущая сумма сделки. ### Работа с заявкой - внутренние заметки; - следующий шаг; - дата следующего контакта; - история создания и изменений статуса, суммы и оплаты. Предусмотри закреплённую шапку, прокручиваемое содержимое, кнопки «Сохранить» и «Отменить» и предупреждение о несохранённых изменениях. Внутренние заметки и история никогда не должны быть доступны посетителю сайта. ## Подготовка к оплате Платёжная система в Workspace пока не подключена. На этом этапе **не подключай эквайринг, не создавай платёжный провайдер, webhook или фиктивные ссылки**, но подготовь архитектуру для двух разных сценариев отправки формы: 1. **Консультация.** После отправки форма создаёт обычную заявку в CRM и показывает текущее сообщение об успешной отправке. Перехода к оплате нет. 2. **Прямая покупка.** Для платной услуги, готового решения или курса форма запрашивает имя, email и телефон. После будущего подключения платёжного провайдера отправка должна на сервере создать заявку и связанный с ней заказ, получить реальную платёжную ссылку и сразу перенаправить клиента на защищённую страницу оплаты провайдера. Для услуг и других продуктов, которые могут продаваться напрямую, предусмотри на уровне данных настраиваемый сценарий формы: **«Консультация»** или **«Сразу к оплате»**. Не определяй платный сценарий только по тексту кнопки или данным из браузера. В модели заявки и заказа заранее предусмотри сумму, статус оплаты, ID заказа, ID будущего платежа, ссылку на оплату и дату оплаты. Клиентские данные, выбранный продукт и стоимость проверяй на сервере; стоимость получай из актуальных данных админки, а не из браузера. Создание заявки, заказа и платёжной сессии должно быть защищено от дублей при повторном клике или обновлении страницы. Когда платёжный провайдер будет подключён, сервер должен передавать ему необходимые данные заказа и email клиента, сохранять полученные ID и платёжную ссылку, а браузеру возвращать только проверенный URL для редиректа. Оплату считай успешной только после подтверждения от провайдера через webhook, а не по факту возврата клиента на сайт. При ошибке создания ссылки уже созданная заявка не должна теряться: покажи понятную ошибку и возможность повторить оплату. Пока провайдер не подключён, прямая покупка создаёт заявку и заказ без редиректа, а пользователю показывает честное сообщение, что онлайн-оплата временно недоступна. В карточке CRM покажи блок «Оплата» с суммой и статусом **«Платёжная система не подключена»**. Кнопка «Создать ссылку на оплату» может присутствовать, но должна быть неактивной и сопровождаться пояснением «Ссылка станет доступна после подключения платёжной системы». Не придумывай маршрут настройки и не имитируй успешную оплату. Архитектура должна позволить позднее добавить серверное создание ссылки и подтверждение платежа без переделки CRM. ## Ручное создание заявки Добавь в разделе «Заявки» кнопку **«Добавить заявку»**. Она открывает ту же правую панель в режиме создания. Обязательны имя клиента, хотя бы один контакт и тип обращения; остальные поля можно заполнить позже. Источник такой записи — «Добавлено вручную». ## Визуальный стиль CRM должна выглядеть естественным продолжением существующей админки: - сохрани тёмно-синий сайдбар `#08101F` и `#10192B`; - используй молочный фон `#F7F1E8`, белые рабочие панели и оранжево-коралловый акцент `#FF5A2F`; - переиспользуй существующие шрифты, радиусы, тени, кнопки, поля и правые панели; - сделай интерфейс плотным и хорошо сканируемым, без рекламных блоков и декоративных иллюстраций; - различай статусы не только цветом, но и текстом или иконкой; - добавь понятные состояния загрузки, пустого списка, ошибки и успешного сохранения; - сохрани видимый клавиатурный фокус и адаптивность. На мобильном таблица превращается в компактный список карточек, канбан прокручивается внутри своей области, а карточка заявки открывается на весь экран. ## Проверка результата После реализации проверь: 1. Наличие и обязательную серверную валидацию имени, email и телефона в каждой из шести форм публичного сайта. 2. Появление заявок в CRM с правильным источником и связанными данными. 3. Сохранение полного расчёта из калькулятора. 4. Сохранение исторического снимка после изменения услуги в админке. 5. Поиск, фильтры, сортировку, таблицу и канбан. 6. Перемещение заявки между этапами. 7. Редактирование заявки, заметок, суммы и следующего шага. 8. Ручное создание заявки. 9. Недоступность CRM и персональных данных для посетителя сайта. 10. Неактивное и честно объяснённое состояние блока оплаты. 11. Разделение консультационного и платного сценариев: консультация не ведёт к оплате, а платный сценарий подготовлен к созданию заказа и редиректу после подключения реального провайдера. Сначала коротко сообщи, какие формы, сущности, маршруты и компоненты уже найдены и как ты свяжешь их с CRM. Затем реализуй систему целиком внутри существующей админки. Не ограничивайся визуальным макетом и не переделывай уже работающие разделы без необходимости.
После отправки задачи Ботану потребуется время на изменение проекта. Пока он работает, не нужно параллельно давать ему противоречащие команды. Лучше открыть подключение платежей в соседней вкладке и вернуться к CRM, когда сборка завершится.
Как проверить готовую CRM
Обновите страницу проекта и откройте административную часть сайта. В меню должен появиться раздел «Заявки». В верхней части полезно иметь краткую аналитику: общее количество обращений, новые заявки, заявки, требующие ответа, ожидающие оплаты и потенциальную сумму сделок.
Проверьте два представления — таблицу и канбан. Таблица удобна для поиска и сравнения полей, а канбан показывает движение заявок по статусам. Перетаскивание карточки между этапами должно менять статус записи, а фильтры — действительно сокращать список, а не только менять внешний вид кнопок.
Откройте карточку заявки. Внутри должны редактироваться основные данные клиента, статус и комментарий менеджера. Если платёжный провайдер пока не привязан к workspace, блок оплаты может быть неактивным — это ожидаемо. На этом этапе важно убедиться, что CRM хранит данные и позволяет работать с заявкой.
Подключаем платёжного провайдера
В Chatium может быть доступен внутренний платёжный провайдер для тестов. Платёж через него не равен обычному поступлению денег на расчётный счёт: в уроке он используется как тестовый механизм, где оплата конвертируется во внутренние токены. Для коммерческого сайта нужен реальный провайдер, который принимает деньги выбранными способами и перечисляет их вашему бизнесу.
Откройте в аккаунте раздел «Платежи», затем «Провайдеры» и нажмите «Добавить провайдера». В уроке выбран GetPlatinum, потому что сервис объединяет несколько платёжных возможностей, поддерживает работу с самозанятыми, рассрочки и встроенную онлайн-кассу. Это пример, а не обязательное требование: выбирайте провайдера по своему юридическому статусу, географии, комиссии и необходимым способам оплаты.
Добавление провайдера в аккаунт
Если аккаунта у провайдера ещё нет, сначала зарегистрируйтесь, заполните реквизиты и дождитесь активации. Затем вернитесь в Chatium и продолжите настройку. Для GetPlatinum в уроке нужны три параметра: API-ключ, ID терминала и название аккаунта. Они берутся в личном кабинете провайдера.
После сохранения новый провайдер появится в списке. Сделайте его провайдером по умолчанию, если именно через него должны проходить реальные платежи. Тестовый провайдер можно отключить или удалить, чтобы сотрудник случайно не создал через него рабочую ссылку и не принял токены вместо денег.
В настройках созданного провайдера скопируйте его внутренний ID. Не путайте его с ID терминала: терминал нужен при подключении внешнего сервиса, а внутренний ID провайдера нужен Ботану, чтобы привязать уже настроенный способ оплаты к конкретному workspace.
Привязка провайдера к workspace
Сам факт добавления провайдера в аккаунт ещё не меняет логику сайта. Теперь нужно вернуться к Ботану и описать, где и когда система должна создавать платёж. Именно на этом шаге мы разделяем два бизнес-сценария: заявка на консультацию и заказ продукта с фиксированной ценой.
Подключи к сайту и CRM платёжного провайдера с внутренним ID PROVIDER_ID. Нужны два сценария. Если клиент оставляет заявку на консультацию или услугу, платёж автоматически не создавай: заявка должна попасть в CRM, а менеджер должен иметь возможность указать сумму и создать ссылку на оплату из карточки. Если клиент оформляет курс или другой продукт с фиксированной ценой, создай заказ, сохрани его в CRM и сразу сформируй платёжную ссылку с суммой продукта, после чего переведи клиента на страницу оплаты. Сохраняй в заявке статус платежа и ссылку. Не храни API-ключи в клиентском коде. После реализации проверь оба сценария и сообщи, какие формы к какому сценарию подключены.
Вместо PROVIDER_ID вставьте внутренний ID провайдера из Chatium. Сам идентификатор не публикуйте и не передавайте клиентам. После отправки промпта дождитесь завершения сборки, обновите административную страницу и только затем переходите к тестированию.
Настраиваем два сценария оплаты
Одна из главных мыслей урока — не каждая заявка должна немедленно превращаться в платёж. Если человек интересуется дорогой или составной услугой, прямой переход на оплату может ухудшить конверсию: клиенту сначала нужно задать вопросы, уточнить объём работ и получить подтверждение условий. Поэтому консультация создаёт обычную заявку без автоматической платёжной ссылки.
Для курса или другого продукта с заранее определённой ценой логика обратная. Пользователь уже выбрал конкретное предложение, заполнил данные и готов платить. В этом случае лишнее ожидание менеджера только добавляет трение, поэтому платёжная страница создаётся автоматически.
Ссылка на оплату из карточки CRM
Оставьте на сайте тестовую заявку на консультацию или услугу. Используйте корректный формат телефона и электронной почты, потому что форма может валидировать поля. Затем обновите раздел «Заявки» и убедитесь, что новая запись появилась в CRM с правильным источником, услугой и суммой.
Откройте карточку заявки и найдите действие создания платежа. Менеджер должен иметь возможность проверить либо изменить сумму, добавить назначение платежа и сформировать ссылку. После создания ссылку можно скопировать и отправить клиенту или открыть в новой вкладке для проверки.
На платёжной странице должны совпасть сумма, описание заказа и доступные способы оплаты. Состав способов оплаты зависит от настроек провайдера: например, можно включить оплату картой, СБП или рассрочку. Не проводите реальный платёж при первичной проверке, если для этого нет отдельного тестового режима и заранее согласованного сценария возврата.
Автоматическая оплата курса
Теперь откройте форму заказа курса. Заполните её отдельными тестовыми данными и отправьте. В отличие от консультации, этот сценарий должен сразу создать заказ и перевести пользователя на платёжную страницу без участия менеджера.
Проверьте сумму на форме и на странице оплаты. Они должны совпадать. Затем откройте CRM и убедитесь, что заказ также появился в списке, а его статус отражает ожидание оплаты. Автоматический редирект не должен лишать команду данных о клиенте: запись в CRM создаётся до перехода на оплату.
Так мы получаем управляемую развилку. Заявки, которым нужен разговор, остаются у менеджера, а стандартные продукты продаются автоматически. Эту логику позже можно расширять: разные продукты могут вести к разным провайдерам, сценариям рассрочки или страницам после оплаты.
Подключаем Telegram-уведомления
CRM уже собирает заявки, но менеджер может не держать её открытой весь день. Telegram решает задачу скорости реакции: новое обращение или успешная оплата появляются в привычном мессенджере. При этом полная история и изменение статусов всё равно должны оставаться в CRM.
Создание бота и транспорта
Откройте в Telegram официального @BotFather, выполните команду /newbot, задайте отображаемое имя и уникальный username. BotFather выдаст токен. Считайте его паролем от бота: не размещайте токен в переписке с клиентами, на скриншотах и в публичных документах. Если токен случайно раскрыт, его нужно отозвать через BotFather и выпустить новый.
В Chatium откройте раздел ботов, перейдите в настройки транспортов, нажмите плюс и выберите Telegram. Вставьте токен, проверьте ключ и подтвердите использование найденного бота. После успешной проверки транспорт появится в списке.
Транспорт — это подключённый внешний канал, через который Chatium может принимать и отправлять сообщения. Тем же принципом могут подключаться другие мессенджеры, но в этом уроке используем Telegram.
Запуск диалога и привязка уведомлений
Откройте созданного бота в Telegram и нажмите «Начать». Без первого сообщения у бота ещё нет диалога, в который можно отправлять уведомления. После старта переписка появится в разделе «Чаты» Chatium.
Откройте этот диалог в Chatium и скопируйте ссылку на цепочку из адресной строки. Затем вернитесь в workspace и попросите Ботана направлять сообщения о заказах и оплатах именно в эту цепочку.
Подключи отправку уведомлений о новых заявках и успешных оплатах в цепочку Chatium: CHAIN_URL. Для новой заявки отправляй источник, имя клиента, телефон, email, продукт или услугу, сумму и комментарий. Для успешной оплаты отправляй имя клиента, продукт, сумму и идентификатор заказа. Уведомление должно отправляться для каждой формы сайта независимо от платёжного сценария, но не должно создавать дубли. Существующую логику CRM и оплаты не меняй. После реализации отправь одно тестовое уведомление и проверь доставку в указанную цепочку.
Вместо CHAIN_URL вставьте ссылку на созданный диалог. Ссылка является технической настройкой проекта, поэтому её также не стоит публиковать. После завершения сборки канал настраивать заново не потребуется: новые события будут автоматически уходить в выбранную цепочку.
Проводим сквозной тест
Финальная проверка должна пройти тем же путём, которым воспользуется реальный клиент. Откройте сайт в обычном пользовательском режиме, выберите форму и создайте новую тестовую заявку. Не используйте данные реального клиента: заведите отдельные тестовые контакты, которые легко отличить и удалить после проверки.
Сначала убедитесь, что сайт показал корректное подтверждение или открыл ожидаемую платёжную страницу. Затем проверьте CRM: заявка должна появиться один раз, получить правильный источник, продукт, сумму и начальный статус. После этого откройте Telegram — там должно быть уведомление с данными, достаточными для быстрой реакции менеджера.
Проверять систему лучше по короткому чек-листу:
- Форма отправляется без ошибки и не создаёт дублей.
- В CRM сохраняются имя, контакты, источник, продукт, сумма и комментарий.
- Для консультации платёж не создаётся автоматически.
- Менеджер может сформировать ссылку из карточки заявки.
- Для курса с фиксированной ценой платёж создаётся автоматически.
- Сумма на сайте, в CRM и на платёжной странице совпадает.
- Уведомление приходит в нужный Telegram-диалог.
- После успешного платежа система способна отправить отдельное уведомление и обновить статус заказа.
Если что-то не работает
Если заявка не появилась в CRM, сначала обновите страницу админки и проверьте, что смотрите тот же workspace, который изменял Ботан. Затем повторите отправку формы и посмотрите, было ли на сайте подтверждение. Если форма показывает ошибку валидации, проблема ещё не дошла до CRM: исправьте формат обязательных полей.
Если ссылка на оплату не создаётся, проверьте четыре уровня: провайдер добавлен в аккаунт; нужный провайдер выбран по умолчанию; в промпте указан правильный внутренний ID; сценарий формы соответствует описанной логике. Для консультации отсутствие автоматического платежа является нормальным результатом, а не ошибкой.
Если Telegram молчит, убедитесь, что бот действительно создан через официальный BotFather, токен прошёл проверку в Chatium, транспорт активен, пользователь нажал «Начать», а Ботану передана ссылка именно на нужную цепочку. После изменения настроек создайте новую заявку: старые события обычно не отправляются повторно.
Не исправляйте всё сразу одним длинным сообщением. Сначала локализуйте участок цепочки: форма, CRM, оплата или уведомление. Затем дайте Ботану узкую задачу с наблюдаемым симптомом и ожидаемым результатом. Так он с меньшей вероятностью затронет уже работающие части проекта.
Практическое задание
Повторите настройку на своём проекте и проведите минимум два сценария: консультацию без автоматической оплаты и заказ продукта с автоматическим переходом к платежу. Для каждого сценария сохраните результат в CRM и проверьте уведомление в Telegram.
После теста удалите или пометьте тестовые заявки, отзовите случайно раскрытые ключи и зафиксируйте для команды, какой провайдер используется по умолчанию. Система готова к работе только тогда, когда менеджер понимает не только куда нажимать, но и почему разные формы ведут себя по-разному.
В отдельных материалах мы подробнее разберём устройство CRM, подключение онлайн-оплаты и настройку Telegram-бота. Эта статья остаётся общей сквозной инструкцией: по ней можно собрать весь путь клиента от формы на сайте до заявки, оплаты и уведомления.
Автор материалаАндрей Власенко