Обсудите сценарии, интеграции, путь данных, критерии приёмки и регулярные расходы. Сравнивайте предложения на одинаковой задаче, а не по названию «ИИ-ассистент».
Два предложения на разработку могут выглядеть одинаково: бот, ИИ, интеграция с CRM и поддержка. При этом один исполнитель предполагает готовые материалы и ручное согласование каждого ответа, а другой — самостоятельную работу с несколькими системами. Разница обнаруживается после начала проекта, если заранее не обсудить условия.
Вопросы подрядчику помогают сравнить не обещания, а конкретный объём работы и ответственность сторон. Для этого полезно принести несколько настоящих сценариев без лишних чувствительных сведений и попросить объяснить весь путь: от обращения до результата в вашей системе.
Как решение пройдёт конкретный сценарий?
Начните с обычной задачи. Например, в условной компании клиент выбирает услугу, отправляет описание и получает время для консультации. Попросите показать, какие шаги выполняет система, когда подключается сотрудник и где сохраняется результат. Перечень экранов или возможностей модели этого не объясняет.
Затем добавьте неудобные варианты: данных не хватает, клиент меняет решение, рабочая система не отвечает, диалог продолжается на следующий день. Уточните, какие из этих случаев входят в предложение, а какие оцениваются отдельно. Формулировка «поддерживает любые вопросы» не заменяет договорённости о поведении в исключениях.
Спросите, какие решения нужно принять вам до разработки: правила распределения, доступные услуги, подтверждение действий и условия передачи человеку. Исполнитель может помочь оформить выбор, но не должен скрыто придумывать бизнес-правила. Если подрядчик задаёт конкретные вопросы о процессе, это полезнее раннего обещания полного запуска без исходных данных.
Что именно будет связано с вашими системами?
Назовите используемые инструменты и попросите разделить чтение, создание и изменение данных. «Интеграция с CRM» может означать отправку контакта, а может — работу с историей, задачами и повторными обращениями. Для сравнения предложений нужен перечень событий и ожидаемых изменений, а не одно общее название.
Уточните, что уже проверено и что пока предполагается. Если исполнитель не видел вашу конфигурацию, права и доработки, окончательная оценка может зависеть от обследования. Попросите обозначить эту зависимость и результат первого этапа. Это помогает заранее понять, почему срок или стоимость могут уточниться.
Важен и вопрос повторов: что произойдёт, если событие придёт дважды или сохранение завершится, а подтверждение потеряется? Для заявки результатом должна быть согласованная карточка, а не несколько похожих записей. Спросите, как команда обнаружит сбой и кто восстановит обработку без потери обращения.
Какие данные нужны и куда они попадут?
Попросите назвать состав данных на каждом шаге: сообщение, документ, сведения CRM, результат обработки. Уточните, где они хранятся, кому доступны и как удаляются. Ответ «всё защищено» недостаточен для понимания устройства решения. Компания должна знать, какие сведения передаются внешним сервисам и зачем.
Для доступа подрядчика к вашим системам определите минимальные права и порядок отключения после работ. Уточните, какие учётные записи принадлежат компании и кто управляет ими. Общий пароль, известный нескольким людям, усложняет отзыв доступа и выяснение действий. Это стоит обсудить до подключения, а не после завершения проекта.
Если нужны образцы документов или диалогов, спросите, как передать их без лишних данных. Для начальной проверки иногда достаточно ограниченного набора с изменёнными персональными сведениями. Но такой образец должен сохранять сложности настоящей задачи, иначе демонстрация покажет качество только на упрощённом материале.
Как вы проверите качество и примете работу?
Попросите описать проверяемый результат для каждого важного сценария. Для помощника по заказам это правильное состояние из источника, для обработки документов — верные поля, для передачи в CRM — ожидаемая карточка. Гладкий ответ и успешная презентация сами по себе не подтверждают качество процесса.
Уточните, можно ли до полного запуска проверить решение на подготовленных вами случаях. Нужны обычные обращения, неоднозначные запросы и отказ источника. Критерии полезно согласовать заранее, включая ошибки, которые недопустимы, и случаи, передаваемые сотруднику. Не стоит требовать абстрактной безошибочности, не определив, что система должна делать при неопределённости.
Спросите, как сотрудник проверяет, исправляет и отменяет предложенный результат. Особенно это важно перед отправкой клиенту, сменой условий или изменением данных. Исполнитель должен объяснить не только успешное действие, но и восстановление после ошибки. Понятный контроль помогает оценить решение вместе с вашей командой.
Какие расходы зависят от использования?
Разделите стоимость разработки, подключений и регулярной работы. Попросите указать, какие услуги оплачиваются отдельно, какие расходы зависят от объёма сообщений или документов и кто следит за ними. Удобно сравнивать предложения на одной условной нагрузке, не принимая её за гарантированный будущий расход.
Также выясните, что входит в сопровождение: исправление дефекта, обновление материала, изменение сценария или поддержка новой интеграции. Эти работы различаются по причине и объёму. Если всё называется поддержкой без границ, спор может возникнуть при первом изменении процесса или условий внешней платформы.
Попросите перечислить зависимости от внешних сервисов и действия при их недоступности или изменении условий. Компания должна понимать, какие компоненты можно заменить и что для этого потребуется. Право использовать готовые части, доступность исходных материалов и условия передачи результатов следует обсуждать явно, не выводя их из общей суммы предложения.
Кто будет управлять решением после запуска?
Уточните, какие доступы, инструкции и материалы вы получите. Документация должна помогать выполнить реальные действия: обновить сведения, назначить ответственного, найти ошибку и обратиться за поддержкой. Список технологий не заменяет рабочего руководства для сотрудников компании.
В конце разговора попросите письменное описание согласованного объёма, допущений и открытых вопросов. Сравнивайте предложения по одинаковым сценариям, способу проверки и границам ответственности. Если разница в цене связана с исключённой интеграцией или иной проверкой, это должно быть видно до заказа, а не в ходе выполнения.
- Какой результат получает клиент и сотрудник в каждом сценарии?
- Что проверено в наших системах, а что требует обследования?
- Как обрабатываются ошибки и передаётся вопрос человеку?
- Какие расходы, доступы и обязанности остаются после запуска?
Материал подготовлен Legan Studio.
Обсудим задачу и состав разработки
Разберём ваши примеры, ограничения и критерии результата, чтобы предложение было понятным до начала работ.
Обсудить проект с Legan Studio