Лáбонька

Продукт начинался как трекер для одной зуботехнической лаборатории. На одном из ранних обсуждений пользователь предложил конкретное решение: парсинг писем от клиник и чат-бот в Telegram для приёма заявок.

Технически это было реализуемо — но я увидел проблему. Клинике всё равно нужно было бы держать под рукой форму в нужном формате, помнить про бота, следить за ответами в Telegram. Автоматизация накладывалась поверх неудобного процесса, не устраняя его.

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

Я предложил другое: дать клинике прямой доступ в ту же платформу. Заявка создаётся там, где она и будет выполняться — обе стороны видят одно и то же, каждая со своей ролью и своими правами.

Из этого решения выросла вся архитектура: партнёрские связи между организациями, разграниченные права, приватные финансы для каждой стороны. Из трекера для одной лаборатории продукт стал рабочей средой для двух организаций.

Один из пользователей обратился с проблемой: не мог найти нужное сообщение от врача. Искал в Telegram, потом в Max — и в итоге нашёл в почте скан, который был нужен для производства работы.

Это оказалась типичная история: рабочие переписки и файлы жили в разных каналах, без привязки к заявке. Когда нужно было что-то восстановить — начинался поиск по мессенджерам и почте.

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

Рабочее общение полностью переехало в платформу. Скан от врача, договорённость о сроках, уточнение по составу работ — всё хранится рядом с самой заявкой. Это стало одной из главных причин, по которым пользователи не хотят возвращаться к прежним инструментам.

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

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

Я добавил историю изменений к каждой заявке: кто и когда изменил статус, состав работ, назначения, описание — всё фиксируется автоматически с отметкой времени и автором. Без ручного ввода, без дополнительных действий от пользователей.

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