Я автоматизировал не то. И понял это слишком поздно
Автоматизировал входящие заявки — бизнес не ускорился. Узкое место было в другом месте, и я его просто не увидел. Рассказываю, как один вопрос разворачивает всю логику автоматизации.
Я автоматизировал процесс обработки входящих заявок. Настроил парсинг, сортировку, уведомления — всё работало. Только бизнес от этого не ускорился. Потому что узкое место было не там. Узкое место было в том, что менеджер перед ответом каждый раз лез в три разных места за информацией. Это я не автоматизировал. Это я даже не увидел — потому что не спросил, зачем этот процесс вообще существует.
Что такое JTBD и почему это не про маркетинг
Jobs to Be Done — это не методология для продуктовых команд. Это один вопрос, который стоит задать перед любой автоматизацией: какую работу клиент нанимает этот процесс делать?
Не «как он устроен» и не «что он делает». А зачем он вообще нужен — что происходит, если его убрать, и кто тогда пострадает.
Этот вопрос звучит просто. Но почти никто его не задаёт. Потому что когда приходишь автоматизировать, хочется сразу к инструментам. Посмотреть на процесс, найти повторяющиеся шаги, прикрутить n8n или Make — и готово.
Когда автоматизация ускоряет симптом
Есть такая ловушка: ты автоматизируешь процесс, он становится быстрее — но бизнес от этого не меняется. Потому что ты ускорил симптом, а не решил проблему.
Типичная картина. Владелец небольшого магазина хотел автоматизировать напоминания для покупателей. Логика понятная: меньше ручной работы, меньше забытых задач. Сели разбираться — и выяснилось, что напоминания существовали только потому, что информация о заказе была раскидана по трём местам. Менеджер не помнил статус — отсюда звонок. Автоматизировать напоминания в этой ситуации — это как купить будильник громче, когда проблема в том, что ты ложишься в три ночи.
Решили другое: собрали статусы в одно место. Напоминания перестали быть нужны почти полностью.
Один вопрос, который разворачивает всё на 180 градусов
Когда я начинаю работу с новым процессом, первый вопрос не «что автоматизируем». Первый вопрос — зачем этот шаг вообще существует в цепочке.
Иногда ответ очевидный. Иногда — нет. Бывает, что процесс живёт по инерции: кто-то когда-то так придумал, все привыкли, никто не пересматривал. Автоматизировать такое — значит закрепить ошибку навсегда и сделать её ещё дороже.
Бывает и другое: процесс нужный, но автоматизировать стоит совсем другое место в цепочке. Не там, где больно, а там, где возникает причина боли.
Именно поэтому JTBD — это не про теорию и не про Кристенсена. Это про то, чтобы не потратить месяц на автоматизацию того, что надо было просто выкинуть.
Как это работает на практике
Перед тем как трогать любой процесс, я задаю три вопроса. Что происходит, когда этот шаг выполняется хорошо? Что происходит, когда он ломается? И кто в бизнесе это чувствует первым?
Ответы на эти три вопроса почти всегда показывают, где реальная точка приложения усилий. Иногда это подтверждает исходную идею. Иногда — полностью меняет скоуп.
Типичная история: клиент пришёл автоматизировать выставление счетов. Оказалось, что счета выставлялись нормально — просто никто не отслеживал, оплачены ли они. Автоматизировали трекинг оплат и напоминания. Сэкономили не два часа в неделю, а несколько тысяч евро в месяц просроченной дебиторки.
Разница между «ускорить то, что есть» и «разобраться, что вообще нужно» — это и есть разница между автоматизацией ради автоматизации и автоматизацией, которая меняет деньги в бизнесе.
Если хочешь разобраться, что именно стоит автоматизировать в твоём бизнесе — и не потратить время на то, что не даст результата — давай разберёмся вместе.
Я автоматизировал процесс обработки входящих заявок. Настроил парсинг, сортировку, уведомления — всё работало. Только бизнес от этого не ускорился. Потому что узкое место было не там. Узкое место было в том, что менеджер перед ответом каждый раз лез в три разных места за информацией. Это я не автоматизировал. Это я даже не увидел — потому что не спросил, зачем этот процесс вообще существует.
Что такое JTBD и почему это не про маркетинг
Jobs to Be Done — это не методология для продуктовых команд. Это один вопрос, который стоит задать перед любой автоматизацией: какую работу клиент нанимает этот процесс делать?
Не «как он устроен» и не «что он делает». А зачем он вообще нужен — что происходит, если его убрать, и кто тогда пострадает.
Этот вопрос звучит просто. Но почти никто его не задаёт. Потому что когда приходишь автоматизировать, хочется сразу к инструментам. Посмотреть на процесс, найти повторяющиеся шаги, прикрутить n8n или Make — и готово.
Когда автоматизация ускоряет симптом
Есть такая ловушка: ты автоматизируешь процесс, он становится быстрее — но бизнес от этого не меняется. Потому что ты ускорил симптом, а не решил проблему.
Типичная картина. Владелец небольшого магазина хотел автоматизировать напоминания для покупателей. Логика понятная: меньше ручной работы, меньше забытых задач. Сели разбираться — и выяснилось, что напоминания существовали только потому, что информация о заказе была раскидана по трём местам. Менеджер не помнил статус — отсюда звонок. Автоматизировать напоминания в этой ситуации — это как купить будильник громче, когда проблема в том, что ты ложишься в три ночи.
Решили другое: собрали статусы в одно место. Напоминания перестали быть нужны почти полностью.
Один вопрос, который разворачивает всё на 180 градусов
Когда я начинаю работу с новым процессом, первый вопрос не «что автоматизируем». Первый вопрос — зачем этот шаг вообще существует в цепочке.
Иногда ответ очевидный. Иногда — нет. Бывает, что процесс живёт по инерции: кто-то когда-то так придумал, все привыкли, никто не пересматривал. Автоматизировать такое — значит закрепить ошибку навсегда и сделать её ещё дороже.
Бывает и другое: процесс нужный, но автоматизировать стоит совсем другое место в цепочке. Не там, где больно, а там, где возникает причина боли.
Именно поэтому JTBD — это не про теорию и не про Кристенсена. Это про то, чтобы не потратить месяц на автоматизацию того, что надо было просто выкинуть.
Как это работает на практике
Перед тем как трогать любой процесс, я задаю три вопроса. Что происходит, когда этот шаг выполняется хорошо? Что происходит, когда он ломается? И кто в бизнесе это чувствует первым?
Ответы на эти три вопроса почти всегда показывают, где реальная точка приложения усилий. Иногда это подтверждает исходную идею. Иногда — полностью меняет скоуп.
Типичная история: клиент пришёл автоматизировать выставление счетов. Оказалось, что счета выставлялись нормально — просто никто не отслеживал, оплачены ли они. Автоматизировали трекинг оплат и напоминания. Сэкономили не два часа в неделю, а несколько тысяч евро в месяц просроченной дебиторки.
Разница между «ускорить то, что есть» и «разобраться, что вообще нужно» — это и есть разница между автоматизацией ради автоматизации и автоматизацией, которая меняет деньги в бизнесе.
Если хочешь разобраться, что именно стоит автоматизировать в твоём бизнесе — и не потратить время на то, что не даст результата — давай разберёмся вместе.
Связанная услуга
ИИ-ассистент для бизнеса
Настраиваю ИИ-ассистента под конкретные задачи бизнеса: ответы клиентам, разбор входящих, документы и повторяющиеся рабочие процессы.