InSales оставляют для стандартных продаж, а свой код выбирают под правила, которые не закрывают приложения

Стандартная продажа уже описана в инструментах платформы. Каталог приложений InSales на 8 октября 2026 года включает оплату, доставку и обмен со складской системой. Перед заказом разработки нужно пройти свой заказ в подходящем приложении.

Наличие нужного названия в каталоге ещё не означает совпадения правил. Важен путь покупателя: какую цену он видит, когда магазин подтверждает заказ и что происходит после отказа. Этот путь и предъявляют поставщику приложения.

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

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

Приложение из каталога и приложение на заказ отличаются тем, кто меняет правила. В готовом продукте магазин выбирает доступные настройки; в своём коде инженер реализует конкретное условие. Саму платформу при этом можно сохранить.

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

Момент применения правила важнее наличия API. В документации InSales есть операции чтения и изменения заказов, а вебхуки уведомляют о событиях. Это позволяет исследовать собственную логику рядом с платформой.

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

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

Агенты для кода помогают реализовать условие, но условие должен определить владелец процесса. «Сделать как у нас принято» не объясняет, кто разрешает замену и что делать после отказа. Постановка задачи агенту начинается с наблюдаемого результата.

Наш опыт здесь относится к продаже курса на vibecoding.ru. Инженер ведёт машину ИИ-агентов; открытая история работы машины показывает изменения проекта. Это пример разработки и проверки своих правил оплаты, а не опыт магазина на InSales.

Для магазина из этого примера полезен порядок проверки. Успешный платёж подтверждает только один путь покупателя. Отказ, повтор события и временная ошибка требуют отдельных ожидаемых результатов.

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

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

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

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

Правило учебного заказа: передавать на отправку только при согласии на замену. Перечень доступных полей и точек подключения инженер дописывает после проверки InSales.

Правила для ИИ-агентов помогают удерживать порядок работы с проектом. Они не заменяют правила продажи: у агента есть инструкция по разработке, а у заказа есть условие, которое обязана выполнить программа.

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

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

Следующим шагом можно обсудить сценарий магазина: принести пример заказа, готовое приложение и результат, которого не хватает. По ним проще определить объём разработки.

Тариф InSales оплачивает доступ к платформе, а разработка оплачивает изменение вашего сценария. Сравнение этих двух сумм не отвечает на вопрос окупаемости. Если готовое приложение закрывает задачу, разработка не становится выгодной от того, что код пишут агенты.

В линейке «Комбо» есть разные цены при помесячной и годовой оплате. На 8 октября 2026 года «Базовый» стоит 6 600 ₽ при оплате за месяц; 5 610 ₽ в месяц указаны при оплате за год. Опции и приложения учитывают отдельно.

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

На /services тариф «Один проект» стоит 250 000 ₽ в месяц, проверено 8 октября 2026 года. Инженер ведёт машину агентов, выполняет по одной задаче из очереди, а изменения идут в репозиторий клиента. Подписку можно поставить на паузу в любой месяц.

Для растущего магазина предметом такой работы может стать развитие недостающих сценариев продаж своим кодом. Сначала проверяют возможность реализации конкретного правила в InSales. Цена подписки не гарантирует совместимость любого требования с платформой.

Разработка по подписке подходит для очереди таких изменений. Разовая настройка доставки или подключения готовой оплаты требует меньшего объёма работ и сама по себе не оправдывает ежемесячную разработку.

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

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

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

1. Сначала прогоните свой заказ в настройках и готовом приложении.

2. Не подтвердился сценарий — опишите недостающее правило и момент его применения.

3. Проверьте возможность своего приложения рядом с InSales до решения о переезде.

4. Принимайте правило на успехе, отказе, повторе и ошибке; забирайте код и описание.

5. Назначьте сопровождение и сверяйте автоматический сценарий с ручной работой сотрудников.