Два года назад Kokoc Group вышел на международный рынок, а в этом году запустил новый продукт — многофункциональную платформу, предоставляющую широчайший спектр услуг диджитал маркетинга для развития бизнеса международных клиентов.
Перед запуском платформы передо мной как руководителем группы разработки и моей коллегой, руководителем отдела поддержки оставалась одна мелочь — организовать поддержку на разных языках (потому что далеко не все партнеры и коллеги за пределами РФ и СНГ знают английский и тем более русский). В процессе мы поняли, что эта самая «мелочь», на самом деле — огромный проект.
Меня зовут Михаил Кобзарев, руководитель группы разработки PHP в Kokoc Group, занимаюсь разработкой внутренних проектов и продуктов для группы компаний. У меня 20+ лет опыта работы в разработке, за которые я реализовал более 1000 проектов, а также участвовал в создании нескольких популярных стартапов.
Во-первых, понять, какую саппорт-систему хочется видеть
Как вы уже поняли, задачу по выбору саппорт-системы я решал не один. Поэтому в написании статьи мне помогала @bogdanna_number1 Анна Богданова, руководитель отдела поддержки Kokoc Group. У Ани более 18-ти лет опыта работы в сфере поддержки, как российских, так и международных команд. Первая часть статьи будет от ее лица.
Анна Богданова
Руководитель отдела поддержки Kokoc Group
Я четыре раза переходила на разные саппорт-системы, в том числе международные, и понимала, что должно быть в идеальной системе. Поэтому перед стартом проекта выделила время, села и расписала все бизнес-требования.
Список получился таким:
опенсорс — если сами захотим что-то дописать или исправить;
хранение пользовательских данных на нашем сервере — ради безопасности и, чтобы не страдать с выгрузкой при переезде на другую систему (да и по закону персональные данные мы обязаны хранить на серверах, размещенных в России);
поддержка популярных языков: русского, английского, испанского, немецкого, индонезийского и так далее;
удобная и понятная аналитика — чтобы контролировать работу системы и не мучиться с поиском и чтением данных;
возможность выгружать статистику в XLS, потому что, как ни крути, с XLS ничто не сравнится;
наличие мобильной версии — чтобы была возможность организовать поддержку 24Х7 и дежурные сотрудники могли работать с телефона и не срывались к ноутбуку;
интеграция с телефонией и почтой — инструменты из категории old fashioned, но вполне рабочие;
все обращения по всем каналам внутри одного окна, чтобы не переключаться между клиентским порталом, почтой, чатом на сайте, чатом в Telegram— требование, казалось бы, простое, но не во всех системах оно есть;
возможность работать нескольким уровням поддержки в одной системе: отделу поддержки конечных клиентов, отделу поддержки пользователей, отделу эксплуатации, технической поддержке, международной поддержке, админам;
интеграция с телефонией, чтобы была возможность отслеживать и записывать звонки;
готовые интеграции с баг-трекинговыми системами — потому что нам надо в режиме реального времени видеть, что делают наши разработчики (в jira например);
интеграция с CRM-системами и справочниками или хотя бы API для такой интеграции — чтобы сразу загружать, выгружать и обновлять данные клиентов и базу знаний и автоматически (и потому что я не представляю, как без них сейчас вообще работать поддержке);
сервис массового оповещения или рассылок — чтобы быстро сообщать о сбоях и плановых работах;
возможность работать со статусами заявок;
внутренняя система оценки обращений и для клиентов, и для внутренних пользователей;
возможность взаимодействовать со смежными подразделениями, например, с кадрами, потому что далеко не все тикеты касаются техподдержки, и мы не хотим их терять или тратить время на передачу информации.
Во-вторых, найти вендора, когда никто не хочет сотрудничать
Мы решили взять этот список требований и пройтись с ним по всем саппорт-системам, которые хорошо зарекомендовали себя на рынке (взяли, конечно же, правый верхний квадрат из квадранта Гарнера).
Но когда я начала обращаться в международные компании с предложением «продайте нам систему», поняла, что никто не хочет сотрудничать. Даже если звонишь с немецкого номера, говоришь по-английски, а компания зарегистрирована на Кипре. Остаются три варианта:
Международные сервисы через Индию с наценкой Х2 и индийской поддержкой.
Российские сервисы, у большинства из которых нет поддержки иностранных языков и возможности работать с российской и международной базой одновременно. К тому же большинство местных продуктов довольно молодые (хотя и классные), и там пока просто нет большинства нужных нам функций.
Опенсорс-решения.
Можно еще полностью написать систему самим — со всеми нужными языками и интересными фишечками, но займет такая работа минимум год. И стоить будет ХХ-миллионов.
Ожидаемо, выбор пал на опенсорс-системы. Больше всего пунктов по нашим критериям набрала FreeScout. К тому же, у нее множество модулей, которые можно докупить для кастомизации системы (стоят они 2–15 долларов) и неограниченное количество лицензий.
Последнему я сначала не поверила, потому что по подсчету получалось в десятки раз дешевле, чем крупная саппорт-система (по моим подсчетам выходило 10–50 тысяч долларов) и ждала, что мы будем платить за каждую лицензию при покупке модуля. Но нет — все модули обошлись в 500 долларов и просьбу добровольно, по возможности поделиться с автором проекта своими наработками и замечаниями (как сказал мой коллега: «Коммунизм в чистом виде»).
В процессе мы поняли, что модулей не хватает, и у компании есть индивидуальные запросы. Но согласитесь, проще корректировать готовый продукт, чем писать новый с нуля. О том, как эти корректировки происходили, расскажет уже Михаил.
В-третьих, договориться насчет доработок (если получится)
И снова привет, я продолжаю уже рассказ от своего имени и с точки зрения разработки.
Когда ребята рассказали, что и как хотят сделать в своей службе техподдержки, то сомнений в том, что им нужен именно FreeScout, не осталось. Потому что ни одно из существующих платных SaaS-решений не удовлетворило бы все их запросы: настройку системы отчетности, гибкий поиск информации, подключение модулей, наличие базы знаний, календаря, менеджера файлов и других инструментов из коробки.
У меня был опыт внедрения этого сервиса в несколько российских интернет-проектов и написания простых модулей, поэтому я с радостью согласился помочь коллегам.
Мы развернули тестовое окружение, подняли на нём копию FreeScout, настроили CI/CD и принялись внедрять фичи, которые были в бэклоге: новые статусы, новые таблицы, более красивый интерфейс и так далее.
Но буквально через неделю после начала разработки мы поняли, что для решения задач, нужно изменить некоторые файлы ядра. Все потому, что в них нашлись критичные ошибки и попросту отсутствовала возможность расширения — а стандартных хуков: событий и фильтров — просто не хватало (привет, WordPress).
Простой пример. Нам нужна была система оценки всего диалога клиента с техподдержкой. Но модуль FreeScout позволяет оценивать только конкретное сообщение. Поэтому мы залезли в ядро и дописали нужную функцию.
Вот пара вещей, которые мы нашли:
система НЕ умеет работать на нескольких языках одновременно (интерфейс можно переключить на другой язык, переводы есть не для всех модулей, а содержимое и настройки вообще могут быть только на одном языке);
система НЕ умеет работать на нескольких доменах одновременно, а для нас это было критично, так как поддержка должна работать в разных странах;
система НЕ умеет делать красивые URL для пользовательских порталов, а генерит вот такие не красивые ссылки: https://example.com/help/2576029897/ticket/1021
Недолго думая, мы связались с автором проекта и предложили помочь : исправить ошибки и написать несколько интересных фич (те же новые статусы и модуль оценки). Автор порекомендовал нам завести issue на GitHub и ждать. Правки копились, он все не отвечал на наши запросы и, в конце концов, написал, что это не баги, а фичи, PR от нас он принимать не станет и удалил issue.
И, наконец, дописать систему
Мы не стали унывать, форкнули проект и продолжили разработку. К счастью. лицензия AGPL-3.0 позволяет изменять исходный код ядра и купленных модулей, чем мы незамедлительно и воспользовались.
Частично закрыли потребности при помощи официальных модулей:
Custom fields — произвольные поля для обращений;
API and Webhooks — API для интеграции с внешними сервисами;
Live Chat — виджет чата;
OAuth & Social Login — вход через соцсети;
Satisfaction Ratings — оценка агентов клиентами;
End-User Portal — портал для клиентов;
Teams — команды агентов;
Custom Folders — произвольные папки для обращений;
User Fields — произвольные поля для агентов;
Tags — теги;
Ticket Number — номера обращений в письмах и формах;
Jira — интеграция с Jira;
CRM — управление клиентами;
Mentions — упоминания;
Reports — отчеты по агентам и обращениям;
Kanban — конструктор канбан-досок.
Над остальными функциями пришлось поработать дольше: дописывать имеющееся или вовсе делать с нуля. Пример такого модуля — интеграция с нашим HR-сервисом. Благодаря ей мы автоматически определяем сотрудника, который обратился в поддержку: имя, фамилию, страну, регион, бизнес-юнит, телефон и другие данные, которые есть в HR-системе. И так упрощаем работу агентам — теперь им не приходится выяснять, что за человек обратился за помощью.
На каждый модуль уходило разное время: от 10 минут до нескольких дней — в зависимости от объема работы. Интеграция проводится просто: выгружаем zip-архив, добавляем в админку и спокойно пользуемся.
Что мы получили на выходе после трех месяцев разработки
Кроссбраузерное и кроссплатформенное приложение для служб технической поддержки как внутренней, так и клиентской;
Возможность работать на нескольких языках с неограниченным количеством доменных имен разграничением на уровне мейлбоксов.
Возможность переводить с одного языка на другой через панель администратора.
Возможность работать одновременно на нескольких доменах.
Удобный виджет для встраивания на сайты.
Полную интеграцию с Telegram.
Интеграция со всеми внутренними сервисами компании.
Возможность создавать сквозные произвольные поля для обращений из разных мейлбоксов — чтобы не копировать раз за разом одно и то же поле в новые ящики.
Мы уместили десятки требований для разных стран в один продукт, протестировали кучу решений, и сделали саппорт-систему за три месяца. Думаем, этот опыт будет полезен всем российским компаниям, которые выходят на международный рынок или планируют работать с международными сотрудниками.
Комментарии (7)
Zivaka
11.10.2024 11:54Когда нашел Freescout много лет назад, установил и начал использовать в компании, то долго не мог понять, в чем же подвох. Все аналоги по функционалу в тот момент были примерно такие же, однако лицензии на небольшую компанию выходили от 10-15 тысяч в месяц. Вопросы к программе иногда возникают, но по мелочи, глобально - работает отлично!
mihdan Автор
11.10.2024 11:54Кроме Laravel 5.5 особых подвохов мы не наблюдаем, код написан сносно, кастомизируется просто и понятно, API вполне юзабелен - а что еще надо от опенсорс проекта?
Zivaka
11.10.2024 11:54При этом, мы не кастомизировали, так устанавливаем выходящие время от времени обновления, да и модули разные тоже приобретали.
a3or
11.10.2024 11:54Можете раскрыть тему хранения ПДн?
У вас ПДн только российских граждан хранятся на серверах в РФ?
Другие страны не предъявляют аналогичных требований для ПДн своих граждан?
Если другие страны предъявляют аналогичное требование, то как решается вопрос?
paganez
Freescout - классный бесплатный хелпдеск, но Laravel 5.5.... Есть ли у вас в планах обновить в этой системе лару до последней версии?