Телеграм-бот может уменьшить трение там, где человеку нужно быстро отчитаться, прислать фото, подтвердить задачу или увидеть свой список дел. Но он становится опасным, если подменяет систему прав, хранит решения только в чате или показывает данные без проверки пользователя.
Полезные сценарии
Например: рабочий получает свои задачи, отправляет фото к конкретному этапу; прораб подтверждает обход и открывает замечание; заказчик получает безопасный запрос решения по своему объекту. Это примеры дизайна процесса — доступность конкретной реализации зависит от интеграции и правил компании.
Как спроектировать безопасно
- Выбрать один сценарий с измеримым результатом, например фотоотчёт по задаче.
- Связать пользователя с учётной записью и проверять роль при каждом запросе.
- Показывать минимум данных, нужный для действия, без P&L и чужих объектов.
- После ответа создавать запись в системе объекта с автором, временем и статусом.
- Предусмотреть понятную ошибку и переход в основной интерфейс для сложных случаев.
Чего не должен делать бот
Не принимайте через него необратимые финансовые решения без дополнительных проверок и не делайте бота единственным местом хранения акта или дефекта. Чат удобен для входа, но доказательная база должна оставаться в контуре объекта.
Что зафиксировать до следующего шага
- Сценарий бота ограничен и понятен пользователю.
- Идентичность и роль проверяются до показа данных.
- Каждое действие оставляет след в истории объекта.
- Для критичных операций есть дополнительное подтверждение или основной интерфейс.
Частые вопросы
- Может ли заказчик писать рабочему через бота?
- Нет, коммуникация должна соблюдать цепочку ответственности: заказчик взаимодействует через менеджера или прораба, а не напрямую с рабочим.
- С чего начать разработку?
- С одного частого действия, которое сейчас теряется в чате, и с проверки прав доступа на реальном тестовом объекте.
