Сотрудники уже присылали Сергею ежедневные итоги голосом в личный Telegram. Людям было проще рассказать о результате, препятствии и следующем шаге, чем заполнять ещё одну форму. Но за удобным разговором скрывалась ручная работа: скачать аудио, разложить файлы, передать их Codex, собрать PDF и вернуть документы адресатам.
Telegram Business позволил сохранить личный чат как человеческий интерфейс, а техническую обработку вынести на Mac mini. Клиент пишет привычным способом, официальный Bot API передаёт только разрешённые сообщения, Codex разбирает смысл, а обычный код проверяет структуру, адресата и право внешнего действия.
Источник
3 ID
Маршрут привязан к business_connection_id, chat_id и user_id, а не к изменяемому имени пользователя.
Материалы
5 форматов
Текст, голосовые, обычные аудиофайлы, документы и изображения проходят через единый входящий контур.
Архитектура
2 слоя
Предсказуемый код держит транспорт и проверки, а Codex работает только с подготовленным смысловым пакетом.
Рабочий маршрут
Постоянный приёмник на Mac mini не пытается сразу сделать вывод или кому-то ответить. Сначала он подтверждает источник, сохраняет исходные материалы, убирает повторы и готовит ограниченный пакет для смысловой работы.
Продуктовое решение
В этом процессе был важен личный адресат. Сотрудник понимал, кому рассказывает о своём дне, и не переходил в ещё одно служебное окно. Поэтому автоматизация появилась на стороне Сергея и не заставила клиента менять привычку.
Человек продолжает писать Сергею в той же переписке, без команд, нового интерфейса и необходимости искать отдельного бота.
Telegram Business-бот получает доступ не ко всей переписке, а к явно разрешённому маршруту с устойчивой числовой идентификацией.
Можно надиктовать итог по дороге, переслать документ, добавить фотографию или написать короткое пояснение.
Сообщение получает происхождение, состояние обработки, документированный результат и контролируемый путь обратно.
Разделение ролей
Codex не живёт внутри Telegram, не получает токен и не выбирает адресатов. Он видит подготовленный пакет источников и возвращает структурированный результат. Получение сообщений, очереди, транскрибация, PDF, журнал и доставка остаются у проверяемого кода.
Официальный Bot API подхватывает разрешённые сообщения в личной переписке, не меняя сценарий клиента.
Локальная машина принимает обновления, хранит вложения, запускает транскрибацию и ведёт состояния обработки.
Агент выделяет результаты, препятствия, следующие действия и собирает документы по строгому контракту.
Подготовленный снимок помогает отличить подтверждённые действия от частично подтверждённых и мест, где данных недостаточно.
Структура, тип документа, адресат и контрольная сумма проверяются до любой обратной отправки.
Новый маршрут по умолчанию готовит черновик; отправка, задачи, CRM-записи и публикация включаются отдельно.
Безопасность
Маршрут проектировался вокруг цены ошибки. Если источник неизвестен, транскрибация не завершилась, результат Codex не прошёл проверку или адресат не совпал с контрактом, система не пытается угадать и ничего не отправляет.
Связка business_connection_id, chat_id и user_id отделяет разрешённый чат от похожего имени или изменённого username.
Каждое сообщение получает ключ защиты от дублей, поэтому перезапуск службы не должен повторить обработку и доставку.
Telegram-токен, пароли, учётные данные других систем и право выбирать адресатов остаются вне смыслового прохода.
Сотрудник получает только своё нейтральное резюме, а управленческий отчёт нельзя случайно отправить не тому человеку.
Перед отправкой сверяются тип документа, адресат и контрольная сумма, а повторный запуск не должен дублировать сообщение.
Сначала одно контрольное сообщение должно прийти ровно один раз, попасть только в свой проект и не вызвать внешних действий.
Повторяемость
После первого рабочего контура стало ясно, что транспорт не зависит от ежедневных отчётов. Через тот же личный Telegram клиент может передать договор, таблицу, фотографию, вопрос или голосовое объяснение — различается только контракт проекта.
Скилл уточняет клиента, допустимые сообщения, нужный результат, место хранения, право ответа и операции с отдельным подтверждением.
Новый чат нельзя просто добавить в чужую очередь: источники, хранилище, контракт обработки и получатели должны быть изолированы.
Пока межпроектный слой не включён, подключение заканчивается подготовленным контрактом и не смешивает новый чат с действующим проектом.
Приём материалов и черновик можно проверить безопасно; отправку, постановку задач и запись в CRM разрешают только после пилота.
Результат
Для клиента почти ничего не изменилось. Для Сергея изменился весь внутренний маршрут: у входящего материала появились происхождение, очередь, транскрибация, смысловой контракт, проверяемые документы и контролируемая обратная доставка.
Он пишет, надиктовывает и пересылает материалы в привычном личном чате.
Файлы не нужно каждый раз скачивать, переименовывать, раскладывать по папкам и заново объяснять задачу Codex.
Сводный отчёт различает подтверждённые данные, частичное подтверждение и места, где информации для вывода недостаточно.
Обычное личное сообщение может безопасно запустить проектный процесс с понятными разрешениями и стоп-линиями.
Источник
В статье разобраны причины сохранить личный чат, устройство приёмника на Mac mini, локальная транскрибация, read-only сверка с amoCRM, роль Codex, безопасная доставка и переход от одного процесса к повторяемому способу подключения клиентов.
Разборы
Разбор
Официальный Plaud MCP убирает ручную прослойку между разговором и работой: агент получает запись через MCP, собирает бриф, следующие действия и контекст для Notion, Linear и Codex.
Открыть разбор →Разбор
Автономный контур синка транскриптов из Plaud в Notion с дедупликацией, миграцией структуры данных и рабочим UX.
Открыть разбор →Разбор
Контентный pipeline, где сырьё из Telegram, соцсетей и закладок превращается в черновики сайта через Notion-агента.
Открыть разбор →