Розробка на замовлення

CRM для маркетплейсів фрилансерів

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

Обговорити розробку CRM Можливості

Чому підтримці складно відновити історію угоди

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

Профілі сторін і ведення звернень за замовленням

Ці модулі можна закласти в проєкт. Склад і правила роботи погодимо після розбору ваших процесів.

Замовлення, звернення та суперечка

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

Приймання результату

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

Звернення за повторною угодою

Повторне замовлення має власний номер, умови й звернення. За потреби оператор може перейти до пов’язаної попередньої угоди за наданим доступом.

Що ще можна передбачити

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

Приклади роботи з CRM

Як можуть працювати ролі та винятки після впровадження.

Звернення щодо проміжного етапу

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

Супровід повторного клієнта

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

Що закласти в першу версію

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

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

Обговорити перший етап

Запитання до розробки

Як об’єднати звернення обох сторін?

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

Чи зможемо вважати повернення коштів завершеним після рішення?

Рішення й платіжний статус варто вести окремо. Остаточне підтвердження залежить від можливостей обміну даними з платіжним сервісом.

Як перенести відкриті звернення за угодами з чинного маркетплейсу?

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

Яка частина маркетплейсу входить до першої версії CRM?

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

Обговорімо вашу CRM

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