Запитання просте. Для відповіді потрібні троє людей
Уявімо постачальника, який співпрацює з компаніями з кількома філіями. Закупівельник питає про строк замовлення, бухгалтерія просить документ, а працівник філії повідомляє про зміну адреси доставки. Усі листи надходять одному менеджерові, хоча кожен стосується іншої частини тієї самої справи.
Менеджер може відповісти, але спочатку шукає інформацію в системі й уточнює її у виконавців. Клієнт чекає не тому, що ситуація складна, а тому, що потрібна інформація — по інший бік телефонної лінії. Портал має усунути цю залежність, а не перекласти на клієнта роботу всієї команди.
Що зупиняє роботу?
Початкова ситуація
Дані доступні, але незрозумілі
Внутрішній статус «етап 4» не пояснює клієнтові, що відбувається із замовленням. Відображення необроблених даних з ERP саме по собі не створює якісного обслуговування.
Документ потрапляє не тій людині
В одній організації працюють закупівлі, бухгалтерія та філії. Спільний обліковий запис ускладнює контроль доступу й визначення того, хто погодив зміну.
Повідомлення без контексту
Звернення «будь ласка, виправте доставку» не вказує ні замовлення, ні потрібної зміни. Команда починає розмову із запитань, відповіді на які портал міг би вже знати.
Проєкт починається із запитань, які клієнт ставить найчастіше
Будуємо першу версію навколо кількох завдань: перевірити замовлення, завантажити документ, залишити примітку та знайти контактну особу. Кожен екран пояснює, що відомо, чого бракує та чи потрібно клієнтові щось зробити.
Отримуємо дані з визначеного джерела, а поруч зі статусом показуємо час оновлення. Якщо інтеграція тимчасово недоступна, портал прямо про це повідомляє. Стара інформація не видається за обіцянку актуального строку.
Так може виглядати новий процес
Запросіть потрібних людей
Обліковий запис належить конкретній людині та організації. Визначаємо, хто може запрошувати колег і які замовлення, філії та документи відкриває кожна роль.
Покажіть ситуацію мовою клієнта
Список замовлень показує впізнаваний номер, етап, строк і найближчу дію. Деталі пояснюють різницю між запланованим і підтвердженим строком та відображають історію змін.
Прив’яжіть документ до справи
Документи мають тип, дату й версію. Клієнт завантажує потрібний файл із замовлення, а не шукає його в загальному каталозі чи просить менеджера надіслати повторно.
Передайте запитання з повним контекстом
Звернення містить посилання на замовлення й тему. Внутрішня черга показує відповідального, а клієнт бачить підтвердження прийняття та подальші відповіді в одній розмові.
Доступ — це бізнес-правила, а не лише екран входу
Двоє людей, які користуються одним порталом, не повинні автоматично бачити однакові дані. Проєктуємо межі організацій, філій і ролей та перевіряємо права також на сервері. Запрошення нового користувача й відкликання доступу в людини, яка залишає компанію, є повноцінними елементами процесу, а не діями поза системою.
- Закупівельники можуть переглядати замовлення своєї організації.
- Бухгалтерія може мати доступ до розрахункових документів без права змінювати доставку.
- Адміністратор клієнта керує користувачами лише в погоджених межах.
Самообслуговування не повинно завершуватися глухим кутом
Іноді клієнтові потрібна термінова розмова, а іноді він не знаходить документ, бо справа ще не синхронізувалася. Тому екран без даних пояснює можливу причину та пропонує наступний крок. Сповіщення надсилаємо про важливі зміни, а не про кожну технічну операцію. На телефоні основні завдання доступні без прокручування широкої таблиці.
Почнімо з одного фрагмента, який працює.
Першим етапом може бути портал лише для перегляду для обраної групи клієнтів: замовлення, статуси й документи та форма звернення. Так перевіримо якість даних і зрозумілість інтерфейсу, перш ніж дозволяти зміни замовлень, індивідуальні прайси або самостійне оформлення. Для пілоту потрібні відповідальний з боку компанії та погоджена група користувачів.
Як зрозуміємо, що стало краще?
Це план вимірювання, а не обіцянка результату. Початкові показники визначаємо до впровадження.
Повторювані запитання до менеджера
Порівнюємо типи звернень до й після запуску порталу. Особливо перевіряємо запитання про статус і повторне надсилання документів, з урахуванням кількості активних замовлень.
Самостійне виконання завдання
Під час тестування спостерігаємо, чи може клієнт знайти конкретний документ і перевірити строк. Кількість створених облікових записів не показує корисності порталу.
Актуальність інформації
Контролюємо затримки синхронізації та випадки розбіжностей із системою-джерелом. Це важливіше за привабливу панель із даними, яким користувач не може довіряти.
Запитання, які варто поставити
Чи обов’язково портал B2B має бути інтернет-магазином?
Ні. Він може обслуговувати вже наявні замовлення та обмін документами. Кошик, оплату й каталог товарів додаємо тоді, коли вони відповідають способу співпраці з клієнтами, а не просто тому, що часто трапляються в системах B2B.
Чи потрібно клієнтові встановлювати застосунок?
Портал може працювати в браузері на комп’ютері й телефоні. Під час проєктування перевіряємо конкретні мобільні завдання, наприклад перевірку доставки або завантаження документа. Сповіщення й можливий режим застосунку добираємо відповідно до реальних потреб.
