Когда команда Quickme работала над прототипом модуля Поддержки (клиентов, пользователей), то для обсуждения было предложено два пути развития продукта — или это будет сложный инструмент, который соответствует требованиям ITIL, ГОСТ, ISO в рамках канонов работы сервисных компаний, либо инструмент будет простым, но при этом закрывающим базовые потребности службы поддержки — нам захотелось свободы. Что из этого получилось и почему я постараюсь рассказать сегодня. Да, моя серия статей о SaaS закончена и статья посвящена исключительно продукту компании и нашей картине мира.
Минимализм в реализации сервиса не значит плохо
Итак, командой проекта было принято решение создавать простой сервис, как и большинство сервисов SaaS (примеры из новых сервисов Dental Cloud, Nova CRM). Главным аргументом в пользу выбора сценария создания простого сервиса стал фактор наследственности — наша почтовое решение минималистично c точки зрения юзабилити (но полное по функционалу) и мы не хотели перегружать лишним следующие модули Quickme.
Далее, мы руководствовались следующей логикой и идеологией — наш потенциальный клиент компании малого и среднего бизнеса. Первые не иерархичны, у них пока небольшие команды и нет необходимости организации и реализации сложных бизнес-процессов, т.е. структура компании не предполагает жесткой привязки к сценарию распределения заявок между сотрудниками, контроля исполнения (клиентов пока мало), жесткого распределения прав доступа (все Ок). Т.е. у потенциального клиента нет потребностей в чем-то лишнем, и как следствие мы не стали реализовывать описанные выше сценарии и ограничились следующим:
— Общим чатом, в который поступают «все заявки от всех клиентов». Такой подход разумен, когда в компании небольшой штат и специалисты обладают разным уровнем компетенций (я могу помочь/мне меня могут дополнить).
— Отсутствием в сервисе распределения прав доступа — в небольшом коллективе, на наш взгляд, руководство может оценивать коллег, общаясь лично и степень доверия к сотруднику в небольших коллективах обычно высока.
— Отсутствием иерархий «руководитель-исполнитель». В нашей концепции все сотрудники видят заявку (вопрос) в общем чате и все могут на него ответить, помогая друг-другу.
— Мы не реализовывали систему отчетности и историй общения с клиентами по причине того, что она не нужна в небольших объемах запросов от клиентов.
— Основной акцент в позиционировании сервиса был в разноуровневых коммуникациях между компанией и клиентом и мы сделали это отлично и дали клиентам возможность получать заявки через форму на сайте, по электронной почте, через личный кабинет пользователя, т.е. задачу минимум мы решили на отлично.
Легкий интерфейс Q.Поддержка.
Что получилось после реализации концепции
В итоге в Quickme.Поддержка реализовано:
— единое пространство получения заявок и работы с ними — все сотрудники компании могут обрабатывать внешние и внутренние заявки сотрудников компании;
— формирование (заполнение) заявки через внешнюю форму, размещенную на сайте компании;
— работа клиента компании с подразделением поддержки через личный кабинет;
— отправка внешних заявок на выделенный адрес электронной почты;
— отсутствие настройки прав доступа для сотрудников компании;
— оповещение о поступившей заявке на адрес электронной почты специалиста;
— обработка заявок в режиме группового чата;
В целом задача решена — мы реализовали коммуникации компания-клиент и адаптировали сервис для сегмента наших потенциальных клиентов. Клиент получает — низкую стоимость решения, сокращение времени на обучение сотрудников, быстрые запуск и начало использования сервиса.
Отправка заявки от клиента через форму на сайте
Стоит ли повторять подход?
Это зависит от того в какой области автоматизации бизнеса вы работаете и на сколько далеко вы готовы зайти, развивая функциональность SaaS. «Простотой» точно не стоит увлекаться разработчикам учетных систем, в которых нужно выполнять нормативные предписания. В коллаборативных системах мы уже видим простоту — ASANA. Аналогичный подход минимализма и простоты мои коллеги попробовали применить еще в одном вертикальном SaaS решении Dental-Cloud и надеемся, что сервис не нужно будет развивать семимильными шагами и он стане оптимальным инструментом для выбранного сегмента — стоматологические кабинеты.
Алексей Калачников / серия статей о SaaS
Автор: EvseyFaydo
