За неделю можно собрать прототип, а не работающую систему. Это не придирка к словам: прототип и система в эксплуатации отличаются не объёмом, а составом работ. У прототипа нет обработки исключений, прав доступа, тестового контура, приёмки на реальных данных и обучения людей — и именно эти работы съедают половину бюджета любого внедрения.

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

Ниже — что помещается в неделю, что не помещается и почему, реальные вилки сроков по типам задач, механика удорожания после быстрого старта в деньгах, четыре условия, при которых неделя честна, и один вопрос, снимающий спор за минуту. Мы сами подрядчик и тоже продаём сроки, поэтому сразу оговорка: наши этапы и их длительность выложены на странице как мы работаем — там прототип занимает 1–3 недели, внедрение 2–8 недель, и мы считаем правильным, чтобы вы требовали такой же разбивки от любого исполнителя, включая нас.

Что действительно помещается в неделю

Что это значитПрототип

Проверка одной гипотезы на ваших данных: распознаёт ли система ваши документы, понимает ли робот ваших клиентов, сходится ли точность на реальной выборке. Прототип отвечает на вопрос «получится ли», а не «работает ли в бою». В нормальной схеме он и нужен именно для этого: после него стоит точка выхода, где проект можно остановить, потеряв 20–30 % бюджета вместо ста.

  • Демонстрационный прототип на одном сценарии. Один путь заявки от начала до конца, на подготовленных данных, без исключений. Полезен: показывает, что подход рабочий.
  • Связка двух систем через готовый коннектор. Если у обеих сторон есть штатная интеграция и справочники уже сопоставлены, обмен настраивается за несколько дней.
  • Настройка типовой коробки под существующий процесс. Воронки, поля, шаблоны документов, автозадачи, права. Это настройка, а не разработка, и неделя здесь — нормальный срок.
  • Один автоматический сценарий поверх готовой платформы. Уведомление о новой заявке, передача лида в мессенджер, автоответ по шаблону — задача на несколько часов работы плюс проверка.
сравнениеsdelaem-za-nedelyu-krasnyy-flag--01
Сравнение прототипа за неделю и системы в промышленной эксплуатации

Сравнение в две колонки по шести строкам. Колонка «Прототип, 1 неделя»: один сценарий, подготовленные данные, исключения не обрабатываются, доступ у одного человека, тестового контура нет, проверка показом. Колонка «Система в эксплуатации»: все сценарии процесса, боевые данные, очередь и повторные попытки при отказе смежной системы, роли и права доступа, отдельный тестовый контур, приёмка по согласованному критерию. Внизу подпись: «в неделю помещается только левая колонка; правая — минимум 19 рабочих дней сверх разработки». Чертёжный стиль, подписи по-русски.

Два разных продукта, которые в разговоре называют одним словом

Что не помещается физически

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

РаботаМинимум рабочих днейЧто будет, если пропустить
Обследование процесса и описание исключений3Система проектируется по устному рассказу; расхождение вскроется на приёмке
Тестовый контур: копия учётной системы и данные2Проверять придётся на живой базе, первая ошибка обмена испортит реальные документы
Обработка исключений: повторы, очередь, журнал, эскалация5При первом отказе смежной системы данные теряются молча
Роли и права доступа3Система запускается с общим доступом; позже выясняется, кто что видел
Приёмочные испытания на реальных случаях3Приёмка превращается в демонстрацию, а демонстрация проходит всегда
Обучение сотрудников и инструкции3Люди продолжают работать по-старому и заполняют систему задним числом

Сумма нижних границ — 19 рабочих дней, почти четыре календарные недели, и это ещё до самой разработки. Отсюда простое следствие: когда объявленный срок меньше суммы обязательных работ, разница не исчезает, а переезжает. Либо в раздел «доработки» с отдельным счётом, либо на ваших сотрудников, которые будут доделывать это руками и без оплаты.

Порядок, в котором пропущенные работы предъявляют себя, устойчив и его можно предсказать заранее. Первым всплывает тестовый контур — в тот день, когда впервые надо прогнать обмен, и решение «проверим на живой базе» принимается второпях. Вторыми приходят исключения: они появляются не в первый день эксплуатации, а на второй-третьей неделе, когда через систему проходит достаточно случаев, чтобы встретился нетипичный. Права доступа и журнал вскрываются последними и переделываются на работающей системе, то есть дороже всего. Обучение и документация не вскрываются никогда — их просто не делают, и это выясняется через год при первой попытке передать решение другой команде.

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

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

Тип задачиРеальный срокОриентир цены
Настройка типовой коробки под процесс1–2 неделиот 30 000 ₽ разово
Связка двух систем через готовый коннектор1–3 недели60 000–150 000 ₽
Базовый агент с поиском по базе знаний3–8 недель150 000–200 000 ₽
Заказной ИИ-агент под процесс6–12 недель250 000–500 000 ₽ плюс 20 000–30 000 ₽/мес
Комплексная автоматизация процессов3–5 месяцевот 1 500 000 ₽

Из таблицы видно, где именно ломается недельное обещание. Первые две строки — это настройка и связка, там неделя реалистична. Начиная с третьей строки в работу входит то, чего в коробке нет: правила, исключения, обмен со справочниками, проверка качества ответов на вашей выборке. Поэтому фраза «сделаем чат-бота за неделю» и фраза «сделаем настройку за неделю» звучат одинаково, но описывают задачи с шестикратной разницей в объёме. Уточняющий вопрос здесь ровно один: это настройка готового продукта или разработка под процесс — и если разработка, то какие исключения уже учтены в оценке.

Полгода после быстрого старта, в деньгах

Модельный случай: приём заявок из мессенджера с передачей в учётную систему, поток около 700 обращений в месяц. Подрядчик обещал неделю и 120 000 ₽ и сдал прототип в срок. Дальше — то, что произошло за следующие пять месяцев.

Старт за неделю: во что он обошёлся за шесть месяцев
Прототип на одном сценарии, 1 неделя120 000 ₽
Месяц 2: обработка исключений и повторные попытки, допсоглашение90 000 ₽
Месяц 3: обмен с учётной системой, «в объёме не было»180 000 ₽
Месяц 4: роли, права доступа и журнал операций60 000 ₽
Месяц 5: приёмка на реальных данных и обучение сотрудников70 000 ₽
Поддержка, 5 месяцев × 20 000 ₽100 000 ₽
Итого620 000 ₽ за шесть месяцев вместо объявленных 120 000 ₽. Всё это время старый процесс работал параллельно, то есть экономии не было ни одного дня
графикsdelaem-za-nedelyu-krasnyy-flag--02
Рост расходов со 120 тысяч до 620 тысяч рублей за шесть месяцев после быстрого старта

Ступенчатая диаграмма роста слева направо по месяцам. Стартовая площадка «Прототип, 1 неделя — 120 000 ₽». Ступени: «месяц 2, обработка исключений +90 000 ₽», «месяц 3, обмен с учётной системой +180 000 ₽», «месяц 4, права доступа +60 000 ₽», «месяц 5, приёмка и обучение +70 000 ₽», «поддержка 5 мес × 20 000 ₽ = +100 000 ₽». Верхняя площадка подписана «итого 620 000 ₽ за 6 месяцев». Под осью подпись «старый процесс работает параллельно всё это время». Единицы — рубли, подписи по-русски.

Ни одна из доплат не была обманом — каждая закрывала работу, которой не было в объёме

Обратите внимание: ни одна доплата не была недобросовестной. Каждая закрывала настоящую работу, которой действительно не было в согласованном объёме. Проблема возникла раньше — в момент, когда объём не выписали целиком. Именно поэтому список допущений и раздел «не входит в работу» важнее итоговой цифры; как читать смету на полноту, разобрано отдельно в материале про чтение сметы на автоматизацию.

Когда неделя — честный срок

Четыре условия должны выполняться одновременно. Достаточно одного невыполненного, чтобы срок поехал.

  1. 1Задача сводится к одному сценарию. Не «автоматизировать продажи», а «при поступлении заявки с сайта создавать сделку и уведомлять ответственного». Один вход, один выход, понятная граница.
  2. 2Процесс уже описан. Есть регламент или хотя бы карточка процесса: кто участвует, сколько операций в месяц, что считается исключением. Если описания нет, обследование занимает 3–7 дней само по себе — и это уже больше недели.
  3. 3Интеграция идёт через готовый коннектор. Обе системы имеют штатную связку, справочники сопоставимы, ничего не надо писать с нуля. Как только появляется обмен через промежуточный слой, срок уходит за две недели минимум.
  4. 4Поток операций небольшой. До нескольких сотен событий в месяц исключения можно первое время разбирать руками. На тысячах событий обработка ошибок становится обязательной, а это отдельные пять рабочих дней.

Один вопрос, снимающий спор за минуту

Спор о сроке бесполезен: обе стороны говорят о разных вещах. Вместо него задайте один вопрос — что именно будет работать в продуктиве на восьмой день и что будет считаться отказом системы. Ответ показывает, о чём вообще шла речь.

Два типа ответа

Инженер отвечает границами: «на восьмой день заявки с сайта создают сделку в CRM и уведомление уходит ответственному; отказом считается потеря заявки или задержка уведомления больше 5 минут; исключения первый месяц разбираются вручную». Такой ответ можно записать в критерии приёмки. Продавец отвечает объёмом: «всё будет работать». Это не ответ, а обещание, и на приёмке его нельзя ни подтвердить, ни опровергнуть. Тот же приём работает против нас — если мы не сможем назвать границы, требуйте их.

Когда подрядчик не нужен

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

  • Задача закрывается штатными настройками. Автозадачи, шаблоны документов, правила распределения и уведомления есть в коробочных CRM и типовых конфигурациях учётных систем. День в документации продукта или один платный час консультации партнёра вендора дешевле любой недели разработки.
  • Операций меньше порога окупаемости. При 60–80 однотипных операциях в месяц любое внедрение не окупится за 24 месяца, потому что цена системы почти не зависит от объёма потока. Порог считается до запроса предложений — методика разобрана в материале про окупаемость автоматизации.
  • Процесс меняется каждый месяц. Быстрый старт на нестабильном процессе фиксирует в системе временное состояние. Сначала стабилизируйте правила, потом автоматизируйте — иначе первая же недельная сборка устареет до приёмки.
  • Нужна одноразовая операция. Разовая выгрузка, единичная сверка, перенос данных перед переездом — это работа на несколько часов, а не проект. Здесь дешевле почасовая помощь специалиста, чем внедрение с этапами и договором.

Итог, неудобный для нашей стороны рынка: скорость сама по себе ничего не стоит и покупать её отдельно бессмысленно. Значение имеет только то, сколько работ вошло в объявленный срок. Просите разбивку по этапам с результатом каждого — так делаем мы, и того же стоит требовать от любого исполнителя. Если разбивки нет, вы покупаете не неделю, а первую строку из списка, который вам не показали.

Срок — это не скорость исполнителя, а количество работ, которые он согласился в него положить.