amoCRM теряла строки заказа. Мы заменили 47 узлов n8n одним экраном

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

Как это выглядело до переделки

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

Считал сумму не компьютер администратора, а внешний сценарий в n8n. На каждое сохранение он забирал карточку, пересчитывал ее и раскладывал результат обратно по полям сделки: "ТЗ 1" ... "ТЗ 20", "Мастер 1" ... "Мастер 20". Всего больше 140 полей. Остаток к оплате администратор все равно часто пересчитывал вручную, на калькуляторе.

Работало это так, как работает любая длинная цепочка через сеть. Вот как это описала сама администратор на видео, которое прислала перед проектом:

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

Администратор ателье, из видео перед началом проекта

Три симптома, у которых одна причина

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

Пропадают строки. Сценарий различал работы по названию. Две одинаковые работы в разных изделиях он считал одной и вторую стирал. Например, "Укоротить низ строчкой" для двух пар брюк. Ателье обходило это копированием и переименованием позиций.

Слетают суммы. Если обмен прервался, например из-за разрыва связи, следующий пересчет не запускался. Сотрудник видел старую сумму без надбавки и не понимал, какая из цифр в карточке правильная.

Это не три разные ошибки. Это одна причина: деньги, хранение заказа, документы и отправки шли одной цепочкой через сеть, а в роли базы данных работала карточка сделки.

47 узлов, 20 из них с кодом

Сначала мы разобрали старое решение целиком: экспорты сценариев, таблицы, старые квитанции. Основной сценарий в n8n состоял из 47 узлов, в 20 из них был свой код. Отдельный зарплатный сценарий добавлял еще 11 узлов.

Само количество узлов не проблема. n8n для того и существует, чтобы связывать сервисы между собой. Проблема в другом: расчет денег, хранение заказа, подготовка квитанции и отправка в CRM шли одной цепочкой. Если в середине что-то менялось или внешний сервис не отвечал, надо было разбираться не только где ошибка, но и что успело сохраниться до нее. Визуально узлы стоят аккуратно. Разбираться, какой из них уже изменил сумму, а какой еще нет, очень удобно - если у вас свободный вечер и никаких других планов)

Почему точечная правка ломала бы соседнюю

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

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

Старый архив - источник правил, а не база для переноса

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

Работа осталась в карточке сделки

Мы не заставили сотрудников учить новую программу. Заказ по-прежнему открывается из карточки сделки в amoCRM. В узкой боковой панели видно главное: сохранено ли, сколько изделий и работ, стоимость, остаток к оплате, кнопка "Открыть заказ" и быстрая доплата. Полный заказ открывается в широком окне, где хватает места для длинных описаний, прайса и оплат.

Первое изделие в новом заказе открыто сразу: одно изделие есть всегда. Кнопка "Добавить изделие" стоит после последнего изделия, там, где ее ищет рука. Время выдачи по умолчанию 15:00, как принято в ателье.

Поиск по прайсу так, как пишут сотрудники

В прайсе 297 услуг. Листать такой список при клиенте бессмысленно. Сотрудники привыкли писать коротко: "пальто укорот низ", "вспушка", часть слова или цену, которую помнят. Поиск работает именно так: по кусочкам слов в любом порядке, по всему прайсу сразу, по разделам ("Платья", потом обычные, вечерние или свадебные), по артикулу и по точной цене.

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

11 спорных позиций из прайса мы намеренно скрыли до уточнения, а не угадали за заказчика. Иногда лучшая автоматизация - это честная строка "нужно уточнить".

Скидки, надбавки и доплаты в своих полях

Квадратные скобки в названиях и нолики в пустых полях ушли. "Скидки и наценки" открываются отдельным окном с выбором: скидка, сложность или срочность. Дальше указывается процент и к чему его применить: к работе, изделию или всему заказу. Доплата в рублях добавляется к одной работе прямо из боковой панели, без перехода в полный редактор.

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

Клиент видит то, о чем договорились

У ателье бывают работы, которых нет в прайсе. Например, зашить нестандартный мешочек. Администратор подбирает для расчета похожие позиции по сложности и времени. Если напечатать их названия в квитанции, клиент резонно спросит, почему ему продали не то, что он принес.

Поэтому описание для клиента и расчетные строки разделены. В квитанции печатается текст администратора и итог по изделию: "Мешочек черный. Зашить разрыв, укрепить шов. Останется след". Внутренние позиции остаются в заказе, участвуют в цене и в начислении мастеру, но клиент их не видит. Для частого предупреждения есть сокращение: две звездочки в описании превращаются в "Останется след".

Для ателье квитанция - не формальность. Администратор на видео сказала прямо: если будет спорная ситуация с клиентом или дойдет до суда, квитанция должна показать, о чем договорились и сколько заплачено.

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

Оплаты и возвраты - отдельными операциями

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

Депозит клиента система не ведет как кошелек: списание фиксируется текстом, как договорились с заказчиком. Это осознанная граница, а не забытая кнопка.

Выданная квитанция не меняется

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

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

Зарплата мастера, которую можно объяснить

Раньше мастер получал сумму "по заказу" и пересчитывал ее сам по старому прайсу. А администратор, по ее словам, должна заниматься не математикой, а заказами, и мастера тоже.

Теперь у каждого мастера в заказе своя кнопка с расчетом: работа, количество, надбавка или скидка, база по прайсу мастеров с учетом количества, скидок и надбавок и сумма к начислению. Например, база 1 782 руб., к начислению 535 руб. Если цифра спорная, разговор начинается с конкретной работы, а не с фразы "компьютер так посчитал".

Месячный отчет скачивается в Excel за выбранный месяц: начисления по квитанциям, итог по каждому мастеру и общий итог. Текущий месяц можно поправить, например если сначала выбрали не того мастера. После закрытия месяц больше не переписывается, поздняя разница оформляется отдельной корректировкой. Дату сдачи заказа система берет из истории сделки в amoCRM, а не из текущего значения поля, поэтому заказ попадает в тот месяц, когда его действительно сдали.

Подбор уходит в Google-таблицу, как раньше

Ателье вело подбор материалов в Google-таблице, и это работало. Мы не стали переносить его внутрь CRM: подбор из заказа сам уходит в таблицу ателье, последние три колонки сотрудники заполняют вручную, как привыкли.

Если amoCRM не отвечает, заказ не теряется

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

n8n никуда не делся

Мы не объявили n8n плохим инструментом. Он нормально подходит для связок между сервисами. Мы убрали его только из того места, где начались деньги, версии документов и история изменений. Telegram-роботы ателье, которые пишут клиентам на этапах "Готово к выдаче" и "Сдано", продолжают работать как работали: новая система их не дублирует и не трогает.

Первая версия считала правильно, но ей не доверяли

Первый прототип был готов 11 сентября. Он правильно хранил изделия и работы, считал суммы и выпускал документы. Но на первой проверке квитанция заметно отличалась от привычного шаблона, один способ скачивания отдавал пустой файл, а длинный заказ пытался поместиться в узкую панель amoCRM, где поля зажимались и подписи переносились.

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

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

Правки по живой работе, обычно к следующему утру

Дальше ателье тестировало систему на своих сценариях и присылало замечания: скриншотами, видео, голосовыми. Большинство правок были сделаны к следующему утру. Вот что добавилось за две недели тестов:

• квитанция с нулевой стоимостью для заказов на консультацию;
• химчистка в общем поиске, без скидки и без начисления мастеру;
• окно "Скидки и наценки" с выбором скидка, сложность или срочность;
• квитанция только с подбором материалов, без работ из прайса;
• список источников клиента: постоянный клиент, сарафанное радио, соцсети, карты;
• в расчете мастера база по прайсу мастеров рядом с суммой к начислению.

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

Где мы отказались от лишней гибкости

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

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

Перенос в рабочую amoCRM

С 14 октября систему переносили из тестовой amoCRM в рабочую. Попутно выяснилось, что сервер старой схемы был оформлен на прежнего исполнителя. Мы подняли новый сервер, зарегистрированный на ателье, и сервисный адрес на домене ателье. Теперь CRM, сервер и домен принадлежат заказчику, а не подрядчику.

Результаты

Цифр вроде "оформление стало быстрее на столько-то процентов" здесь нет, и это честно: до запуска никто не засекал время оформления в старой схеме, а после запуска прошло слишком мало дней. Есть другое: система работает в ателье с 21 октября 2026 года, жалоб и правок после запуска не было.

Сколько времени это заняло

Около семи недель от первого письма до запуска.

Что не получилось с первого раза

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

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

Что происходит сейчас

Система работает в рабочей amoCRM ателье с 21 октября 2026 года. Старые заказы закрываются в прежней схеме, новые оформляются в новой. Замечаний после запуска не было.

Что можно перенести в другие CRM

1. Начинайте со списка документов, а не с экрана. Если из одного заказа рождаются квитанция, задание исполнителю и зарплатный отчет, это разные представления одних данных.
2. Не используйте название как идентификатор строки. Повторяющиеся работы, разные изделия и разные исполнители быстро это сломают.
3. Деньги считаются в одном месте. Экран, документ и отчет не должны каждый считать скидку по-своему.
4. Выданный документ храните как файл. Не обещайте себе собрать его потом из текущих данных.
5. Сначала сохраните, потом отправляйте. Сбой CRM, таблицы или почты не должен откатывать уже принятый заказ.
6. Клиенту - его формулировку, расчету - свои позиции. Ручное описание плюс итог честнее списка технических строк.
7. Проверяйте на живом процессе. Макет не покажет, что сотрудник добавляет четыре работы подряд и не хочет каждый раз заново открывать поиск.
8. Не трогайте рабочую CRM без карты полей и роботов. Правильная новая автоматизация может сломать правильную старую.
9. Проверьте, на ком оформлены сервер и домен. Если на подрядчике, процесс заказчика зависит от чужого аккаунта.

Частые вопросы