Хто вирішує і хто платить

Демо, яке захоплює людину перед тобою, однаково може ні до чого не привести, бо в більшості продажів кілька людей грають різні ролі:

• користувач відчуває проблему й щодня працюватиме з продуктом;
• той, хто ухвалює рішення, каже «так» чи «ні»;
• економічний покупець (economic buyer) справді платить.

В автосервісі Greg на шість постів адміністраторка Martha — користувачка: вона вручну набирає нагадування у Viber, приблизно п'ять годин на місяць. Власник Greg — і той, хто ухвалює рішення, і економічний покупець. Він може витратити гроші, але не відчуває проблеми і ніколи не рахував ці п'ять годин.

Продукту торкаються й інші. Механіки вноситимуть пробіг та історію ремонтів, тож вони користувачі, від яких залежать дані. Власники авто отримують нагадування й мають із цього користь, але GarageDesk нічого не платять.

Тож коли комусь подобається демо, перше питання не «чи куплять?», а «яку роль грає ця людина?» Сказати «так» грошима може лише той, у кого гроші.

«Я скажу власникові» — один із найпоширеніших способів, яким перспективний продаж тихо помирає. Користувач щиро це обіцяє, але переказ із других рук губить усе, що спрацювало на демо: цифри, приклади, відповіді на запитання власника. До того ж у користувача повний день власної роботи.

Допомагає залучити до розмови того, хто ухвалює рішення, разом зі справжніми цифрами користувача:

1. попроси в користувача його числа: години на місяць на проблему, дзвінки, втрачених клієнтів;
2. спитай, коли буває власник і чи може користувач теж бути присутнім;
3. зустрінься з власником у присутності користувача й говоріть про ці числа.

Для автосервісу Greg: п'ять годин Martha на місяць на нагадування і постійні клієнти, які не повертаються, у суботу зранку, і Martha в кімнаті.

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

Спокусливо не зважати на всіх, хто не ухвалює рішень і не платить. Це помилка, бо користувачі можуть заблокувати продукт, не сказавши й слова.

У GarageDesk нагадування залежать від даних, які вносять механіки: пробіг і виконані роботи для кожного авто. Якщо механікові це набридає і він пропускає, нагадуванням ні на що спертися. Ніхто ні від чого не відмовлявся; продукт просто перестає працювати, а за три місяці власник скасовує підписку, бо «не допомогло».

Тож користувачі важливі двічі:

• до продажу — як люди, що відчувають проблему й приносять цифри;
• після продажу — як люди, чиї щоденні звички вирішують, чи дає продукт те, за що заплатив власник.

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

Підписує власник, але чи продовжить він підписку, вирішують користувачі.

Ролі не завжди належать різним людям. У гаражі Paul на два пости Paul одночасно власник і механік: він відчуває проблему, вирішує і платить. Усі три ролі в одній людині.

Це змінює продаж у двох напрямках:

• швидше: нікого не треба переконувати через посередника, немає «я скажу власникові». Якщо Paul переконаний, рішення може статися в тій самій розмові;
• важче привернути увагу: Paul цілий день під машиною, а телефон дзвонить. Часу слухати демо в нього найменше, тож розмова має бути короткою і про його власні цифри.

У більших автосервісах ролі розходяться. В автосервісі Greg на шість постів є власник, який вирішує і платить, адміністраторка, яка відчуває проблему, і механіки, які вносять дані. Там однієї зустрічі рідко досить.

Корисна звичка — для кожного автосервісу, де буваєш, записувати, хто яку роль грає. Той самий продукт потребує іншої розмови в гаражі на два пости, ніж в автосервісі на шість, і плутанина між ними марнує візити.

Той самий продукт має різні причини існувати для різних ролей, і кожна людина слухає свої.

Власник, який платить, мислить машинами, візитами й грошима. Список функцій («онлайн-запис, нагадування, історія ремонтів в одній панелі») змушує його перекладати самому, а він зазвичай не стане. Він чує витрату, яку видно, або дохід, який можна порахувати:

• п'ять годин Martha на місяць на нагадування — витрата, на яку він ніколи не дивився;
• постійні клієнти, які забувають про наступне ТО і йдуть деінде, — дохід, що виходить за двері.

Користувачку хвилює її день: вільні вечори, менше незручних дзвінків, менше сердитих клієнтів біля стійки.

Тож добра розмова з Greg починається з його чисел, а не з функцій продукту: «Martha витрачає близько п'яти годин на місяць на нагадування, а частина постійних клієнтів однаково не повертається. Скільки їх приїжджало навесні і скільки повернулося цієї осені?» Продукт з'являється наприкінці, коротко, як спосіб збільшити це число.

Користувач робить проблему реальною; той, хто ухвалює рішення, перетворює її на «так» чи «ні».

«Постійні клієнти йдуть деінде» переконує лише тоді, коли це власне число власника, пораховане з його власних записів. Розрахунок короткий:

1. Втрачені постійні клієнти = постійні клієнти минулого періоду − ті, хто повернувся. Бери два порівнянні сезони, як-от минулу весну і цю осінь.
2. Дохід з одного постійного клієнта на рік = середній чек за візит × візитів на рік.
3. Дохід, що йде геть = втрачені клієнти × дохід з одного клієнта на рік.

Приклад: минулої весни приїжджало 120 постійних клієнтів, цієї осені повернулося 84, тож 36 — ні. Постійний клієнт витрачає приблизно 2 500 грн за візит і приїжджає двічі на рік: 36 × 2 × 2 500 = 180 000 грн на рік.

Чесним розрахунок роблять дві речі. По-перше, цифри дає власник, тож результат — «його число, а не твоє». По-друге, не кожного втраченого клієнта можна повернути: хтось переїхав чи продав авто. Сервіс нагадувань не поверне всіх 36, але навіть кілька з них багаторазово покриють плату 600 грн на місяць.

Типова помилка — пропустити один множник, найчастіше кількість візитів на рік, і тоді відповідь удвічі менша.

Знання ролей змінює те, з якої проблеми варто почати. Проблема може бути справжньою і все одно важко продаватися, якщо той, хто платить, її не відчуває.

Розклади проблеми-кандидати за тим, хто їх відчуває і в якій валюті:

• відчуває лише персонал, власник не бачить: механікам не подобаються паперові картки робіт, у Martha замалий стіл. Справжні проблеми, але власник не вважає їх своєю витратою, тож не платитиме, щоб їх прибрати;
• відчувають ті, хто взагалі не платить: власники авто хотіли б застосунок з історією ремонтів. Приємно для них, але вони не клієнти GarageDesk;
• власник відчуває в грошах, які може порахувати: постійні клієнти забувають про наступне ТО і їдуть до іншого автосервісу. Це б'є прямо по доходу власника, у візитах, які він може порахувати.

Останній тип продати найлегше, бо власник бачить виграш у власних записах.

Проблеми, які відчувають користувачі, теж важливі: вони роблять аргумент реальним і вирішують, чи продуктом користуватимуться. Але перша проблема, під яку будувати, має бути такою, яку той, хто платить, може виразити числом.

Продаж малому бізнесу має простий порядок, і більшість починає з неправильного кінця: презентує першій зустрічній людині й одразу просить зобов'язання.

Порядок, який працює:

1. Знайди людину, яка щодня відчуває проблему. В автосервісі Greg це Martha за стійкою.
2. Збери її цифри: витрачені години, зроблені дзвінки, втрачені візити. Вони роблять проблему реальною і конкретною.
3. Принеси ці цифри тому, хто ухвалює рішення, найкраще разом із користувачем у кімнаті і мовою власника: машини й гроші.
4. Попроси того, хто ухвалює рішення, про конкретне зобов'язання: оплату, передоплату чи хоча б дату наступного кроку.

Кожен крок потребує попереднього. Прохання про зобов'язання, поки власник не бачив цифр, зазвичай закінчується «я подумаю». А цифри, вигадані тобою замість цифр користувача, провокують «у нас усе не так».

Перша людина, яку зустрічаєш, корисна: вона часто відчуває проблему і знає цифри. Просто підписує рідко саме вона.