Лидогенерация клиентов одного человека: сколько контактов нужно на одну договорённость, и почему очередь важнее воронки

Я более 15 лет работаю в партнёрском бизнесе и много лет смотрю, как люди, которые продают сами, без отдела продаж, планируют свою работу. Почти все планируют одинаково: «надо больше контактов». Когда что-то не получается, ответ тот же: «значит, мало написал». И почти никто не может сказать, сколько контактов ему на самом деле нужно и почему через месяц их всё равно не хватает.
У этого вопроса есть простое инженерное решение, и оно давно лежит в теории очередей. Ниже попробую разложить лидогенерацию для одного человека как систему с входом, выходом и временем пребывания, а потом посчитать её на условных числах.
Воронка это не только конверсии, но и время
Обычно лидогенерацию описывают как воронку: из всех, кто узнал о вас, часть ответила, часть заинтересовалась, часть договорилась о следующем шаге. Каждый этап характеризуется долей, которая проходит дальше. Если перемножить доли, получится, сколько входящих контактов нужно на одну договорённость.
Посчитаем на условном примере. Допустим, из тех, кому вы написали первым, отвечает каждый третий, то есть доля 1/3. Из ответивших разговор о задаче доходит у половины, 1/2. Из таких разговоров к договорённости о следующем шаге приходит каждый четвёртый, 1/4. Перемножаем: 1/3 × 1/2 × 1/4 = 1/24. Значит, на одну договорённость нужно в среднем 24 первых контакта.
Это полезное число, но оно врёт о главном. Оно ничего не говорит о времени, а именно время у человека, который работает один, ограничено жёстче всего.
Закон Литтла и «живые» разговоры
В 1961 году Джон Литтл опубликовал в журнале Operations Research короткое доказательство формулы, которая с тех пор носит его имя: L = λW. Среднее число объектов в системе L равно средней скорости их поступления λ, умноженной на среднее время, которое каждый объект в системе проводит W. Формула верна для очень широкого класса систем и не требует знать, как именно устроены процессы внутри.
Применим её к переписке. Пусть вы начинаете в среднем два новых разговора в день, λ = 2. Пусть разговор, если его не закрыть явно, «живёт» в вашем внимании в среднем пять дней: вы ждёте ответа, напоминаете, снова ждёте, W = 5. Тогда одновременно у вас в работе L = 2 × 5 = 10 разговоров.
Теперь увеличьте вход, как советуют все: λ = 6 в день при том же W. Получаем L = 6 × 5 = 30 одновременных разговоров. Человек, который продаёт сам и параллельно работает, физически не держит тридцать диалогов в голове. Часть из них молча проваливается в тишину, и доля доходящих до договорённости падает. Добавили вход и получили меньше результата.
Что из этого следует на практике
Вывод неочевидный для тех, кто привык мыслить воронкой: управлять стоит не только входом, но и временем пребывания. Если сократить W с пяти дней до двух, то при тех же шести новых разговорах в день L = 6 × 2 = 12, и это уже можно удержать.
Сократить W можно двумя способами, и первый из них в том, чтобы закрывать разговоры явно. Если человек не ответил на второе сообщение, разговор переводится в «тишину» и перестаёт занимать место. Второй: делать так, чтобы человек приходил к разговору уже подготовленным, то есть узнавал о вас и о вашем предложении до переписки. Тогда разговор короче, потому что половину объяснений он уже прочитал сам.
Где здесь ошибается интуиция
Интуиция говорит: мало результата, значит, мало контактов. Закон Литтла говорит: при ограниченном внимании рост входа без сокращения времени пребывания увеличивает очередь, а не результат. Это та же ошибка, что и у перегруженного сервера: добавлять запросы, когда растёт время ответа, значит ухудшать ситуацию.
Я не призываю писать меньше людям. Я предлагаю сначала посчитать, сколько разговоров вы реально можете вести одновременно, и только потом решать, сколько новых начинать. Для этого достаточно двух чисел из собственной истории: сколько новых разговоров вы начинаете в среднем и сколько дней длится разговор до явного финала.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.