Менеджер у дзвінку каже, що передзвонить у четвер. Клієнт записує собі цей день і чекає. Наступного ранку в картці угоди видно, що дзвінок відбувся: є тривалість, є відповідальний, активність позначена як завершена. Але задачі на четвер немає, тож у робочому списку цей контакт ні в кого не стоїть.

У п’ятницю клієнт або звертається до іншої компанії, або пише, що йому ж обіцяли передзвонити вчора. Керівник відділу продажів побачить тишу в угоді пізніше, коли дивитиметься воронку, і вже тоді почне з’ясовувати, чому все зупинилося. Запис підтвердить лише те, що розмова завершилася, але не покаже, що компанія ще мала виконати обіцянку.

Те саме трапляється в листуванні. Менеджер пише, що сьогодні надішле комерційну пропозицію, або що перевірить залишки й повернеться з відповіддю. Діалог виглядає закритим, бо останнє повідомлення відправила компанія. У картці угоди немає файлу, з пошти нічого не пшло, а задач або немає, або вони стоять на наступний тиждень на людині, яка не брала участі в листуванні. CRM зберегла завершену комунікацію, але не зафіксувала зобов’язання.

Коли керівник помічає таку закономірність, компанія часто купує не те, що потрібно: чат на сайті або інструмент, який відповідає відвідувачам до підключення менеджера. Але тут бракує не ще одного каналу спілкування. Обіцянка, дана конкретній людині, живе поза всіма списками, за якими працює компанія, рівно до того моменту, поки її не перенесуть у задачу. У цьому матеріалі про те, як перенести її так, щоб в обіцянки з’явився відповідальний і видима дата, і про тиждень, який показує, чи працює такий перенос.

1. Де обіцянка насправді втрачається

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

З комерційною пропозицією або перевіркою залишків збій виглядає інакше, але влаштований так само. Менеджер пише, що надішле пропозицію сьогодні, листування закривається, а в картці немає ні файлу, ні ознаки відправленого листа. Або менеджер обіцяє повернутися з відповіддю сьогодні, а задача в CRM стоїть на наступний понеділок. Для системи все ніби гаразд: задача існує. Для клієнта вона вже запізнилася в ту секунду, коли менеджер назвав інший термін.

Задача може існувати й водночас нічого не тримати. Вона висить у черзі без відповідального або стоїть на людині, якої не було в розмові. Або в неї є відповідальний, але немає терміну. Обіцянка без терміну не може запізнитися: порівнювати фразу нема з чим, тому срив усередині компанії невидимий. Клієнт пам’ятає четвер. У компанії в руках картка, яка формально в строк, бо ніхто не записав день.

Хто чує, коли обіцянка горить, це третя точка втрати. Покупець єдина людина, яка тримає обіцянку і її срив одночасно. Усередині компанії першим це бачить, як правило, керівник відділу продажів, який відкриває мовчазну угоду через тиждень, або підтримка, що читає злісного листа. Вибірковий контроль теж не ловить цей випадок: коли керівник слухає записи заради якості спілкування, він чує, чи був менеджер ввічливим, але ввічливість не створює термін. Як обирати, які записи варто перевіряти глибше, розказано окремо в матеріалі як перевіряти якість дзвінків, не слухаючи кожен запис. Тут обіцянка вже має слова й час, і питання лише в тому, чи є задача, яка їм відповідає.

2. Що має бути записано, щоб обіцянка існувала

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

Форма в CRM навмисно нудна. Задача з назвою-дією, наприклад «Передзвонити». Термін дорівнює дню, який менеджер назвав клієнту. Відповідальним стає сам менеджер, якщо пізніше людина не записала іншого відповідального з причиною. Ім’я клієнта, телефон і обіцяний день переносяться на задачу з дзвінка або листування, і робить це фонове завдання після збереження розмови. Якщо обіцянка стосувалася комерційної пропозиції, перевірка файл не вигадує і лист не пише замість менеджера. Вона лише показує, що файлу або відправленого листа бракує.

Обіцянка без дати в цей підрахунок не потрапляє. Фраза «будемо на зв’язку» розбирається в коучингу, а не в звіті: вирішує людина, чи це була просто ввічливе завершення розмови, чи єдиний наступний крок, який почув клієнт. Виняток оформлюється так само: ім’я і причина поруч із рядком. Поки такого запису немає, перевірка продовжує показувати розбіжність. І вона не вчиться ігнорувати всі майбутні четверги, бо мовчазний виняток і є тим способом, яким наступний реальний срив ховається під тим самим ярликом.

3. Що показує перевірка і що керівник відкриває вранці

Перевірка запускається після розмови, в картці угоди, яка вже існує. Вона читає розшифровку, короткий підсумок або листування, витягує обіцяну дію, термін і того, хто на неї погодився. Далі дивиться в CRM: чи є задача, чи збігається її термін із днем, який почув клієнт, чи стоїть відповідальним та сама людина, а для комерційної пропозиції чи є файл у картці або відправлений лист. Збіг лишається без рядка. Чотирьох типів розбіжностей для старту досить: немає задачі, термін пізніший за обіцяний, не той відповідальний, пропозиція без файлу і без відправлення.

Ранковий список відсортований за обіцянкою, а не за менеджером. Згори стоїть обіцянка, чий день настав без зміни статусу: вона горить, а клієнт ще не поскаржився. Під нею лежать учорашні розбіжності. Керівник читає рядки однієї людини, відкриває дві картки і або ставить задачу, або позначає рядок як необіцянку. Формат лишається простим: ім’я менеджера, угода, фраза і те, чого бракує. Один бал без речення майже завершується суперечкою про методику замість задачі на п’ятницю.

Це не чат-бот і не модель на сайті. Така перевірка не веде розмову за менеджера, не пропонує знижку і не створює новий канал комунікації. Вона порівнює вже виконану роботу з тими задачами, які вже мали з’явитися в CRM. Кроки скрипту й обов’язкові поля перевіряє інший тип контролю: перевірка скрипту й обов’язкових полів після зв’язки телефонії з CRM. Їх краще не змішувати. У картці можуть бути заповнені всі обов’язкові поля, але задача на передзвін так і не буде створена.

4. Що все одно лишається за людиною

Рядок у списку ще не означає провини менеджера. Людина, яка знає контекст угоди, має вирішити, чи справді це пропуск. Керівник відкриває саме цю хвилину запису або це повідомлення в листуванні й або створює задачу, або позначає, що це не була обіцянка.

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

Сам дзвінок клієнту теж лишається за людиною. Список може показати, що менеджер назвав четвер, але задачі немає. Він не має сам телефонувати замість менеджера і не повинен писати клієнту в чужому стилі. Коучинг також проводить керівник, коли в нього відкрита розшифровка дзвінка або листування, а не тільки цифра в таблиці. Якщо прив’язати мотивацію до сирої кількості рядків, команда дуже швидко навчиться уникати конкретних дат у розмові, а не краще виконувати обіцянки. Тоді обіцянки повернуться взагалі без дат.

5. Один відділ, один канал, один тиждень

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

На старті достатньо трьох чисел. Скільки явних обіцянок знайшла перевірка. Скільки з них були без задачі. Скільки невідповідностей керівник підтвердив як реальні пропуски після того, як відкрив дзвінок або листування. І ще одне питання тижню: чи показала перевірка обіцянку, чий день настав раніше за скаргу клієнта? Якщо керівник майже нічого не підтверджує, правила, найімовірніше, ловлять ввічливі формулювання замість справжніх зобов’язань. Тоді список звужують, поки втомлена людина не зможе перевірити кожен рядок приблизно за хвилину.

Не варто виводити цю перевірку на всі команди вже наступного понеділка. Так само не треба підключати другий канал, доки команда не може спокійно пояснити ці три числа без суперечки про формулювання. Рейтинг тримаємо осторонь від цього тижня: команда почне сперечатися про бали, поки задача на четвер усе ще не створена.

Коли варто підключати допомогу

Такі правила команда може описати й сама вже цього тижня, якщо менеджери звично називають наступний крок, а в CRM уже є задачі з термінами та відповідальними. Допомога потрібна тоді, коли розшифровка дзвінка або листування живе в одному інструменті, а картка угоди й задачі в іншому, і ніхто ще не зводив одну обіцянку з однією задачею в одному місці. Або якщо попередній інструмент давав лише оцінку без зрозумілого рядка, чи якщо результат має потрапляти в картку угоди так, щоб не заважати менеджеру працювати.

Послуги охоплюють саме таку зв’язку: від розшифровки дзвінка або листування і списку задач до короткого щоденного списку, який керівник фільтрує за менеджером і днем. У розділі Обрані роботи є подібні перевірки виконання як робочий механізм, а не як гасло. Обіцяний зворотній дзвінок так і не став задачею, і цю прогалину бере на себе послуга автоматизації заявок у CRM. Якщо хочете прогнати перший тиждень на своїх дзвінках, напишіть мені: вкажіть канал, де зберігається розшифровка або листування, і де створюються задачі. Імена клієнтів, телефони та записи краще не надсилати в першому повідомленні.