Запросы под конкретного клиента: когда внедрять, переводить в процесс или отказывать

Почему кастомные запросы быстро копятся

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

Один клиент хочет другой шаг согласования. Другой — специальный экспорт. Третий просит еще одно правило доступа. Каждый запрос по отдельности выглядит мелким, поэтому команда берет его в работу. Потом sales слышит: «А для нас так можно?» — и планка тихо сдвигается от «мы так не делаем» к «мы уже однажды это сделали».

Так и расползается кастомная работа. Каждое исключение делает следующее проще согласовать.

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

Простой B2B-пример хорошо показывает этот паттерн. Один клиент просит CSV-экспорт с дополнительными колонками. Engineering быстро это делает. Скоро другой клиент хочет тот же экспорт, но с другими названиями колонок, правилами по датам и ограничениями доступа. Support уже должен помнить, кому какой формат положен. QA получает больше сценариев для проверки. Позже одно изменение в отчетности ломает один экспорт, но не другие. На код можно потратить день. Владение этим решением может тянуться годами.

Скрытая стоимость обычно ложится в одни и те же места:

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

Большая часть вреда для roadmap приходит не от одной крупной ставки. Она приходит из кучи мелких исключений, которые постепенно становятся частью продукта.

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

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

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

В других случаях лучше выбрать отдельный workflow. Такой вариант подходит, когда важнее результат, а не точный путь. Например, одной группе нужен дополнительный review, согласования или проверка через ИИ, а большинству пользователей это не нужно. Тогда внутренний процесс, простая автоматизация или шаг в ops могут решить задачу без изменения ядра продукта для всех.

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

Несколько признаков сильно упрощают triage feature request. Самый важный — повторяющийся спрос. Если несколько клиентов просят об одном и том же в одном квартале, возможно, вы нашли настоящее продуктовое правило. Следом идет риск. Если плохой исход может раскрыть данные, сломать цифры или заблокировать выручку, лучше использовать контролируемый workflow или отказаться от запроса. Потом смотрите на нагрузку support. Если support уже нужен playbook, ручные исправления и еженедельные исключения, значит запрос уже стоит вам денег, еще до любой разработки.

Помогает простой тест: можете ли вы объяснить поведение обычными словами, и будет ли оно по-прежнему логичным через шесть месяцев? Если да — делайте правилом. Если нет — оставьте это в workflow или вообще не берите.

Используйте простой процесс сортировки

Большинство команд отвечает на запросы слишком рано. Кто-то важный просит об особом случае, sales чувствует давление, и команда начинает обсуждать разработку, еще до того как кто-то проверил, реальна ли проблема.

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

Сначала заставьте запрос уложиться в одно предложение. Если никто не может написать его ясно, никто не сможет построить решение аккуратно. «Acme нужны exports» — это расплывчато. «Acme нужен запланированный CSV-экспорт в S3 каждую неделю по понедельникам, потому что finance копирует данные вручную» — это уже конкретика, которую можно оценить.

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

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

Отдельной строкой держите edge cases. Небольшой запрос может расползтись гораздо дальше первого экрана, где он появился. Специальное правило согласования для одного аккаунта может затронуть еще и доступы, audit logs, биллинг и support scripts.

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

Такая заметка экономит время позже. Без нее одни и те же запросы под конкретного клиента возвращаются каждый квартал, и спор начинается заново.

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

Какие вопросы задать до изменения продукта

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

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

Поймет ли новый клиент поведение без длинного sales call? Хорошие изменения в продукте понятны сами по себе. Если каждый менеджер по продажам объясняет одну и ту же функцию по-разному, скорее всего, у вас нет чистого продуктового правила.

Может ли команда решить это вне продукта? Ручная проверка, внутренний playbook или легкий workflow часто решают задачу быстрее, чем код. Это особенно верно в компаниях, где активно используют ИИ: очень легко добавить еще один prompt, маршрут или automation и сказать, что проблема решена, хотя на деле команда просто создала еще больше скрытой логики.

Какой постоянный вес это добавит? Новые поля, условия, ветки доступа и исключения почти никогда не остаются маленькими. Они меняют onboarding, документацию для support, тестирование и будущие релизы.

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

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

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

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

Растущий B2B-продукт часто получает запросы, которые звучат безобидно. Клиент говорит: «Нам нужна особая цепочка согласований». Большинство сделок идут обычным путем, но сделки выше определенной суммы должны попадать в finance, а одному подразделению нужен review со стороны legal, прежде чем что-то сдвинется.

Вариант с продуктовым правилом выглядит заманчиво. Команда добавляет несколько условий, один тумблер для администратора и еще одно уведомление. Sales сохраняет довольного клиента, и тот продлевает контракт.

Проблемы начинаются позже. Другому клиенту нужен другой порог. Третий хочет поменять порядок согласований по регионам. Support теперь должен объяснять, почему один запрос обошел finance, почему другой застрял в legal и почему редактирование черновика перезапустило всю цепочку. То, что выглядело как одно правило, превращается в настройки, исключения, audit logs, тест-кейсы и долг поддержки.

Отдельный workflow часто оказывается лучшим средним вариантом. Оставьте основной процесс согласования внутри продукта, а редкие случаи решайте через custom workflow design вне основного пути. Заказ, который попадает под особый случай, может создать задачу для ops или отправить структурированное сообщение в очередь на review перед финальным approval.

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

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

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

Типичные ошибки, которые ломают roadmap

Обычно roadmap ломается не в один драматический момент. Он смещается постепенно.

Один особый случай делают для громкого клиента. Еще один прячут в prompt или маленький скрипт. Потом sales обещает третий еще до того, как product и ops вообще поговорили. Через несколько месяцев команда поддерживает работу, которой никогда не собиралась владеть.

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

Другая ошибка — считать code, сгенерированный ИИ, бесплатной работой. Его действительно быстрее создать, но он все равно требует review, тестов, мониторинга и поддержки. Команды говорят «да», потому что первая версия появляется за час. Реальная стоимость всплывает позже, когда код ломается после смены модели, обновления схемы или нового edge case.

Владение результатом тоже слишком часто исчезает после запуска. Engineering написал кастомный flow. Support знает, как его запустить. Sales помнит, зачем он существует. Но никто не владеет итогом. Когда клиент просит изменить решение, запрос превращается в поиски по следам.

Скрытая логика создает еще больше проблем. Команды держат специальные правила внутри prompts, крошечных скриптов или заметок support, потому что работа кажется временной. Но временная работа живет дольше, чем люди ожидают. Если запросы под конкретных клиентов лежат в пяти разных местах, никто не видит настоящих product roadmap decisions, которые принимает компания.

Слишком ранние обещания доставки — еще одна плохая привычка. Sales говорит «да», чтобы закрыть сделку. Product думает, что ops справится. Ops думает, что engineering все автоматизирует. Потом команда узнает, что каждую неделю нужны ручные проверки.

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

Сторонний operator может помочь, когда команда снова и снова ходит по одному и тому же кругу. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как fractional CTO, и именно в таких решениях внешний взгляд особенно полезен. Задача не в том, чтобы одобрять больше функций. Задача — четко решить, что должно попасть в продукт, что — в операционный workflow, а что — вообще никуда.

Согласуйте sales, product и ops

Команды расходятся, когда каждая группа оценивает один и тот же запрос по-своему. Sales видит сделку, которую можно закрыть в этом квартале. Product видит еще одну ветку в приложении. Ops видит еще одну вещь, которую придется поддерживать в 2 часа ночи. Если никто не владеет финальным решением, обычно побеждает самый громкий голос.

Назначьте одного владельца для исключений и кастомной работы. В небольшой компании это может быть product lead, founder или fractional CTO. Остальные дают input, но решение принимает один человек и записывает, почему.

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

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

Используйте одну и ту же scorecard каждый раз. Спрашивайте, сколько клиентов, вероятно, будут использовать изменение в течение следующего года, поможет ли оно sales больше одного раза, какую нагрузку на support или ops оно добавит каждый месяц, можно ли решить ту же потребность через workflow и какой запланированный work сдвинется, если вы скажете «да».

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

Что делать дальше

Начните с запросов, которые уже лежат в backlog. Возьмите десять самых частых или десять самых спорных и разложите каждый в одну из трех корзин: сделать в продукте, решить через отдельный workflow или отказать.

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

Проведите review, где вместе будут product, sales и ops. Дайте каждому запросу одного владельца и одно решение. Уберите старые исключения, которыми сейчас никто не пользуется, даже если когда-то они казались срочными. Запишите причину каждого «нет», чтобы команда не возвращалась к тому же спору в следующем месяце.

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

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

Если запросы под конкретных клиентов продолжают сгибать ваш roadmap, короткий reset от человека со стороны может помочь. Oleg Sotnikov работает со стартапами и небольшими компаниями, которым нужны более четкие продуктовые решения без найма CTO на полный день.

Следующий шаг простой: разберите десять запросов, удалите два устаревших исключения и опубликуйте политику до того, как следующий sales call снова заставит решать все на ходу.