Когда уместно готовое решение, а когда — кастомный AI-проект
Что важно понять
Не каждую задачу клиента нужно вести в готовое решение. Но и не каждую задачу нужно превращать в большой AI-проект.
В реальной работе ошибка бывает в обе стороны:
- кто-то пытается натянуть знакомую коробку почти на любой запрос;
- кто-то, наоборот, слишком рано уводит клиента в сложный проект, интеграции и долгую разработку.
Обе крайности мешают.
Поэтому в разговоре с клиентом важно сначала понять, что перед вами:
- достаточно типовая задача;
- нестандартный процесс;
- или ситуация где-то между ними.
От этого зависит, что будет честным следующим шагом: готовое решение, проект под клиента или более смешанный вариант.
Почему это важно
Когда сотрудник ошибается с форматом, начинаются проблемы.
Натянуть готовое решение на сложную задачу
Если натянуть готовое решение на сложную и нестандартную задачу:
- у клиента появятся лишние ожидания;
- команда потом начнёт «дотягивать» продукт до реальности проекта;
- растёт риск разочарования и внутри, и у клиента.
Слишком рано уводить в большой проект
Если же там, где можно было быстро зайти через понятный сценарий, сразу уводить разговор в большой проект:
- клиенту сложнее принять первый шаг;
- сделка может стать тяжелее и дольше;
- там, где можно было показать быстрый результат, всё усложняется раньше времени.
Зрелая позиция сотрудника — не упрощать и не усложнять без нужды.
Что считать готовым решением
Готовое решение — это не обязательно «коробка без единой настройки».
В контексте AI это скорее значит, что:
- у клиента понятная и довольно типовая задача;
- похожие сценарии уже встречались и уже решались;
- есть понятная логика пользы;
- можно довольно быстро объяснить, с чего начать.
Обычно к таким сценариям ближе задачи, связанные с:
- обработкой документов;
- поиском информации и базой знаний;
- поддержкой и повторяющимися вопросами;
- встречами и звонками;
- типовыми задачами в финансах, логистике и смежных функциях.
Это не значит, что решение будет одинаковым для всех. Но это значит, что путь входа для клиента может быть более продуктовым и предсказуемым.
Что считать кастомным AI-проектом
Кастомный проект — это история, где клиентскую задачу нельзя честно закрыть типовым сценарием без глубокой адаптации.
Обычно это видно, когда:
- процесс у клиента сильно нестандартный;
- участвует несколько систем;
- есть много ручной логики, исключений и внутренних правил;
- задача затрагивает интеграции, безопасность, контуры, архитектурные ограничения;
- типовое решение закрывает только маленькую часть реальной проблемы.
Здесь важно не пугаться слова «проект».
Если задача клиента действительно проектная, не нужно делать вид, что её можно быстро и безболезненно решить коробкой. Гораздо честнее сразу говорить о более глубокой проработке, этапности и проектном формате.
Как понять, что задача ближе к готовому решению
Вот несколько признаков, что клиентская ситуация больше похожа на готовый или близкий к готовому сценарий.
Признак 1. Боль легко узнаётся
Вы слышите задачу и понимаете, что она уже знакома по типу:
- поиск по документам;
- ответы на повторяющиеся вопросы;
- расшифровка звонков и встреч;
- извлечение данных из документов;
- ускорение типовых операций.
Признак 2. Клиент описывает понятную точку эффекта
Например:
- «слишком долго ищем информацию»;
- «много времени тратим на ручной разбор документов»;
- «поддержка отвечает на одно и то же».
То есть проблема звучит довольно конкретно.
Признак 3. Не требуется радикально перестраивать процесс
Клиенту не нужно заново изобретать весь ландшафт. Ему нужен понятный рабочий сценарий, который можно встроить в существующую работу.
Признак 4. Можно быстро объяснить первый шаг
Если уже на базовом уровне понятно, как это может выглядеть на практике, это хороший сигнал, что сценарий ближе к готовому решению.
Как понять, что задача ближе к проекту
Теперь наоборот.
Признак 1. Процесс у клиента сильно уникальный
Не просто «у нас своя специфика», а реально сложная логика:
- несколько веток;
- исключения;
- ручные согласования;
- разные роли;
- много нюансов, которые нельзя обойти.
Признак 2. В задаче много интеграций
Если нужно связать несколько систем, источников данных, каналов или внутренних контуров, вероятность проектного формата растёт.
Признак 3. Есть серьёзные ограничения по безопасности и инфраструктуре
Например:
- закрытый контур;
- высокие требования к ИБ;
- локальное размещение;
- особые правила работы с данными.
Признак 4. Типовое решение закрывает только кусочек задачи
Это очень важный момент.
Бывает, что сотрудник видит знакомый элемент и радуется: «О, здесь у нас есть решение». Но если это решение закрывает 10–20 процентов реальной задачи, нельзя делать вид, что этого достаточно.
Важно: между коробкой и проектом есть промежуточные варианты
На практике не всё делится жёстко на два лагеря.
Иногда уместен смешанный путь:
- в основе берём понятный типовой сценарий;
- дальше дорабатываем его под контекст клиента;
- или сначала заходим через ограниченный сценарий, а потом расширяемся.
То есть сотруднику важно не мыслить в логике «или коробка, или огромный проект». Иногда правильный ответ звучит так:
«Основу можно взять из понятного решения, но дальше потребуется адаптация и более глубокая проработка».
Это зрелая и честная позиция.
Пример из практики
Ниже — три короткие ситуации.
Ситуация 1
Клиент говорит:
«У нас специалисты постоянно тратят время на поиск информации по инструкциям и внутренним документам».
Это похоже на типовую задачу. Боль понятна, сценарий узнаваемый, эффект можно довольно быстро объяснить. Здесь логично думать о готовом или близком к готовому решении.
Ситуация 2
Клиент говорит:
«У нас сложный внутренний процесс обработки заявок: несколько систем, нестандартные правила, разные роли, ручные проверки и много исключений».
Здесь уже видно, что ситуация тянет на проект. Если пытаться закрыть её как типовой сценарий, велик шанс создать неверные ожидания.
Ситуация 3
Клиент говорит:
«У нас есть похожая на типовую задача, но при этом много особенностей по безопасности, данным и внутреннему маршруту обработки».
Это пример промежуточной ситуации. Здесь не стоит обещать клиенту «чистую коробку», но и не обязательно сразу рисовать огромный проект. Корректнее говорить о типовом ядре плюс адаптация под контекст.
Как говорить об этом клиенту
Когда вы понимаете, что готовое решение не совсем подходит, важно не звучать так, будто вы усложняете жизнь или пытаетесь продать что-то подороже.
«Нет, коробка вам не подойдёт, у вас всё слишком сложно».
«Похоже, у вас задача шире, чем типовой сценарий. Здесь важно не натянуть готовое решение на процесс, а подобрать рабочий формат. Скорее всего, правильнее будет идти через проектную проработку или адаптацию под ваш контекст».
И наоборот, когда уместно готовое решение, не нужно искусственно усложнять:
«У вас довольно понятная и типовая задача. Здесь есть смысл сначала посмотреть на более быстрый и предсказуемый сценарий, а не заходить сразу в большой проект».
Простое рабочее правило
Если совсем коротко, задайте себе три вопроса:
- Эта задача типовая или сильно уникальная?
- Её можно честно закрыть понятным сценарием или без глубокой адаптации не обойтись?
- Мы сейчас упрощаем без оснований или, наоборот, усложняем раньше времени?
Если вы честно отвечаете на эти вопросы, вероятность ошибки становится ниже.
Инструмент урока
Мини-чек-лист: готовое решение или проект
Чаще уместно, если:
- боль типовая и узнаваемая;
- сценарий понятен;
- можно быстро объяснить пользу;
- не требуется глубокая перестройка процесса;
- следующий шаг выглядит довольно прозрачно.
Чаще уместен, если:
- процесс нестандартный;
- много интеграций и исключений;
- есть ограничения по инфраструктуре и безопасности;
- задача затрагивает несколько систем и ролей;
- типовое решение покрывает только часть реальной проблемы.
Уместен, если:
- ядро задачи типовое;
- но контекст клиента требует адаптации;
- есть смысл начать с понятного сценария и дальше доработать его по результатам.
✍️ Мини-практика
Прочитайте ситуации и определите, какой формат здесь выглядит более уместным: готовое решение, кастомный проект или готовое решение с адаптацией.
- Клиент хочет сократить время на обработку однотипных документов и быстро получить понятный первый эффект.
- Клиенту нужно автоматизировать уникальный внутренний процесс, который проходит через несколько систем и сильно зависит от внутренних правил.
- У клиента типовая задача по смыслу, но жёсткие требования по безопасности и сложный маршрут данных.
- Клиенту важно быстро запустить понятный сценарий без большой перестройки текущих процессов.
На что обратить внимание
Проверьте себя
Вопрос 1
Что чаще всего говорит в пользу готового решения?
Вопрос 2
Когда особенно честно сразу обсуждать проектный формат?
Вопрос 3
Что из этого является наиболее зрелой позицией сотрудника?
Итог урока
Не каждая клиентская задача — это коробка. Но и не каждая клиентская задача — это большой проект.
Сильная позиция сотрудника — видеть разницу между типовой и нестандартной задачей, не обещать лишнего и помогать клиенту выбрать реалистичный формат первого шага.