Использование ботов мессенджеров для автоматизации и упрощения бизнес-процессов

Мой доклад посвящен ботам и их использованию в 1С. Сразу предупрежу, что у нас на работе в качестве корпоративного мессенджера используется ICQ, и в ходе доклада я буду его упоминать.

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

Расскажу немного о себе. Программистом 1С я работаю более 12 лет. Семь лет назад погрузился в веб-разработку. И еще я недавно участвовал в конкурсе по программированию искусственного интеллекта, где занял 74 место из тысячи с лишним участников. Отсюда, наверное, и моя любовь к разработке искусственного интеллекта и ботов, в том числе.

Доклад будет условно разбит на две части.

• В первой половине я расскажу об области применения ботов в 1С. Поговорим:

  • для кого это нужно;

  • что можно сделать с помощью ботов;

  • что нельзя делать с помощью ботов.

• А во второй части будет про внутреннее устройство ботов. Я расскажу:

  • про объекты метаданных, которые я использовал в разработке нашего бота;

  • про безопасность – чем она достигается;

  • про то, как можно добавлять новые возможности бота без обновления конфигурации;

  • и про режим диалогов.

Кому нужны боты?

Больше всего боты востребованы в средних и крупных компаниях.

Очень редко боты нужны небольшим компаниям, потому что основная цель бота – это сократить коммуникационный разрыв и предоставить информацию нужным пользователям как можно быстрее. Но в маленьких компаниях, когда у нас один-два кабинета, где все ежеминутно друг другом общаются – там коммуникационных разрывов, как правило, нет. И скорость получения информации там тоже достаточно оперативная, потому что бухгалтер сидит за соседним столом – если менеджеру пришла оплата, бухгалтер может ему сам передать информацию. У меня был опыт внедрения бота в небольшие компании из 15 человек, но там это не пошло – у них не было в этом потребности.

Основные пользователи бота – это:

• Менеджеры отделов продаж. Для них бот – это своего рода секретарь, который вовремя обо всем напоминает и может проделать какую-то не очень сложную работу. Пользоваться ботом выгоднее, чем нанимать реального сотрудника, ведь, если у вас в компании 150 менеджеров по продажам, каждому нанять секретаря – это достаточно затратно. А так мы можем использовать бота, и он будет секретарем.

• Менеджеры отдела закупок тоже могут являться пользователями бота – но, конечно, в меньшей степени.

• Даже системные администраторы у нас получают от бота уведомления, если заканчивается место на диске для бэкапов.

• Еще, возможно, боты нужны вашим клиентам. Например, когда вы хотите уведомить клиента, что его заказ готов к отгрузке. Но здесь есть одно «но» – чтобы ваши клиенты смогли стать пользователями вашего бота, данные у вас в базе должны быть безупречными. Иначе может произойти неловкая ситуация, когда бот написал клиенту, что товар готов к отгрузке, а в реальности окажется, что товара на складе нет – клиент будет очень разочарован и недоволен вашей компанией.

Для чего можно использовать ботов?

Что можно сделать с помощью ботов?

• Прежде всего, это, конечно, уведомления – они могут быть личные (предназначаться непосредственно сотруднику) или групповые. У нас, например, в компании есть групповой чат и групповой канал. Наверное, знаете, что в чат могут писать все, а в канал – только отдельные люди, остальные читают. Бот может писать и туда, и туда. Я позже расскажу, как он это делает.

• Еще с помощью ботов можно записывать документы и справочники.

• И можно в целом взаимодействовать с 1С – так же, как вы взаимодействуете с 1С через мобильный клиент или через мобильное приложение. Что вы туда заложите, так и будет это работать.

В нашей компании мы через бота пишем в базу 1С:

• события;

• проводим анкетирование новых сотрудников для заполнения информации в справочнике физических лиц;

• регистрируем отсутствия на рабочем месте;

• отменяем бронирование по заказу покупателя при отсутствии оплаты в течение определенного срока.

По уведомлениям – давайте я вам расскажу немного подробнее, какие уведомления используются в нашей компании, и как они помогают менеджерам по продажам.

• Во-первых, бот своевременно сообщает менеджеру, что пришла оплата от клиента. Говорит номер и состав заказа, указывает номер телефона, по которому можно созвониться с клиентом и подтвердить заказ.

• Есть уведомления о готовности к отгрузке. Если у вас заказной товар, который откуда-то едет в течение длительного времени, важно, чтобы менеджер про этого клиента не забыл. Чтобы, когда товар все-таки поступил на склад, бот уведомил менеджера, что товар поступил и его нужно отгрузить. На скриншоте мы видим сообщение, которое приходит в этом случае менеджеру – здесь указан заказ, наименование контрагента, его телефон, сколько у клиента оплачено и какие условия оплаты по договору. Это очень удобно – менеджер может тапнуть на номер телефона и сразу же совершить звонок клиенту.

• Еще есть уведомления о готовности к перемещению в производство – если это не только заказная позиция, но ее еще нужно как-то доработать. Бот пишет, что товар готов к перемещению в производство – такое уведомление тоже позволяет повысить оперативность работы.

• Есть уведомления по ожиданию решения в согласовании – это тоже очень полезно, особенно при долгих согласованиях. Наверняка, у всех в компаниях организовано согласование документов в электронном виде – в 1С или еще где-то. Очень важно, чтобы все участники согласования своевременно понимали, что сейчас требуется их участие в согласовании, бизнес-процесс ожидает их решения. Для этого бот отправляет тем, кто должен согласовать, уведомление, что ожидается решение. Таким образом согласование проходит в целом быстрее, мы получаем меньше задержек в согласовании.

• Есть уведомления по изменениям статуса счета – эти уведомления во многом похожи на уведомления по оплате от клиента и готовности к отгрузке, но здесь бот дополнительно уведомляет о статусе «Отменен». Это удобно, когда менеджер, допустим, сделал корректировку заказа покупателя и закрыл его в ноль, сам того не ведая. Бот ему сразу пишет, что у счета статус «Отменен». Менеджер начинает разбираться и понимает, что он скорректировал заказ в ноль.

• Уведомления о потерянных счетах тоже полезны. Когда менеджер сделал счет, но при этом в течение пяти дней нет никаких событий по счету – нет оплат, нет заказов клиента – бот также пишет: «Не забыл ли ты про этот счет?». Бывает, что менеджер по продажам забывает и счет теряется. А так бот уведомил, и менеджер не забыл, позвонил. Увеличиваем продажи.

• И еще одно полезное уведомление – недостающая сумма для выполнения плана. Бот в середине месяца начинает писать каждому менеджеру, на какую сумму ему нужно продать, чтобы выполнить его личный план. Каждому пишет его индивидуальные показатели продаж. Таким образом менеджеры понимают, что им нужно еще немного постараться, и у них план будет закрыт. Соответственно, денег они получат больше, и компания получит прибыль больше. Когда такие уведомления есть, все счастливы.

• Уведомляем менеджеров по закупкам о том, что скоро будет поступление товаров. За три дня у нас бот пишет менеджерам и снабжению, что скоро приедет товар.

• И у нас есть уведомления для системных администраторов. Мы все знаем, что бэкапы нужны, важны, их нужно делать всегда, и не должно быть причин, по которым они не могут делаться. Поэтому бот уведомляет системных администраторов, когда заканчивается место на диске, на который складываются бэкапы. Тоже удобно – администраторы всегда знают, что место заканчивается и принимают меры, если бэкапы сделаться не могут.

Расскажу про запись объектов.

При трудоустройстве сотрудника наш отдел кадров дает ему ссылку на бота, где новый сотрудник должен заполнить анкету – указать, как с ним связаться: его ФИО, должность, город, телефон, мессенджер и т.д.

Причем, обратите внимание, здесь на скриншоте видно, что город сделан кнопками. Использовать в боте кнопки – это очень важно, потому что часто сотрудник может написать город с ошибкой, а здесь мы точно можем идентифицировать и потом строить из этого какие-то отчеты.

После того как сотрудник заполнил анкету у бота, происходит запись в справочник физлиц – там сохраняются все анкеты, которые заполняют новые сотрудники. Т.е. бот уже знает о том, кто в компании работает.

Причем, не только бот знает, но и все остальные сотрудники знают. Как я говорил, у нас есть канал, в котором подключены все сотрудники. И как только анкета заполнена, происходит запись в справочник физлиц и формируется уведомление в канал о том, что в компании появился новый сотрудник с такой-то должностью, у него такой-то телефон, такой-то мессенджер. Тоже очень удобно – из сообщения можно кликнуть, сразу перейти и написать что-то новому сотруднику.

Тем самым мы устраняем коммуникационные разрывы – все понимают, что новый сотрудник будет отвечать вот за это.

События после уведомления о просроченной задолженности. Помимо самого уведомления о просроченной задолженности, менеджеры потом повторно с какой-то периодичностью получают сообщения о том, что есть просроченная задолженность.

Бот так же пишет наименование и телефон клиента, какая сумма, сколько дней, чтобы менеджер смог позвонить и пообщаться: «У вас такая просрочка, не хотите ли вы ее закрыть?».

Допустим, клиент говорит: «Да, через неделю закрываем эту просрочку, надо немного подождать». В этом случае здесь снизу есть кнопка «Создать событие по договору».

Когда менеджер нажимает «Создать событие по договору», бот его спрашивает: «Дай мне какое-то описание события», и менеджер туда пишет, что клиент пообещал через неделю заплатить.

После того как менеджер нажимает «создать событие» и делает описание, создается событие.

Событие, в свою очередь, подтягивается в отчет по дебиторке, и юристы, когда формируют отчет, оперативно видят, что работа с этим клиентом идет – пока не нужно начинать судебное разбирательство или еще что-то.

Дальше есть еще у нас тоже своего рода анкета – это отсутствие на рабочем месте.

Когда человек собрался в любой отпуск или на больничный, он заполняет у бота некую анкету – дата начала, дата окончания, причины отсутствия.

Опять-таки эта информация попадает в канал, где все сотрудники.

И все понимают, что этого сотрудника не будет там в течение двух следующих недель. И если какие-то вопросы с ним нужно срочно закрыть, срочно их закрывают.

Есть еще запись объектов на снятие броней с товаров.

Снимаются брони по определенному правилу.

• На девятый день бот уведомляет сотрудника, что у тебя есть бронь, которая будет завтра снята.

• А на десятый день бот уведомляет сотрудника о том, что твоя бронь снята.

Так у нас выглядит справочник сотрудников – это я делал через HTTP-сервисы.

Здесь HTML-страничка, которая использует bootstrap, jQuery – все, что нужно.

Очень удобно, когда сотрудники в браузере открывают этот справочник, а информация сюда попадает оперативно, как мы знаем – заполнил анкету, и информация в справочнике.

• Если кликнуть по ФИО, открывается ICQ (в нашем случае).

• А если кликнуть по почте, открывается почтовая программа.

Сразу же можно начать общаться – не нужно искать, звонить или еще что-то. Это тоже удобно, кстати.

Для чего нельзя использовать ботов?

Ну и давайте поговорим, что нельзя делать с помощью ботов:

• Через бота нельзя спамить. Практическим путем я для себя вывел ограничение – 25 сообщений в день на одного сотрудника воспринимается в целом нормально. Но если сообщений становится больше, начинаются жалобы: «У меня куда-то все сообщения уходят вверх, я ничего не успеваю прочитать!!!» Таким образом бот уже перестает быть помощником менеджера, он начинает ему реально мешать жить, и он его игнорирует. На этом история отношений бота и сотрудника заканчивается.

• Нельзя еще уведомлять при записи объектов. Это не запрет, а моя рекомендация. Например, если вы хотите уведомить сотрудника о том, что товар поступил, не стоит делать это при записи документа «Поступление товаров». Потому что может оказаться, что вам в поступлении нужно добавить комментарий – при этом произойдет повторное уведомление сотрудника. И опять мы приходим к тому, что бот начинает спамить – а это вызовет жалобы.

• Нельзя изменять данные без уведомлений. Когда мы хотим изменить какие-то данные – например, снять бронь – мы обязательно должны уведомить об этом ответственное лицо. Иначе опять может произойти неприятная ситуация, когда бот снял бронь, а менеджер ни сном ни духом. Клиент приехал забирать товар, а товара, оказывается, нет, потому что бронь уже была снята и отдана другому клиенту.

• Нельзя через бота заставить сотрудников работать. У меня был запрос, чтобы бот каждый день в 12 часов напоминал, чтобы сотрудник не забыл посмотреть отчет. Но это работать не будет, потому что в целом сотрудник может легко игнорировать бота – не посмотрел и не посмотрел, забыл и ладно. Руководитель должен контролировать это самостоятельно – проверять, посмотрел ли сотрудник отчет и знает ли о том, что у него вот такая ситуация с таким-то клиентом.

Внутреннее устройство ботов

Теперь давайте поговорим, что внутри бота.

Прежде всего, это константа для хранения токена. Когда мы регистрируем бота на сервере – в нашем случае, на сервере ICQ – нам выдаётся токен, с которым мы уже можем управлять ботом, отправлять сообщения или получать. И этот токен должен использоваться во всех запросах, которые мы делаем на сервер. Для этого я использую константу.

Используется регламентное задание. Оно используется одно, но для него создаётся несколько экземпляров – я об этом сейчас расскажу.

Используется два справочника:

• Меню бота. Это справочник, который позволяет в виде кнопок выводить все возможные действия бота.

• Настройки для уведомлений и обработки входящих сообщений. Это самый главный справочник. По сути, каждый элемент этого справочника создает новое регламентное задание – мы можем сделать в этом справочнике столько элементов, сколько нам нужно регламентных заданий.

Ну и регистры сведений:

• Входящие сообщения. Я предлагаю фиксировать все входящие сообщения, потому что это очень важно, чтобы проанализировать правильность работы бота. Например, у нас есть сервис «Поиск контакта через бота». Набираешь боту контакт, он говорит: «Напиши мне ФИО, отдел, номер телефона или почту». И пользователи пишут. Анализируя входящие сообщения, я понял, например, что пользователи часто пишут фамилию с ошибкой. Для этого я добавил некую маску, и пользователь может искать по неточному соответствию. Например, моя фамилия Опарин, но многие ее хотят написать с буквой «А» и ищут фамилию Апарин. В этом случае бот все равно выведет мой контакт.

• Отправленные уведомления. Этот регистр сведений нужен для того, чтобы фиксировать, что мы уже отправили сотруднику, чтобы не отправлять повторно. Например, как в случае с готовностью к отгрузке – это регламентное задание срабатывает каждые 300 секунд, и если мы менеджера уже уведомили, что товар готов к отгрузке, то незачем это делать еще раз. Мы заглядываем в регистр сведений «Отправленные уведомления», видим, что уже отправляли уведомление меньше 24-х часов назад, и повторно уже не отправляем. Но если больше 24-х часов прошло, и товар все еще не отгружен, менеджера, наверное, нужно уведомить еще раз – он мог по каким-то причинам это пропустить.

• Диалоги. Это очень важный регистр. Когда я начинал разработку этого бота, я думал, что он будет только уведомлять. Но оказалось, что пользователи хотят с ним как-то общаться и какую-то информацию от него получать по запросу. Для этого появился режим «Диалоги», чтобы, когда пользователь делает какой-то запрос, бот понимал, что пользователь находится в определенном диалоге. Например, поиск контактов – это тоже диалог, и если менеджер начал поиск контакта, бот перестает реагировать на другие его сообщения – вне зависимости от того, что пользователь пишет, бот ищет в контактах. У диалогов есть время открытия и время закрытия. Есть автоматическое закрытие диалогов, которое закрывает диалоги, открытые более пяти минут. Допустим, менеджер мог что-то написать боту, диалог открылся, менеджер забыл про него и ушел. А когда вернулся, он хочет уже другой запрос. Чтобы закрывать такие диалоги, используется отдельное регламентное задание.

• Переменные диалогов. В этом регистре сведений хранятся данные для всевозможных анкет, информации по контактам, когда нам нужно шаг за шагом опросить сотрудника и каждый шаг куда-то сохранить. Мы сохраняем это в регистр «Переменные диалогов», где есть ID диалога, номер шага, с которого это сохранено, и сама переменная. Чтобы, когда пользователь дойдет до конца заполнения анкеты, можно было все эти переменные собрать и уже записать в элемент справочника «Физические лица».

• Соответствие пользователей 1С пользователям мессенджера. Тоже очень важный регистр, чтобы понимать, кому что писать.

Новые возможности бота без изменения конфигурации

Так выглядит справочник настроек – в данном случае показаны настройки уведомления «Готовность к отгрузке».

Здесь установлено использование регламентных заданий и задано расписание – каждые 300 секунд бот проверяет, не нужно ли сообщить о готовности к отгрузке. Если нужно, сообщает.

Также есть вкладка «Алгоритмы».

На слайде показаны алгоритмы для уведомления «Отсутствие на рабочем месте». Перечислены шесть шагов, которые пользователь пройдет, если захочет у бота заполнить анкету на отсутствие на рабочем месте.

Шаги в диалогах можно пропускать – это важно, потому что иногда мы выбираем, к примеру, какой-то город, в котором работает сотрудник, а в этом городе только одно подразделение, и нет смысла спрашивать следующим шагом – в каком подразделении работает сотрудник. Поэтому какой-то шаг можно пропустить.

Структура большинства шагов может быть парной:

• Сначала производится какой-то запрос – в данном случае мы обращаемся за контактной информацией, чтобы идентифицировать пользователя – нам пользователь написал какой-то номер ICQ, и мы его идентифицируем.

• И дальше через процедуру «Выполнить» выполняется сам алгоритм и делает все, что там написано.

Благодаря такой структуре этого справочника, настройки можно добавлять без изменения конфигурации:

• Если нам нужно регламентное задание, ставим галочку «Использовать регламентные задания» и задаем расписание.

• Если регламентное задание не нужно, а это какой-то диалог, мы заполняем алгоритмы, которые при этом выполняются.

Теперь немного подробнее про меню бота.

У бота есть меню, я его использую, чтобы выдавать в любой непонятной ситуации. Потому что пользователь должен всегда получать какой-то ответ от бота. Не должно быть таких ситуаций, что пользователь написал что-то, а бот молчит. В таких случаях сотрудник не понимает, что происходит – это бот задумался, или он хочет, чтобы я ему еще что-то написал? Поэтому в любой непонятной ситуации на любой запрос можно выдавать меню.

У нас меню из восьми пунктов. Подробно на них останавливаться не буду. В общем, это просто нужно делать.

Безопасность. Идентификация пользователя и long polling

Ну и про безопасность. Я уже говорил, что есть регистр сведений «Соответствие пользователей 1С и пользователей мессенджера».

Когда пользователь хочет пройти авторизацию в 1С, бот выдает ему небольшую инструкцию: «Открой указанную обработку и скинь мне ключ».

Ключ генерируется из хэш-функции, и он у всех уникальный. Никто не может знать, какой ключ у другого сотрудника.

Пользователь копирует ключ, отправляет боту. Бот при этом делает запись в регистр сведений «Соответствие пользователей».

У нас таким образом появляется четкая идентификация, что этому пользователю соответствует этот идентификатор, чтобы в дальнейшем это использовать и слать пользователям личные сообщения.

Немного поговорим про long polling – вытягивающие запросы.

Есть два вида взаимодействия с ботом.

• Это веб-хук, когда сервер вам делает запрос по вашей 1С и при этом 1С начинает что-то делать. Это называется веб-хук.

• А есть, когда 1С делает запрос к серверу и говорит: «Нет ли там новых сообщений?». И сервер отвечает: «Да, есть сообщения». Это называется long polling. И тогда уже 1С что-то начинает делать.

Практическим опытом выведена такая формула – я даю боту пять секунд на ожидание ответа от сервера мессенджера и пять секунд на обработку запроса.

Если давать меньше пяти секунд, мы можем попасть в такую ситуацию, что сообщений очень много и сервер не успел дать ответ или мы не успели обработать запрос.

Получается, что бот раз в десять секунд делает эти long polling запросы, чтобы пять секунд ожидать ответ и пять секунд делать обработку.

Есть запросы, которые предполагают, что будет какая-то долгая обработка – например, запрос какого-то тяжелого отчета.

Для таких запросов стоит использовать фоновые задания – не нужно пытаться сразу же это обработать, как только бот получил это сообщение. Если это долгие запросы – всегда используйте фоновые задания.

3 правила бототехники

Ну и как итог этого доклада давайте поговорим про три правила бототехники, которые я вывел для себя за те полтора года, как у нас в компании работает бот – увеличивает прибыль компании и помогает менеджерам.

• Первое правило – бот должен помогать, а не мешать. Помните, мы про спам говорили? Если бот начнет спамить, он начнет мешать, взаимодействие сотрудника и бота прекратится.

• Второе правило – бот не должен молчать. Нужно, чтобы сотрудник всегда понимал, чего от него хочет бот, и как ему реагировать. Можно, как в моем случае, в любой непонятной ситуации вводить меню.

• Ну и третье правило – бот не должен менять данные без уведомления ответственных. Да, как мы с вами говорили, если бот меняет какие-то данные, но не уведомляет сотрудника при этом, может произойти неловкая ситуация, когда клиент приедет, а его товара на складе нет.

Ну и в качестве заключения хочу сказать, что, с моей точки зрения, все компании сейчас делятся на два типа – компании, у которых есть бот, и компании, где бот будет.

Вопросы

Почему вы в качестве мессенджера используете ICQ?

Мой доклад безотносительно какого-то мессенджера. Почему мы на работе используем ICQ, я, честно говоря, не знаю. Когда я пришел, она уже была.

Это тот самый мессенджер ICQ, который был несколько лет назад? Или вы его так называете?

За последние несколько лет ICQ сделала много шагов в сторону пользователя и сейчас, по своей сути, она повторила Telegram. Правда, мне все равно кажется, что Telegram немного лучше в качестве мессенджера, но ICQ сейчас очень похожа на Telegram.

Вы также там регистрируетесь, указывая свой телефон. Там тот же интерфейс, что в Telegram – слева список контактов, справа окно мессенджера.

Если вы не видели последние два года Аську, советую посмотреть. Она очень изменилась.

Мессенджеры, которые используют long polling – это как раз Telegram, теперь еще ICQ. Вы говорите, что разрабатываете бота и навешиваете на него логику безотносительно какого-то конкретного мессенджера. Но вот этого long polling в других мессенджерах – Viber, WhatsApp Business, Facebook, ВКонтакте – их там нет. Там все работает через веб-хуки, и тогда встает следующая проблема – мы не можем опубликовать продуктовую базу, содержащую логику бота в интернет. Это, наверное, неправильно с точки зрения безопасности. А ваш бот – прямо в продуктовой базе расположен?

Да, наш бот в рабочей базе работает. В качестве безопасности не было прецедентов.

Это потому, что вы через long polling работаете. А расскажите еще про сам процесс диалога, особенно когда этот диалог контекстно-зависимый. Вы говорите, что используете для хранения этого контекста регистр с переменными, но когда карта этого диалога там более сложная, чем вопрос-ответ, вы эту схему реализуете кодом или рисуете через карты маршрута бизнес-процесса, какие-то сторонние приложения? Например, если в дерево этого диалога нужно добавить еще какое-то ответвление – что вы делаете в вашей парадигме? Садитесь и кодите или используете какие-то визуальные редакторы?

Если нужно добавить или изменить какие-то шаги, я сажусь и пишу код. Если честно, я плохо представляю визуальное редактирование всех возможностей, потому что, когда мы добавляем GUI, мы сокращаем возможности. Я этого не сделал, потому что на это тупо уходит больше времени. Время мне нужно было все-таки беречь, поэтому я сделал шаги у бота. И можно из любого шага при необходимости можно перепрыгнуть на любой другой.

Если сотрудник, общаясь с вашим ботом, ушел в какое-то дерево диалога и находится в середине этого дерева. И вдруг он решает спросить о чем-то совершенно другом, что нужно сделать, чтобы это сработало? Например, бот у него спросил: «Как твоя фамилия», а сотрудник передумал говорить фамилию и хочет узнать расписание.

У бота есть определенное стоп-слово – на удивление, оно называется просто /stop, сотрудник просто пишет боту /stop, и диалог закрывается.

Т.е. диалог либо автоматически закрывается, либо через /stop.

Пользователи с телефонов работают или через браузер?

Кому как удобно. Большинство работают с десктопного приложения, но также есть возможность работать и с сотового телефона.

Вот мне интересно, какой процент пользователей работает со своих телефонов, если такие есть?

У меня такой статистики нет, и вряд ли она может быть, потому что когда бот получает сообщение, там нет информации о том, с какого устройства это сообщение получено.

Не сталкивались ли вы с проблемой нарушения целостности при откате транзакции? Например, мы попытались отработать запрос от бота, у нас произошла ошибка базы данных, а пользователь уверен, что данные он отправил. Или наоборот – мы отправили что-то пользователю в транзакции, а транзакция откатилась.

Все транзакции выполняются в последнем сообщении – это делается через «Попытка… Исключение». Он пытается записать информацию в справочник физлиц, и в исключении пишет пользователю: «Запись не удалась». А если попытка сработала, он пишет: «Данные записаны».

Сильно ли ваше решение зависит от конфигурации? Оно реализовано в виде расширения? Можно ли в вашей системе разместить сразу несколько ботов – один бот в Телеграме, а другой – в ICQ?

Я для себя вывел такое правило: один бот – одна база. Да, если вы используете несколько мессенджеров – Телеграм, ICQ и еще что-то – да, можно сделать несколько ботов, чтобы они работали в одной базе. Но у них у всех будет настроено получение сообщений. И если часть сообщений мы уже получили, в следующий раз мы их уже получить не можем. Поэтому один бот – одна база.

Если вы про саму мою разработку, у меня сейчас нет ни расширения, ни какой-то конфигурации, которую можно накатить – все это еще только в планах. Решил начать с доклада. Если будет интересно, обязательно сделаю такую разработку.

Как вообще обычные пользователи восприняли бота? Легко ли им все это далось?

У нас работает около 200 человек. Менеджеров по продажам – около 150.

В первый месяц, когда я ввел бота только с уведомлениями, мне в течение месяца где-то человек 30 написало: «Я просто не знаю, как без этого раньше работал».

На тот момент еще нельзя было устранять коммуникационные разрывы и видеть справочник контактов, были только уведомления и их набор был очень ограничен (вначале два или три уведомления только было). Но пользователи это очень хорошо восприняли. И директор тоже поблагодарил, сказал: «Классная работа!»

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.