Платформа клієнтського обслуговування для регіонального сервісного бренду

Клієнт обслуговував перші сто своїх клієнтів зі спільної поштової скриньки, маркетингового сайту, теки з договорами в Google Drive і таблиці Excel, у якій вели статуси. Така схема працювала. Наступна сотня клієнтів її зламала.

На момент нашого старту троє різних співробітників підтримували три трохи різні версії "правди" про відкриті заявки. Листи від клієнтів губилися між поштою й таблицею. Договори жили в теці Drive зі структурою, яку формував той, хто останнім завантажував файл. Власний бекенд, що зв'язував частину цього докупи, написав підрядник, з яким уже не вдавалося зв'язатися, і ніхто з нинішньої команди коду не читав.

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

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

Публічний сайт — це маркетингова поверхня: серверний рендеринг для SEO, i18n там, де бізнес реально працює більш ніж однією мовою, без клієнтського JavaScript там, де достатньо серверної відповіді. Це найдешевша в експлуатації частина системи і перше, що бачить клієнт, тому саме сюди йде бюджет на полірування.

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

Внутрішня адмінка — це back-office інструмент, розширений там, де розширення виправдане: користувальницькі списки з тими фільтрами, які команда справді застосовує, інлайн-дії для сортування й призначення, гілки коментарів на кожній заявці, заплановані роботи, прив'язані до картки клієнта, звіти, які співробітники витягують самі, не звертаючись до нас. Ми не будували окремий "операційний дашборд" як застосунок. Внутрішня адмінка, яку сприймали як повноцінну продуктову поверхню, закрила дев'яносто відсотків потреб команди.

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

Автентифікація сесійна і для команди, і для клієнтів — без токенів, що ходять навколо, без SaaS-постачальника автентифікації. Рольовий доступ розрізняє ролі команди (адмін, редактор, переглядач) і клієнта (власник акаунта, делегований користувач). Кожна дія, що змінює стан, записується в журнал аудиту з прив'язкою до користувача й заявки і доступна для запитів з адмінки. Пошук іде через повнотекстові індекси бази даних по всій історії клієнта, з обмеженням за роллю.

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

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

Що ми свідомо відкинули

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

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

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

Ми не будували аналітичних дашбордів понад ту півдюжину звітів, які команда реально використовувала з першого дня. Дашборди легко додати пізніше поверх чистих даних. Дашборди поверх брудних даних — змарнована робота.

Передавання

Клієнт володіє кодом, інфраструктурою, runbooks і конвеєром розгортання. Репозиторій — їхній, кластер бази даних — у їхньому хмарному акаунті, домен — у їхнього реєстратора. Ми залишили письмову інструкцію реагування для чергового інженера, документ архітектури, що описує кожне ухвалене рішення, і беклог того, що ми свідомо відклали. Жодної прив'язки до постачальника. Жодного обов'язкового місячного ретейнера, щоб система працювала.

Якщо вони захочуть повернутися до нас за наступним обсягом — двері відчинені. Якщо захочуть вести далі самотужки, систему збудовано так, щоб її міг читати інженер, який її не писав. Саме таке було завдання.