Привет! Меня зовут Нарек Маркосян и я backend-разработчик в компании «Ситимобил». Хочу рассказать вам о нашем закрытом Телеграм-боте «Тайный покупатель».
В Ситимобил никто не носит розовых очков, мы хорошо понимаем, что наш сервис не идеален, поэтому мы всегда работаем над его улучшением. Проблемы клиентов могут быть связаны с приложением, с расчетом цены, но чаще всего — с водителем.
Мы любим своих водителей и стараемся сделать их работу более приятной и прибыльной, но из-за одного недобросовестного водителя мы можем потерять несколько клиентов и тем самым лишить заработка водителей, которые честно делают свою работу.
По этой причине мы решили разработать инструмент для быстрого реагирования на жалобы, связанные с водителями.
Абсолютно все жалобы наших клиентов рассматриваются работниками отдела поддержки, но полностью полагаться на статистику, полученную от клиентов мы не можем по несколькольким причинам:
Так что же делать? Попросить наших коллег помочь!
Конечно, при возникновении проблем всегда можно позвонить в диспетчерскую и обойтись без посредников, но бот помогает выполнить две важные задачи: напоминает, на что нужно обращать внимание и позволяет сообщить о проблеме нажатием одной кнопки.
Бот тайного покупателя очень прост. Он состоит всего из двух обработчиков:
Первый обработчик забирает из нашего API поездки, которые недавно завершились или находятся в статусе «В пути», и отправляет в чат первый вопрос о поездке.
Второй обработчик обращается к API Телеграма и забирает непрочитанные сообщения, проходится по очереди по каждому сообщению и отправляет ответ в чат.
Конечно, можно было сделать так, чтобы наш сервер автоматически отправлял сообщения в бот поездки а ответы пользователей из Телеграма приходили не пачками, а в момент отправки, но после обсуждений мы решили сделать именно описанный выше механизм. На это было несколько причин:
В качестве базы для бота мы выбрали MySQL. Нам бы подошла любая база, даже noSQL, но мы выбрали именно MySQL, чтобы отделу аналитики было удобнее обрабатывать нужные данные.
Что касается языка, тут мы выбирали между PHP и GoLang. Остановились на PHP, потому что «а почему бы и нет». При реализации которая у нас есть, основными преимуществами Go мы бы не воспользовались, но зато усложнили бы дальнейшую разработку — не все наши разработчики пишут на Go. Если у вас есть идея, чем в данной реализации Go была бы лучше PHP, буду рад почитать в комментариях.
Улучшений с момента первой версии было не так много. После официального запуска мы начали собирать фидбек и в результате нашли всего две проблемы.
Первая проблема — короткая память. В первой реализации бот начинал расспрашивать сотрудника через 5 минут после завершения поездки. Оказалось, что за это время пассажир успевал забыть некоторые подробности, например, регистрационный номер машины. После доработки бот начинал опрос через минуту после того, как пассажир сел в машину. Бот задавал вопросы, ответ на которые уже точно известен (чистота машины, правильные ли у машины номера и т.д.). После завершения поездки бот возвращался с еще одной пачкой вопросов, ответы на которые становятся ясны только по ходу поездки.
Вторая проблема — у нас почти всегда все хорошо. Как бы странно это ни звучало, но с точки зрения бота это стало проблемой. Наши коллеги устали после каждой поездки 10 раз отвечать «все хорошо». Мы решили эту проблему группировкой вопросов: объединили все вопросы, которые задавали во время поездки и все вопросы, которые задавали после, в два одинаковых вопроса: «Все хорошо?» с разным набором ответов.
В ближайшее время планируем увеличить количество доверенных клиентов и тем самым сделать бот более эффективным. Для этого нужно будет переделать авторизацию и добавить мониторинг на критичные события. Если будут интересные перемены, напишу о них отдельную статью…
Пролог
В Ситимобил никто не носит розовых очков, мы хорошо понимаем, что наш сервис не идеален, поэтому мы всегда работаем над его улучшением. Проблемы клиентов могут быть связаны с приложением, с расчетом цены, но чаще всего — с водителем.
Мы любим своих водителей и стараемся сделать их работу более приятной и прибыльной, но из-за одного недобросовестного водителя мы можем потерять несколько клиентов и тем самым лишить заработка водителей, которые честно делают свою работу.
По этой причине мы решили разработать инструмент для быстрого реагирования на жалобы, связанные с водителями.
Зачем нам понадобился бот
Абсолютно все жалобы наших клиентов рассматриваются работниками отдела поддержки, но полностью полагаться на статистику, полученную от клиентов мы не можем по несколькольким причинам:
- не все клиенты оставляют отзывы, если что-то пошло не так;
- мы не всегда можем быть уверены в объективности клиентов;
- мы не хотим и не можем доставать клиентов кучей уточняющих вопросов для получения полной картины.
Так что же делать? Попросить наших коллег помочь!
- Сотрудники вероятнее всего не забудут сообщить о проблеме;
- Сотрудники более объективны. Не до конца, но все же :)
- Можно подойти к коллеге и разузнать все нужные подробности.
Конечно, при возникновении проблем всегда можно позвонить в диспетчерскую и обойтись без посредников, но бот помогает выполнить две важные задачи: напоминает, на что нужно обращать внимание и позволяет сообщить о проблеме нажатием одной кнопки.
Как работает бот
Бот тайного покупателя очень прост. Он состоит всего из двух обработчиков:
Первый обработчик забирает из нашего API поездки, которые недавно завершились или находятся в статусе «В пути», и отправляет в чат первый вопрос о поездке.
Второй обработчик обращается к API Телеграма и забирает непрочитанные сообщения, проходится по очереди по каждому сообщению и отправляет ответ в чат.
Конечно, можно было сделать так, чтобы наш сервер автоматически отправлял сообщения в бот поездки а ответы пользователей из Телеграма приходили не пачками, а в момент отправки, но после обсуждений мы решили сделать именно описанный выше механизм. На это было несколько причин:
- при такой реализации сервис полностью закрыт для входящих запросов по всем портам, тем самым мы можем не опасаться попыток взлома или DDOS-атак;
- если от пользователей придет одновременно много сообщений, Телеграм не засыплет нас запросами;
- если бот затупит, это никак не повлияет на наш основной сервер и не затронет бизнес-процессы.
В качестве базы для бота мы выбрали MySQL. Нам бы подошла любая база, даже noSQL, но мы выбрали именно MySQL, чтобы отделу аналитики было удобнее обрабатывать нужные данные.
Что касается языка, тут мы выбирали между PHP и GoLang. Остановились на PHP, потому что «а почему бы и нет». При реализации которая у нас есть, основными преимуществами Go мы бы не воспользовались, но зато усложнили бы дальнейшую разработку — не все наши разработчики пишут на Go. Если у вас есть идея, чем в данной реализации Go была бы лучше PHP, буду рад почитать в комментариях.
Улучшения
Улучшений с момента первой версии было не так много. После официального запуска мы начали собирать фидбек и в результате нашли всего две проблемы.
Первая проблема — короткая память. В первой реализации бот начинал расспрашивать сотрудника через 5 минут после завершения поездки. Оказалось, что за это время пассажир успевал забыть некоторые подробности, например, регистрационный номер машины. После доработки бот начинал опрос через минуту после того, как пассажир сел в машину. Бот задавал вопросы, ответ на которые уже точно известен (чистота машины, правильные ли у машины номера и т.д.). После завершения поездки бот возвращался с еще одной пачкой вопросов, ответы на которые становятся ясны только по ходу поездки.
Вторая проблема — у нас почти всегда все хорошо. Как бы странно это ни звучало, но с точки зрения бота это стало проблемой. Наши коллеги устали после каждой поездки 10 раз отвечать «все хорошо». Мы решили эту проблему группировкой вопросов: объединили все вопросы, которые задавали во время поездки и все вопросы, которые задавали после, в два одинаковых вопроса: «Все хорошо?» с разным набором ответов.
В ближайшее время планируем увеличить количество доверенных клиентов и тем самым сделать бот более эффективным. Для этого нужно будет переделать авторизацию и добавить мониторинг на критичные события. Если будут интересные перемены, напишу о них отдельную статью…