Масштабирование без раздувания штата

Ситуация

Небольшая студия ремонта техники запустила акцию, и за неделю заявок пришло вдвое больше обычного. Бот отвечал мгновенно, менеджеры успевали считать стоимость, мастера были готовы работать. Но через десять дней клиенты начали звонить с одним вопросом: «Когда приедет мастер?»

Заявки накопились не там, где их ждали. Все визиты распределял сам владелец: он смотрел карту, учитывал пробки и ставил мастеров по адресам. В обычные дни это занимало полчаса. Теперь на это не хватало вечера.

В чём настоящая проблема

Симптом: «Всё работало, а потом встало». Причина: пропускную способность бизнеса определяет самый слабый этап цепочки, а в спокойное время он не заметен. Пока поток небольшой, любой этап справляется, и кажется, что проблем нет.

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

Ещё одна причина, по которой узкие места не видны: загрузка этапа растёт нелинейно. При загрузке 60% небольшие сбои рассасываются сами. При загрузке 95% одна сложная заявка или один больной сотрудник создают очередь, которая уже не уменьшается. Поэтому «мы же справлялись» ничего не говорит о запасе.

Как это работает

Узкое место — этап цепочки с самой низкой пропускной способностью. Пропускная способность — сколько заявок этап может обработать за месяц при реальных часах работы.

Формула простая: часы, доступные этапу в месяц, умножить на 60 и разделить на минуты, которые уходят на одну заявку. Результат — число заявок в месяц. Минимальное число по всей цепочке и есть предел бизнеса, как бы хорошо ни работали остальные этапы.

Бывают узкие места пяти типов.

–

Человеческие: этап делает один человек, и заменить его некому.

–

Ручные: данные переносят из одного сервиса в другой руками.

–

Сервисные: у программы есть лимиты на число сообщений, запросов, записей или одновременных соединений.

–

Решающие: без вашего согласия или подписи заявка не движется.

–

Денежные: оплаты, возвраты и сверки обрабатываются медленнее, чем растёт поток.

Часть этих мест видна в таблице, часть — только при проверке. Поэтому метод состоит из двух частей: расчёт и стресс-тест. Стресс-тест — это пересчёт показателей при потоке выше текущего: в полтора, два и три раза.

Пошаговая инструкция

Шаг 1. Нарисуйте цепочку. Запишите этапы от обращения клиента до закрытия заявки: приём, ответ, расчёт, согласование, исполнение, оплата, сверка, обратная связь. Нужно 5–9 этапов. Если вышло больше, объедините мелкие. Если не получается вспомнить этап, пройдите путь одной реальной заявки по переписке.

Шаг 2. Укажите исполнителя и сервис. Для каждого этапа запишите: кто делает (человек или роль) и где (программа, таблица, мессенджер). Должна получиться таблица из трёх столбцов. Если исполнителей двое, запишите обоих.

Шаг 3. Замерьте время на заявку. Возьмите 10 заявок и засеките минуты на каждом этапе. Берите не среднее, а типичное значение: отсортируйте результаты и выберите серединное. Если замер невозможен, спросите исполнителя и пометьте оценку звёздочкой.

Шаг 4. Определите чистые часы. Из 160 рабочих часов вычтите совещания, переключения на другие задачи, отпуска и больничные в среднем. Запишите, сколько часов в месяц этап реально получает. Если не уверены, возьмите 70% от номинальных часов.

Шаг 5. Посчитайте пропускную способность. Формула: часы × 60 ÷ минуты на заявку. Запишите результат рядом с каждым этапом. Должно получиться число заявок в месяц. Если вышло слишком большое число, проверьте, не перепутали ли минуты с часами.

Шаг 6. Найдите узкое место. Выделите минимальное число. Отметьте и второй этап снизу: он станет узким следующим, когда вы расчистите первое. Запишите оба названия.

Шаг 7. Проведите стресс-тест на бумаге. Умножьте текущий поток на 1,5, на 2 и на 3. Для каждого значения посчитайте загрузку этапа: заявки × минуты ÷ 60 ÷ чистые часы. Отметьте этапы, где загрузка выше 80%, и те, где выше 100%. Загрузка выше 100% означает очередь, которая растёт.

Шаг 8. Проверьте лимиты сервисов. Для каждой программы в цепочке найдите на официальной странице сервиса ограничения вашего тарифа: число сообщений, запросов, пользователей, записей, размер базы. Не полагайтесь на память: условия меняются. Затем запишите, при каком потоке вы упрётесь в лимит. Если лимиты найти не удалось, напишите в поддержку сервиса.

Шаг 9. Запустите тестовую пачку. Отправьте в систему 20–30 тестовых заявок подряд, с пометкой «ТЕСТ», чтобы они не попали в отчёты. Наблюдайте: где появляются задержки, ошибки, потерянные записи. Должен получиться список сбоев. Если сбоев нет, увеличьте пачку.

Шаг 10. Найдите скрытые узкие места. Задайте пять вопросов, по одному на каждый тип: кого нельзя заменить, что переносится руками, где упрёмся в лимит, где всё ждёт моего решения, где копятся оплаты и возвраты. Запишите ответы.

Шаг 11. Выберите способ устранения. Для узкого места подходит один из способов: убрать этап, упростить, автоматизировать, передать другому, добавить ресурс. Начинайте с первых трёх, это дешевле найма. Запишите выбор и ожидаемую пропускную способность после изменения.

Шаг 12. Измените и замерьте снова. Внесите одно изменение, подождите две недели и повторите шаги 3–6 для этого этапа. Если пропускная способность не выросла, вернитесь на шаг 3: возможно, замер был неточным.

Рабочие шаблоны

Шаблон 1. Карта цепочки.

Ты — аналитик операционных процессов. Вот описание того, как в моём бизнесе обрабатывается заявка: [опишите своими словами от обращения до закрытия]. Разбей путь на 5–9 этапов. Для каждого укажи: название, кто выполняет, в каком инструменте, что на входе и что на выходе. Если данных не хватает, задай уточняющие вопросы, а не придумывай.

Что менять: описание процесса. Проверьте, не пропустила ли модель этап, который вы знаете по опыту.

Шаблон 2. Таблица пропускной способности.

Вот данные по этапам: название, минуты на заявку, чистые часы в месяц. Данные: [вставьте]. Посчитай пропускную способность каждого этапа по формуле часы × 60 ÷ минуты. Затем посчитай загрузку при потоке [N], [1,5N], [2N], [3N] заявок в месяц. Покажи расчёт по шагам и выдели этапы с загрузкой выше 80% и выше 100%.

Что менять: данные и текущий поток N. Арифметику перепроверьте на калькуляторе.

Шаблон 3. Проверка сервисных лимитов. Это рабочий документ, а не промпт. Заведите таблицу с колонками: «Сервис», «Что ограничено», «Лимит по моему тарифу», «Где проверил». Колонку «Лимит» заполняйте только по официальной странице сервиса и записывайте дату проверки. Если лимит не нашли, пишите «уточнить в поддержке», а не цифру по памяти.

Шаблон 4. Выбор способа устранения.

Узкое место в моём бизнесе: [этап], пропускная способность [число] заявок в месяц, нужна [целевое число]. Сейчас этап делает [кто], тратит [минуты] на заявку. Предложи по одному варианту для каждого способа: убрать этап, упростить, автоматизировать, передать другому, добавить ресурс. Для каждого оцени, во сколько раз вырастет пропускная способность, и укажи риски. Отметь, что требует проверки юристом или бухгалтером.

Что менять: этап и числа. Оценки модели — гипотезы, их проверяют замером.

Учебный кейс с расчётами

Все числа условные. Сервисная компания: 300 заявок в месяц, цель — 900. Цепочка из пяти этапов.

Этап

Минут на заявку

Чистые часы в месяц

Пропускная способность

Первичный ответ

2

60

1 800

Квалификация и расчёт

12

120

600

Согласование

10

150

900

Распределение визитов

6

40

400

Сверка оплат

4

30

450

Как считали, на примере распределения: 40 × 60 = 2 400, делим на 6, получаем 400. Минимум цепочки — 400 заявок, это распределение, которое делает владелец. Вторые снизу — сверка оплат (450) и расчёт (600).

Стресс-тест на поток 900. Загрузка получается такой: первичный ответ 50%, расчёт 150%, согласование 100%, распределение 225%, сверка 200%. Ломается четыре этапа из пяти. Если бы владелец нанял ещё менеджера по расчётам, это снизило бы одну цифру из четырёх.

План устранения (условный).

–

Распределение: записать правила (район, тип работ, окно времени), чтобы помощник на базе ИИ готовил черновик расписания, а диспетчер проверял. Время 3 минуты, часы 60. Способность: 60 × 60 ÷ 3 = 1 200.

–

Расчёт: шаблоны стоимости по типовым работам, 6 минут вместо 12. Способность: 120 × 60 ÷ 6 = 1 200.

–

Согласование: готовые шаблоны ответов, 7 минут. Способность: 150 × 60 ÷ 7 ≈ 1 285.

–

Сверка оплат: автоматическая выгрузка платежей и сопоставление с заказами, 2 минуты, часы 45. Способность: 45 × 60 ÷ 2 = 1 350.

Загрузка при потоке 900 после изменений: распределение 900 × 3 ÷ 60 = 45 часов из 60, это 75%. Расчёт: 900 × 6 ÷ 60 = 90 часов из 120, тоже 75%. Согласование: 105 из 150, 70%. Сверка: 30 из 45, около 67%. Все этапы ниже 80%.

Суммарные часы вырастают со 170 до 300: рост 1,76 раза при потоке в три раза больше. Это учебная модель, и реальные цифры могут отличаться, но принцип понятен: ускорять надо этапы, а не просто добавлять людей.

Второй сценарий, интернет-магазин. Цепочка: заказ, подтверждение, сборка, отправка, поддержка, возвраты. В спокойное время узкое место не видно. В пик им обычно становятся сборка (один склад, одна смена) и возвраты (каждый возврат требует личного решения). Расчёт тот же: часы × 60 ÷ минуты на заказ, затем стресс-тест на потоке 1,5, 2 и 3.

Ошибки внедрения

Замер по ощущениям. Исполнитель говорит «минут пять», а на деле двенадцать. Предотвращение: засечь время на 10 реальных заявках.

Номинальные часы. В расчёт берут 160 часов, хотя совещания и отпуска съедают треть. Предотвращение: использовать чистые часы.

Устранение не того места. Улучшают самый шумный этап, а не самый слабый. Предотвращение: сначала найти минимум в таблице.

Забытые лимиты сервисов. Тариф рассчитан на сотни сообщений, а нужно тысячи. Предотвращение: проверить лимиты на официальной странице и прогнать тестовую пачку.

Владелец как узкое место. Этап «согласование у меня» не попал в таблицу, потому что это «не работа». Предотвращение: записать этап и время, как для любого сотрудника.

Тест на реальных клиентах. Нагрузку проверяют на живых заявках, и клиенты видят сбои. Предотвращение: тестовые заявки с пометкой и отдельным каналом.

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

Как проверить, что работает

Метрики:

–

пропускная способность каждого этапа и всей цепочки (минимум по этапам);

–

загрузка каждого этапа при текущем потоке;

–

загрузка при потоке ×2 и ×3 по расчёту;

–

число сбоев в тестовой пачке.

Критерий «внедрено»: есть таблица этапов с замеренным временем и чистыми часами, найдено узкое место, проведён стресс-тест на ×2 и ×3, для узкого места выбран способ устранения с датой повторного замера. Критерий «не внедрено»: время на этапах взято из головы или нет расчёта при росте потока.

Вопросы владельцев

«У меня всего три этапа. Мне нужна вся эта таблица?» Нужна, но она будет короткой. Три строки тоже показывают, где предел. Часто выясняется, что одно из этих мест держится на вас.

«Что делать, если время на заявку сильно разное, от 5 минут до часа?» Разделите заявки на простые и сложные и считайте отдельно. Одно среднее число здесь только вводит в заблуждение.

«Узкое место — сам я. Как это исправить?» Запишите свои решения как правила: по каким условиям вы решаете так или иначе. Правила можно отдать сотруднику или помощнику на базе ИИ с проверкой выборки. Подробнее это разбирается в главах 5 и 6.

«А если ИИ оценит узкие места сам?» Модель не видит вашей реальной работы и не знает лимитов вашего тарифа. Она может помочь с расчётом, но входные данные замеряете вы.

Альтернатива без ИИ. Таблица, секундомер и калькулятор дают тот же результат. Для бизнеса до 100 заявок в месяц это даже разумнее: замеры займут вечер.

Чек-лист главы

–

Записана цепочка из 5–9 этапов от обращения до закрытия.

–

У каждого этапа указан исполнитель и сервис.

–

Время на заявку замерено на 10 реальных заявках, а не названо по памяти.

–

Посчитаны чистые часы по каждому этапу.

–

Рассчитана пропускная способность и найдено узкое место.

–

Проведён стресс-тест на потоке ×1,5, ×2 и ×3.

–

Проверены лимиты сервисов по официальным страницам.

–

Проведён тестовый прогон пачки заявок.

–

Для узкого места выбран способ устранения и назначена дата повторного замера.

Практическое задание

Время: 45–60 минут.

Откройте таблицу из главы 1 и создайте лист «Цепочка». Выполните шаги 1–7 на своих данных: этапы, исполнители, время на заявку, чистые часы, пропускная способность, узкое место, стресс-тест на ×2.

Критерий выполнения: на листе есть таблица с числами, выделено минимальное значение, записана загрузка каждого этапа при потоке ×2, а рядом написано одно предложение о том, что вы будете менять первым.

Переход

Вы знаете, где цепочка сломается при росте. Но прежде чем чинить её и привлекать больше заявок, нужно проверить, что каждая новая заявка приносит больше, чем стоит. В следующей главе мы построим unit-экономику роста: расчёт, который покажет, когда рост выгоден, а когда он только увеличивает убытки.

Ситуация

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

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

В чём настоящая проблема

Симптом: «Заявок больше, а денег нет». Причина: владелец смотрел на стоимость заявки, а не на то, что остаётся от неё после всех затрат. Дешёвая заявка и выгодная заявка — это разные вещи.

Обычные советы здесь не помогают. «Снижайте стоимость привлечения» приводит к притоку слабых заявок. «Повышайте средний чек» работает не всегда: клиент может уйти. Без полного расчёта любой совет — гадание.

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

Как это работает

Unit-экономика — это расчёт прибыли на одну «единицу» бизнеса. Единицей может быть заявка, заказ или клиент. Мы будем работать с двумя единицами.

Экономика заявки отвечает на вопрос: сколько в среднем остаётся с одной входящей заявки, если учесть, что часть заявок не превращается в оплату.

Экономика клиента отвечает на вопрос: сколько в сумме остаётся с одного клиента за всё время, пока он у вас покупает.

Для расчёта нужны несколько понятий.

–

Конверсия — доля заявок, дошедших до оплаты.

–

Средний чек — средняя сумма одной оплаты.

–

Маржинальная прибыль (маржа) — то, что остаётся от чека после прямых затрат: материалов, работы исполнителя, доставки, комиссии платёжной системы. Аренда и зарплата управляющих сюда не входят, они не растут с каждым заказом.

–

CAC (стоимость привлечения клиента) — сколько вы тратите на рекламу и продажи, чтобы получить одного платящего клиента. Считается как расходы на привлечение, делённые на число новых клиентов.

–

LTV (ценность клиента за всё время) — сколько маржинальной прибыли приносит один клиент за период, пока покупает. Мы считаем её по марже, а не по выручке, иначе число выйдет завышенным.

–

Окупаемость — за какое время маржа с клиента покрывает затраты на его привлечение.

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

Пошаговая инструкция

Шаг 1. Выберите единицу и период. Возьмите последние 3–6 месяцев и решите, считаете вы по заявке, по заказу или по клиенту. Для услуг с повторными покупками считайте по клиенту, для разовых продаж — по заказу. Запишите выбор в шапку нового листа «Экономика».

Шаг 2. Разделите источники. Составьте список каналов, откуда приходят заявки: реклама, рекомендации, поиск, повторные обращения. Для каждого понадобится свой расчёт. Если разбить нельзя, отметьте это: итоговое число будет менее точным.

Шаг 3. Соберите расходы на привлечение. По каждому каналу запишите рекламу, оплату подрядчиков, часть зарплаты, которая уходит именно на привлечение. Должна получиться сумма в рублях за период. Если сомневаетесь, относить ли расход, включайте: лучше занизить прибыль, чем завысить.

Шаг 4. Посчитайте заявки и клиентов. Для каждого канала запишите число заявок и число оплативших. Разделите второе на первое, получите конверсию. Если оплата растянута во времени, берите заявки, которым уже больше срока обычного цикла сделки.

Шаг 5. Посчитайте CAC. Расходы на привлечение разделите на число оплативших клиентов. Запишите по каждому каналу. Должны получиться разные числа, а если они совпали, проверьте, не взяли ли вы общую сумму для всех.

Шаг 6. Посчитайте средний чек и маржу. Выручку разделите на число оплат. Затем вычтите прямые затраты на выполнение и комиссии. Должна получиться маржа в рублях на одну оплату. Если не знаете прямые затраты, спросите бухгалтера, какие статьи растут вместе с заказом.

Шаг 7. Определите число покупок на клиента. Посмотрите, сколько в среднем раз клиент платит за выбранный период. Если данных мало, возьмите осторожную оценку и пометьте её звёздочкой. Не берите лучших клиентов: нужен средний.

Шаг 8. Посчитайте LTV. Умножьте маржу с одной оплаты на среднее число оплат. Результат — маржинальная прибыль с клиента за период. Если клиенты уходят заметно, не продлевайте период в расчёте дальше, чем у вас есть данные.

Шаг 9. Сравните LTV и CAC. Разделите LTV на CAC по каждому каналу. Отметьте каналы выше вашего порога, около него и ниже. Запишите вывод одним предложением на канал.

Шаг 10. Посчитайте срок окупаемости. Разделите CAC на маржу в месяц с клиента. Получите число месяцев, за которые вы вернёте затраты на привлечение. Эти месяцы вы финансируете из собственных денег, и это нужно учитывать в резерве (глава 12).

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

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

Рабочие шаблоны

Шаблон 1. Расчёт экономики по каналу.

Ты — финансовый аналитик малого бизнеса. Посчитай unit-экономику канала. Данные за период: расходы на привлечение [руб.], заявок [число], оплативших [число], выручка [руб.], прямые затраты на выполнение [руб.], среднее число оплат на клиента [число]. Рассчитай конверсию, CAC, средний чек, маржу на оплату, LTV по марже, отношение LTV к CAC. Покажи каждый расчёт по шагам. Данные не придумывай, при нехватке задай вопрос.

Что менять: все значения в скобках. Результат перепроверьте калькулятором.

Шаблон 2. Сравнение каналов.

Вот таблица по каналам: название, CAC, LTV, конверсия, срок окупаемости в месяцах. Данные: [вставьте]. Отсортируй каналы от самого выгодного к самому слабому. Для каждого дай вывод: усиливать, держать или сокращать, и одну причину. Укажи, каких данных не хватает для уверенного вывода.

Что менять: таблицу. Решение о бюджете остаётся за вами: модель видит только цифры, а не рыночную ситуацию.

Шаблон 3. Стресс-тест экономики.

Базовые данные: конверсия [%], CAC [руб.], средний чек [руб.], маржа [%], число оплат на клиента [число]. Пересчитай LTV, отношение LTV к CAC и срок окупаемости для трёх сценариев: конверсия ниже на 20%, CAC выше на 20%, средний чек ниже на 10%. Покажи, какой сценарий опаснее всего, и при каком изменении отношение опустится ниже [мой порог].

Что менять: значения и порог. Сценарии можно заменить своими.

Шаблон 4. Решение о бюджете. Рабочий документ для таблицы. Колонки: «Канал», «Бюджет сейчас», «LTV/CAC», «Окупаемость, мес.», «Решение», «Дата пересмотра». Заполняйте после расчёта и возвращайтесь к таблице раз в месяц. Решение без даты пересмотра не считается принятым.

Учебный кейс с расчётами

Все числа условные. Онлайн-школа тратит на рекламу 400 000 руб. в месяц в двух каналах.

Показатель

Канал А

Канал Б

Расходы, руб.

200 000

200 000

Заявок

400

200

Оплативших

20

25

Средний чек, руб.

12 000

18 000

Конверсия. Канал А: 20 ÷ 400 = 5%. Канал Б: 25 ÷ 200 = 12,5%.

CAC. Канал А: 200 000 ÷ 20 = 10 000 руб. Канал Б: 200 000 ÷ 25 = 8 000 руб. Заявка в канале А стоит 500 руб., в канале Б — 1 000 руб., но платящий клиент во втором дешевле. Именно с этого перекоса начиналась ситуация главы.

Маржа. Прямые затраты на оплату (преподаватель, платформа, комиссия) в канале А составляют 7 200 руб., маржа 4 800 руб. В канале Б затраты 9 900 руб., маржа 8 100 руб.

Покупки на клиента. В канале А клиенты в среднем платят 1,2 раза (многие уходят после первого пакета), в канале Б — 2 раза.

LTV по марже. Канал А: 4 800 × 1,2 = 5 760 руб. Канал Б: 8 100 × 2 = 16 200 руб.

LTV к CAC. Канал А: 5 760 ÷ 10 000 = 0,58. Это значит, что каждый привлечённый клиент приносит меньше, чем стоит. Канал Б: 16 200 ÷ 8 000 ≈ 2,03. Это выше единицы, но ниже порога 3, который мы взяли для примера.