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

Возьмём обычное сообщение: «Нужна презентация для встречи в четверг. По оформлению берём прошлую версию. Цены добавим, если успеем согласовать».

Здесь есть исходные материалы, зависимость от согласования и дата встречи. Причём дата встречи ещё не определяет срок готовности презентации: кому-то нужно время на просмотр. Хорошая постановка задачи должна сохранить все эти различия.

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

Это полезно определить ещё до выбора модели. Иначе мы просто поручим ей самой решить, что в нашей переписке главное.

Для разбора текста в такой цепочке можно использовать, например, GigaChat. В узле «Языковая модель» он получает сообщение и описание нужных полей, а ответ можно запросить в формате JSON по схеме. По сути, это данные для карточки задачи, которые следующий шаг процесса сможет обработать.

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

Формат JSON задаёт структуру ответа. Проверка смысла остаётся отдельной частью процесса: модель может ошибиться даже в аккуратно заполненной карточке. Запись в CRM или постановка задачи — тоже отдельный шаг, для которого нужны свои проверки.

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

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

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