Платный пакет внедрения: сколько брать за настройку

Почему эта работа исчезает внутри цены продукта

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

Именно так маржа начинает утекать.

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

Отдел продаж часто делает хуже не специально. Чтобы закрыть сделку, кто-то говорит: «Мы с этим поможем» или «Импорт мы возьмём на себя». Клиент слышит обещание. Финансы записывают это как выручку от продукта. А команда внедрения получает неоплаченную сервисную работу.

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

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

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

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

Что должно входить в пакет

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

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

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

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

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

Лучше всего обучение работает, если разделить его на два блока. Обучение администратора — для человека, который будет владеть системой после запуска. Ему нужно понимать настройки, права доступа, импорты и что проверять, если что-то выглядит не так. Обучение пользователей должно быть короче и быть сосредоточено на повседневных задачах, чтобы вся команда могла спокойно начать работу.

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

Что лучше не включать

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

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

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

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

Редизайн процессов требует особой осторожности. Если клиент говорит: «Пока мы настраиваем систему, можете ещё перестроить, как продажи, операционный отдел и финансы передают друг другу работу?», сначала остановитесь и проведите отдельное обсуждение объёма. За таким запросом обычно скрываются политика, исключения и решения, которые ещё никто не принял. В стандартный пакет это не помещается.

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

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

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

Как пошагово определить объём

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

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

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

Несколько ограничений помогают держать объём честным. «Обучение включено» — это слишком размыто. «Две сессии по 60 минут для группы до восьми пользователей» — уже понятно. «Импорт включён» тоже создаёт проблемы. «Импорт до 10 000 строк из одного чистого CSV» защищает ваше время.

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

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

Например, если Олег помогает небольшой компании выстроить AI-поддерживаемый процесс разработки, пакет может включать один вводный звонок, настройку доступа к репозиторию, две автоматизации, одну обучающую сессию и фиксированный объём миграционных работ. Если позже команде понадобятся ещё пять сценариев и дополнительные сессии проверки, это уже платные допуслуги.

Жёсткий объём сначала может казаться слишком строгим. Но он экономит споры, защищает маржу и делает предложение более надёжным.

Как назначить цену без гаданий

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

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

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

Если в среднем проект занимает 14 часов, а ваша минимальная ставка — $140 в час, ваша внутренняя целевая стоимость — $1,960. Добавьте запас 10–15% и округлите до аккуратной суммы. Котировка в $2,200 объясняется проще, чем страница с мелкими отдельными начислениями.

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

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

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

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

Реалистичный пример

Небольшая команда продаж из пяти человек покупает ваш продукт по годовому плану. Цена продукта даёт им доступ к инструменту, но перед началом работы им всё равно нужна помощь. Их клиентская база лежит в трёх таблицах с разными названиями столбцов, пустыми полями и дубликатами аккаунтов. Они хотят перенести всё это в свой CRM.

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

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

Можно сделать объём ещё точнее с помощью нескольких ограничений. Например, очистка покрывает до 5 000 строк, один импорт в один CRM и обучающие сессии продолжительностью до 60 минут каждая. Такие пределы выглядят небольшими, но они важны. Они не дают расплывчатым просьбам превращаться в работу, за которую никто не заплатил.

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

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

Ошибки, которые съедают маржу

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

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

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

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

Ещё одна утечка начинается, когда вы приступаете к работе до того, как клиент отправил финальные файлы. Если он присылает черновые данные, ваша команда их сопоставляет, тестирует и находит проблемы. Потом клиент отправляет обновлённую версию и просит «просто обновить». В итоге вы дважды делаете одну и ту же работу. Начинайте только тогда, когда клиент отправил финальные файлы, назначил одного согласующего и подтвердил, что исходные данные готовы.

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

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

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

Быстрая проверка перед отправкой сметы

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

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

Вам не нужен огромный процесс discovery. Нужна короткая проверка перед сметой. Составьте список всех исходных файлов, приложений, таблиц и ручных вводов, которые участвуют в настройке. Назначьте одного человека со стороны клиента, который отвечает за исходные данные, и одного, кто подтверждает очищенную версию. Посчитайте, сколько людей нужно обучить и какое именно обучение им требуется. Определите точку, в которой запуск считается завершённым. Установите почасовую или дневную ставку для всего, что выходит за рамки объёма.

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

Объём обучения может быстро изменить смету. Обучить двух администраторов за 90 минут — это совсем не то же самое, что обучить 25 сотрудников из продаж, поддержки и операционного отдела. Спросите, кому нужно обучение, что им нужно будет делать после этого и входит ли обучение новых сотрудников в пакет или это отдельная услуга.

Будьте строгими с точкой завершения. «Запуск» — это слишком расплывчато. Лучше сформулировать правило запуска так, чтобы оно было конкретным, проверяемым и понятным для обеих сторон.

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

Что делать дальше, чтобы пакет оставался прибыльным

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

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

Как только увидите закономерность, превратите её в один стандартный пакет с чёткими ограничениями. Затем создайте допуслуги для того, что отличается от клиента к клиенту. Так базовое предложение будет легко продавать, а необычные запросы перестанут съедать маржу.

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

Если в вашей работе есть AI-инструменты, внутренняя автоматизация или технический онбординг, правило остаётся тем же. Олег на oleg.is делает такую работу по определению объёма в качестве Fractional CTO и в стартап-консалтинге, где настройка легко может вырасти далеко за рамки исходной сделки, если заранее не поставить ограничения.

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