Как найти саппорт-систему за три месяца, если при себе нет 10 миллионов

Два года назад 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.

• Интеграция со всеми внутренними сервисами компании.

• Возможность создавать сквозные произвольные поля для обращений из разных мейлбоксов — чтобы не копировать раз за разом одно и то же поле в новые ящики.

Мы уместили  десятки требований для разных стран в один продукт, протестировали кучу решений, и сделали саппорт-систему за три месяца. Думаем, этот опыт будет полезен всем российским компаниям, которые выходят на международный рынок или планируют работать с международными сотрудниками.