Я автоматизировал не то. И понял это слишком поздно

Автоматизировал входящие заявки — бизнес не ускорился. Узкое место было в другом месте, и я его просто не увидел. Рассказываю, как один вопрос разворачивает всю логику автоматизации.

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

Что такое JTBD и почему это не про маркетинг

Jobs to Be Done — это не методология для продуктовых команд. Это один вопрос, который стоит задать перед любой автоматизацией: какую работу клиент нанимает этот процесс делать?

Не «как он устроен» и не «что он делает». А зачем он вообще нужен — что происходит, если его убрать, и кто тогда пострадает.

Этот вопрос звучит просто. Но почти никто его не задаёт. Потому что когда приходишь автоматизировать, хочется сразу к инструментам. Посмотреть на процесс, найти повторяющиеся шаги, прикрутить n8n или Make — и готово.

Когда автоматизация ускоряет симптом

Есть такая ловушка: ты автоматизируешь процесс, он становится быстрее — но бизнес от этого не меняется. Потому что ты ускорил симптом, а не решил проблему.

Типичная картина. Владелец небольшого магазина хотел автоматизировать напоминания для покупателей. Логика понятная: меньше ручной работы, меньше забытых задач. Сели разбираться — и выяснилось, что напоминания существовали только потому, что информация о заказе была раскидана по трём местам. Менеджер не помнил статус — отсюда звонок. Автоматизировать напоминания в этой ситуации — это как купить будильник громче, когда проблема в том, что ты ложишься в три ночи.

Решили другое: собрали статусы в одно место. Напоминания перестали быть нужны почти полностью.

Один вопрос, который разворачивает всё на 180 градусов

Когда я начинаю работу с новым процессом, первый вопрос не «что автоматизируем». Первый вопрос — зачем этот шаг вообще существует в цепочке.

Иногда ответ очевидный. Иногда — нет. Бывает, что процесс живёт по инерции: кто-то когда-то так придумал, все привыкли, никто не пересматривал. Автоматизировать такое — значит закрепить ошибку навсегда и сделать её ещё дороже.

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

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

Как это работает на практике

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

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

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

Разница между «ускорить то, что есть» и «разобраться, что вообще нужно» — это и есть разница между автоматизацией ради автоматизации и автоматизацией, которая меняет деньги в бизнесе.

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

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

Что такое JTBD и почему это не про маркетинг

Jobs to Be Done — это не методология для продуктовых команд. Это один вопрос, который стоит задать перед любой автоматизацией: какую работу клиент нанимает этот процесс делать?

Не «как он устроен» и не «что он делает». А зачем он вообще нужен — что происходит, если его убрать, и кто тогда пострадает.

Этот вопрос звучит просто. Но почти никто его не задаёт. Потому что когда приходишь автоматизировать, хочется сразу к инструментам. Посмотреть на процесс, найти повторяющиеся шаги, прикрутить n8n или Make — и готово.

Когда автоматизация ускоряет симптом

Есть такая ловушка: ты автоматизируешь процесс, он становится быстрее — но бизнес от этого не меняется. Потому что ты ускорил симптом, а не решил проблему.

Типичная картина. Владелец небольшого магазина хотел автоматизировать напоминания для покупателей. Логика понятная: меньше ручной работы, меньше забытых задач. Сели разбираться — и выяснилось, что напоминания существовали только потому, что информация о заказе была раскидана по трём местам. Менеджер не помнил статус — отсюда звонок. Автоматизировать напоминания в этой ситуации — это как купить будильник громче, когда проблема в том, что ты ложишься в три ночи.

Решили другое: собрали статусы в одно место. Напоминания перестали быть нужны почти полностью.

Один вопрос, который разворачивает всё на 180 градусов

Когда я начинаю работу с новым процессом, первый вопрос не «что автоматизируем». Первый вопрос — зачем этот шаг вообще существует в цепочке.

Иногда ответ очевидный. Иногда — нет. Бывает, что процесс живёт по инерции: кто-то когда-то так придумал, все привыкли, никто не пересматривал. Автоматизировать такое — значит закрепить ошибку навсегда и сделать её ещё дороже.

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

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

Как это работает на практике

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

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

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

Разница между «ускорить то, что есть» и «разобраться, что вообще нужно» — это и есть разница между автоматизацией ради автоматизации и автоматизацией, которая меняет деньги в бизнесе.

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

Связанная услуга

ИИ-ассистент для бизнеса

Настраиваю ИИ-ассистента под конкретные задачи бизнеса: ответы клиентам, разбор входящих, документы и повторяющиеся рабочие процессы.

Посмотреть услугу Написать мне

Почитать дальше

Связанные материалы

13.04.2026 около 3 минут

Ты уже полгода собираешься автоматизировать бизнес. И всё никак.

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

Читать далее
10.04.2026 около 3 минут

Пока ты выбираешь CRM, конкуренты уже автоматизировали входящие через Telegram-бота

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

Читать далее
29.05.2026 около 5 минут

Первая автоматизация с быстрой окупаемостью

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

Читать далее