Всем привет! Практически любая организация — от муниципалитета до стартапа — постоянно принимает поток разнообразных обращений. Навести порядок и ускорить их обработку можно с помощью простой заявочной системы: назначить ответственных, быстро подготовить нужные документы. Для этого подойдут готовые Helpdesk- или Servicedesk-системы, но их часто нужно интегрировать с уже имеющимися инструментами. Они хорошо работают для сложных бизнес-процессов с большими объемами заявок, но стоят дорого и требуют затрат на внедрение и поддержку. В общем, это развлечение для крупных и средних компаний. Для более простых кейсов можно собрать свою небольшую систему, используя no-code-платформы.
Меня зовут Иван, я бизнес-аналитик в MWS. В этом материале расскажу о реализации заявочной системы на платформе MWS Tables, где я взял на себя не только свою работу, но и функции всей команды — от архитектора до тестировщика. Таких примеров много, и на этом видно, как no-code и разумное использование нейросетей позволяют быстро автоматизировать бизнес-процесс и адаптировать его под меняющийся ИТ-ландшафт.
Предыстория
В уездном городе N собрались люди добрые и начали думу думать, как бездомным животным помочь, да сделать так, чтобы заявки не терялись и в одно место стекались. Ибо как повелось на Руси: один звонил по первому попавшемуся телефону, другой писал бумажные письма. Нужно было что-то недорогое, быстрое и простое. Решили использовать MWS Tables, где нужные функции настраиваются быстро, дешево и самостоятельно. Так и началась история этого кейса.
Базовый продукт
MWS Tables — платформа для совместной работы и автоматизации рутины на базе умных таблиц, по сути no-code-инструмент для команды с различными ролями. Ближайший аналог — Airtable. В отличие от Google Таблиц, наша платформа представляет собой реляционную базу данных с типизацией столбцов и разными вариантами визуализации (не только табличной формой, но и диаграммой Ганта, канбан-досками и так далее).
С помощью MWS Tables можно решать много задач. Инструмент дает возможность вести персональные пространства — проекты, таблицы, опросники, заметки, автоматизации, интеграции по API с другими сервисами. Вся работа с этими элементами в режиме реального времени синхронизируется с коллегами — так управлять данными проще. Автоматизировать бизнес-процессы или руководить проектами можно без привлечения ИТ-специалистов: взять готовый шаблон, добавить сортировок, чуть доработать — и no-code-решение готово.
Мы уже писали о MWS Tables:
Фактически, мы реализовали базу данных (таблицу) для хранения всех заявок, после чего задали механизм ее заполнения и экспорта данных исполнителям в виде печатных форм. Благодаря Tables вся база была сделана буквально за два клика и без лишних сложностей.
Сбор заявок
Первоначально заказчик пришел с задачей сделать бота в MAX. Однако на тот момент реализовать такую систему было проще через Telegram. По этому пути мы и пошли.
Задача бота — последовательно задавая вопросы, собирать данные по заявкам:
ФИО заявителя;
контактные данные;
информацию о бездомном животном (размеры, особенности поведения);
адрес, где животное заметили;
фото (опционально).
В таком простом формате бота собрали вайбкодингом буквально за пару часов. Он задает вопросы из списка, собирает данные из ответа, показывает итог и отправляет их через публичный API в Tables. Заявителю в ответном сообщении бот выдает номер созданной заявки.
Позднее мы собрали простую форму внутри Tables, которая решает ту же задачу, а еще чуть позже, когда Telegram стал работать нестабильно, реализовали и бота в MAX. Теперь заявители могут сами решать, через какой канал подавать обращение. Независимо от выбора, все заявки попадают в одну базу данных. Более того, реализована логика: если бот по каким-то причинам работает плохо, он сам предлагает перейти в Tables и отправить запрос с помощью формы.
Отображение заявок
Доступ к системе имеет как заказчик, так и исполнители по задачам. Естественно, присутствуют и разработчики. Для каждой роли реализовано свое представление данных — хотя сами данные одни и те же.
Заявка — это строка в таблице с определенным набором полей: данными заявителя, информацией о проблеме, техническими деталями. Исполнители видят только ее данные (без технической информации), заказчику доступны номер, временная отметка, когда она взята в работу и статус обращения, а разработчики видят все.
Логика работы сервиса проста: как только появляется новая заявка, необходимо создать для нее печатную форму по установленному образцу, чтобы исполнителю было с чем работать (открыть, распечатать, подписать своей рукой — ради этого все и затевается, ведь заказчик отказался от электронной подписи: они не готовы цифровизироваться настолько).
При появлении новых данных в Tables срабатывает триггер, и мы отправляем запрос во внешний сервис, который генерирует печатную форму. Изначально в качестве этого сервиса выступал Google Apps Script. На тот момент самым простым путем оказалось использовать короткий код на JavaScript, опубликованный в виде функции, которую можно вызвать через браузер или API-клиент. Код использовал шаблон и подставлял в нужные места реальные данные из заявки. Исполнителю оставалось только открыть файл и распечатать его через Ctrl+P.
Позже Google Apps Script пришлось заменить на сервис функций в Яндекс Cloud — заказчик оказался ультраконсервативным и попросил использовать отечественные аналоги.
Генерацию печатных форм реализовали (а потом переделали) вообще без программистов, хотя пришлось перевести код с JavaScript на Python. Думаю, сейчас уже можно не скрывать, что 99,9% такого утилитарного простого кода — без сложных классов и невоспроизводимой логики — может писать нейросеть.
Что получилось в итоге
Хотя проект достаточно простой, реализация хорошо адаптировалась под разные условия. За время существования сервиса сменилось три варианта подачи заявок — два мессенджера и форма. Уже понятно, что инструмент можно масштабировать практически на любые внешние интерфейсы.
Ничего страшного не произошло и при смене политики относительно внешнего сервиса, генерирующего печатную форму — его быстро заменили, не привлекая разработчиков. Код потребовался только там, где нужно было строго соответствовать шаблону печатной формы. Но даже перевод на другой язык не вызвал проблем. Нечто подобное вполне может собрать для себя кто угодно.
Это стало возможным благодаря логике работы всей системы. Tables — ядро с открытым API, а любые внешние зависимости — это просто взаимозаменяемые модули. Когда обстоятельства вокруг меняются, не нужно переделывать ядро — достаточно переключиться на другой доступный инструмент.