Повернення губляться в листуванні й таблицях? Як CRM веде заявку на повернення від звернення до рішення — зі статусами, строками й історією.
Клієнт пише, що товар не підійшов або прийшов із браком, і хоче повернути кошти. Менеджер записав це в блокнот чи в листування, пообіцяв «розібратися» — і закрутилося: товар їде назад, але до якого замовлення він належить, уже з'ясовують вручну; кошти повернули чи ні, ніхто точно не пам'ятає; клієнт телефонує втретє й питає статус. Коли повернення живуть у месенджерах і таблицях, кожне з них — маленьке джерело хаосу й невдоволених клієнтів.
Повернення й рекламації в CRM — це коли повернення ведеться як окремий процес зі статусами: заявка, перевірка, рішення — і вся історія прив'язана до замовлення й картки клієнта. Розберемо, як це влаштовано й де проходять чесні межі.
Чому повернення не можна пускати на самоплив
Повернення — це момент, коли клієнт уже незадоволений або передумав. Від того, наскільки швидко й акуратно ви його обробите, часто залежить, чи лишиться клієнт із вами взагалі. А без системи стається протилежне:
- заявка на повернення губиться в листуванні й месенджерах;
- незрозуміло, на якому етапі повернення: прийняли, перевіряють, повернули кошти?;
- товар прийшов назад, а до якого замовлення він належить — з'ясовують вручну;
- причини повернень ніхто не рахує, і ті самі проблеми повторюються.
Важливо пам'ятати: повернення — це ще не втрачений клієнт. А от погано оброблене повернення — майже напевно втрачений, та ще й із поганим відгуком.
Повернення як процес: заявка → перевірка → рішення
Сенс — перетворити повернення з хаосу на зрозумілий ланцюг статусів, де на кожному кроці ясно, що відбувається:
- Заявка. Клієнт або менеджер створює заявку на повернення, прив'язану до конкретного замовлення.
- Перевірка. Оцінюють товар і причину: брак, не підійшло, передумав, пересорт.
- Рішення. За вашою політикою — повернути кошти, замінити товар або обґрунтовано відмовити.
- Закрито. Результат і вся історія лишаються в картці клієнта.
На кожному кроці видно статус і строк, тому ні сама заявка, ні час відповіді не губляться. Клієнт отримує передбачуваність, а ви — контроль над процесом.
Що фіксується по кожному поверненню
Щоб поверненнями можна було керувати, а не просто «розрулювати» їх по одному, по кожному фіксують кілька речей:
- причину — брак, не підійшов розмір, передумав, привезли не те;
- товар і замовлення, до якого належить повернення;
- рішення і хто його ухвалив;
- строки — коли прийняли заявку, коли вирішили, коли повернули кошти або замінили.
Із цього народжується аналітика причин. Якщо по конкретному товару повернення йдуть потоком, це сигнал: проблема в самому товарі, його описі або пакуванні при доставці. Без обліку такі закономірності просто не видно.
Повернення прив'язане до замовлення й клієнта
Головна цінність — повернення не висить окремим папірцем у когось у пошті, а прив'язане до замовлення й картки клієнта. Видно всю історію: що людина купила, що повернула, з якої причини й чим усе закінчилося.
Це зручно всім сторонам. Менеджер відповідає клієнту предметно — «ваше повернення на перевірці, рішення до п'ятниці», — а не «зараз уточню й передзвоню». Керівник бачить по клієнтах і товарах, де й чому йдуть кошти. А сам клієнт відчуває, що його питання не загубилося, — і це прямо впливає на те, чи повернеться він за наступною покупкою.
Шлях повернення: заявка → перевірка → рішення
Найпростіше побачити логіку на схемі. Зліва направо йде ланцюг: заявка на повернення, перевірка товару й причини, рішення. А рішення веде до одного з трьох результатів — повернути кошти, замінити товар або відмовити за правилами.
Ключове тут — передбачуваність. Хай яким буде результат, він не «зависає в повітрі», а фіксується як статус, зрозумілий і менеджеру, і клієнту.
Без системи vs повернення й рекламації в CRM
| Аспект | Вручну | У CRM |
|---|---|---|
| Заявка на повернення | у листуванні, легко втратити | окрема заявка, прив'язана до замовлення |
| Статус обробки | «десь на етапі» | видно: прийнято, перевірка, вирішено |
| Причина повернення | ніде не фіксується | записана, є аналітика причин |
| Рішення і строк | по пам'яті | зафіксовані, хто й коли |
| Зв'язок із замовленням | з'ясовують вручну | повернення прив'язане до замовлення й клієнта |
| Повторювані проблеми | непомітні | видно по частих причинах |
Де межі: рішення завжди за компанією
Облік повернень упорядковує процес, але в нього є чіткі рамки, про які чесно сказати важливо.
- Повернення регулюються законом. Права споживача, строки повернення й гарантії визначає закон і ваша політика. CRM веде облік, статуси й строки, але не визначає за вас правомірність конкретного повернення.
- CRM не схвалює й не відхиляє сама. Вона фіксує рішення людини й тримає процес прозорим. Наскільки жорсткими чи м'якими будуть правила — вирішує бізнес.
- Строки й гарантії задаєте не ви й не система, а закон і договір. CRM лише нагадує про строки, щоб їх не пропустити.
- Користь є там, де процес ведуть. Якщо заявки не заводити, аналітики й порядку не буде — система не замінює дисципліну, а підтримує її.
Під ваші правила повернень
У кожного бізнесу своя політика повернень: які причини приймаються, у які строки, що можна замінити, а що ні, як оформлюється брак і гарантія. Готові коробкові рішення рідко враховують ці нюанси — зазвичай це або загальний «тикет», або нічого. Тому процес повернень має сенс налаштовувати під ваші правила: під ваші причини, статуси й рішення.
По суті повернення — це окремий випадок звернення клієнта, тільки з рухом товару й грошей; як улаштована загальна робота зі зверненнями, ми розбирали в матеріалі про сервіс і обробку звернень. А фізично товар повертається тією ж логістикою, що й від'їжджав, — про оформлення відправлень і відстеження ми писали в статті про кур'єрську доставку і ТТН у CRM.
Перш ніж вибудовувати процес повернень, корисно прикинути, у скільки обходиться клієнт, якого ви втрачаєте через погано оброблене повернення і який більше не повернеться — калькулятор утримання клієнтів допоможе побачити цю цифру.
Часті запитання
Навіщо вести повернення в CRM, а не в таблиці чи листуванні?
Щоб повернення не губилося й був видно його статус: прийнято, перевірка, рішення. У CRM заявка прив'язана до замовлення й клієнта, фіксуються причина, рішення та строки, а по частих причинах видно аналітику.
Які статуси проходить заявка на повернення?
Зазвичай це ланцюг: заявка → перевірка товару й причини → рішення (повернути кошти, замінити товар або відмовити) → закрито. Конкретний набір статусів налаштовується під вашу політику повернень.
Що фіксується по кожному поверненню?
Причина повернення, товар і замовлення, до якого воно належить, ухвалене рішення і хто його ухвалив, а також строки — коли прийняли заявку, коли вирішили й коли повернули кошти або замінили товар.
Чи вирішує CRM, схвалювати повернення?
Ні. Правомірність повернення визначає закон і ваша політика, а рішення ухвалює людина. CRM лише фіксує це рішення, веде статуси й нагадує про строки, роблячи процес прозорим.
Чим повернення відрізняється від звичайного звернення?
Повернення — це звернення з рухом товару й грошей: треба прийняти товар назад і повернути кошти або замінити його. Тому в нього окремий процес зі своїми статусами й рішеннями, а не просто відповідь на питання.
Повернення й рекламації перетворилися на хаос із листування й таблиць? Розкажіть про свої правила повернень — запропонуємо, як вибудувати процес повернень і рекламацій саме під вашу модель роботи.
