Бот-менеджер: продажі й сервісні питання, коли менеджерів немає на зміні

Магазин працює цілодобово, а відділ продажів - ні. Замовлення, яке людина зробила о 23:40, лежить до ранку. Клієнт, який у неділю ввечері хоче спитати, де його посилка, не отримує відповіді до понеділка.

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

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

Проблема: у чат-бота продажів дві різні смерті

Перша смерть - бот, який нічого не знає. Він вітається, задає три питання і передає діалог людині. Клієнт витратив час і не отримав нічого, чого не отримав би з форми на сайті.

Друга смерть страшніша. Бот, побудований навколо мовної моделі без обмежень, впевнено називає ціну, якої немає, обіцяє наявність товару, якого немає на складі, і домовляється про доставку, якої не буде. Кожна така відповідь - це не просто помилка, це зобовʼязання магазину перед клієнтом.

Є ще третя тонкість, специфічна для цього клієнта: у нього два магазини зі спільним виробництвом, і клієнт може мати покупки в обох. Показати в одному діалозі покупки з двох магазинів - це не зручність, це розкриття інформації, яку власники не оприлюднюють.

Як автоматизація це вирішує

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

Ключова ідея: модель не має права вигадати число

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

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

Що лишається людині

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

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

Що це дало бізнесу

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

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

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

Як це влаштовано всередині

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

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

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

Відкат одним прапорцем. Ядро вмикається перемикачем. Якщо воно не відповіло, апдейт іде попередньому коду - клієнт цього не помічає.

Кому це підходить

Магазинам, де є жива обробка замовлень людьми і є трафік поза графіком роботи: вечори, ночі, вихідні, сезонні піки. І тим, у кого частина клієнтів принципово не хоче говорити по телефону.

Як зрозуміти, що це про вас: подивіться, скільки замовлень і питань приходить після 19:00 і у вихідні, і помножте на середній чек. Це і є ціна тиші.

Бот не мусить бути розумнішим за менеджера. Він мусить ніколи не вигадувати те, чого немає в системі.