Как написать регламент с помощью нейросети: соберите фактические заметки об одном повторяющемся процессе, попросите модель собрать из них черновик с ролями, условиями и исключениями, затем проверьте текст на пропуски и отдайте владельцу на сверку. Ниже — полный порядок действий на учебном примере команды «Лист», которая принимает заявки на макет.
Определите границы процесса и его владельца
Регламент описывает один повторяющийся процесс с началом и концом. Возьмите процесс, у которого есть понятное событие запуска и понятный результат: заявка пришла — карточка ушла в работу. Процессы, которые тянутся месяцами и пересекаются с другими, распадаются на несколько регламентов.
Границы фиксируются тремя вопросами. Что запускает процесс (вход)? Что считается завершением (выход)? Где процесс останавливается и уходит на решение человека? В учебном примере вход — письмо клиента в общую почту, выход — карточка со статусом «В работе», датой и копией сообщения клиенту.
Владелец — человек, который отвечает за актуальность текста и принимает спорные решения. В исходных заметках команды «Лист» владелец версии не назван, поэтому в черновике это место помечается как «Требует решения владельца». Имя вписывает команда, модель его придумывать не должна.
Отделите роли от людей. Роль «координатор» обозначает функцию. При смене исполнителя регламент остаётся рабочим. Такой подход совпадает с тем, как устроены описания процессов в инструментах документирования: в справке Process Street указано, что сгенерированный workflow включает поля формы, назначения на пользователей, динамические сроки и согласования.
Запишите границы до обращения к модели. Черновик, построенный на размытом описании, придётся переписывать целиком.
Соберите факты и отделите неизвестное от правила
Исходник — это заметки о том, как процесс идёт сейчас. Пишите их короткими утверждениями, по одному действию на строку. Формулировки «обычно», «как правило», «если успеваем» в регламент не переносятся: они описывают привычный порядок. Для регламента уточните обязательное правило у владельца.
Разделите материал на три группы. Первая — принятые правила: «координатор создаёт карточку в тот же рабочий день». Вторая — условия и развилки: «если размера или текста нет, координатор просит дополнить и ставит Ожидает данных». Третья — неизвестное: цена, сроки ответа клиенту, интеграции с программами. Неизвестное помечается как вопрос к владельцу.
Полезно сразу выписать то, чего в заметках нет. В учебном примере не назван владелец версии, не задан срок ответа клиенту и не описан нестандартный формат дальше факта передачи руководителю. Вынесите эти пробелы в отдельный список вопросов владельцу.
В обзоре Process Street по AI SOP software сказано, что команда должна проверить черновик, подтвердить точность шагов и согласовать итоговую версию перед использованием.
Проверьте, что каждая строка заметок отвечает на вопрос «кто, что, когда». Строки без ответственного или без срока превращаются в отдельные вопросы к владельцу.
Три способа получить черновик по виду исходника
Способ выбирается по тому, что у вас на руках: текст, экранная запись или готовность настраивать исполняемый процесс.
| Вид исходника | Инструмент | Что даёт | Что остаётся человеку |
|---|---|---|---|
| Текстовые заметки, письма, черновики | Обычный текстовый чат с моделью | Черновик структуры: цель, вход, выход, роли, условия | Проверка фактов, ролей и сроков |
| Экранная запись процесса в браузере | Scribe AI | Пошаговый документ со скриншотами и подписями | Правка шагов, добавление условий и исключений |
| Готовый документ или описание процесса | Process AI в Process Street | Workflow с полями, назначениями, сроками и согласованиями | Настройка маршрута и запуск |
Первый способ подходит, когда процесс ещё не автоматизирован и живёт в переписке. В документации Scribe указано, что Scribe AI превращает рабочий процесс в пошаговый документ автоматически, а страницы собирают несколько записей в один документ с текстом, видео и скриншотами.
Второй способ удобен для действий в интерфейсе: расширение записывает клики и набираемый текст, после остановки записи генерируется пошаговая инструкция. В справке Scribe описаны шаги: запустить захват, остановить его, отредактировать и поделиться ссылкой или экспортировать в PDF, HTML либо Markdown.
Третий способ выбирайте для регламента с исполняемыми заданиями и согласованиями. В справке Process Street сказано, что генератор workflow создаёт полный процесс из названия и описания, включая поля формы, подсказки к задачам, назначения, динамические сроки и согласования; поле описания принимает до 10 000 знаков, а импорт документов поддерживает PDF, CSV, DOCX, HTML и TXT до 25 МБ и изображения JPG и PNG до 20 МБ.
Полный промпт с фактическими заметками
Ниже — готовый промпт. Он включает исходные заметки целиком, поэтому копируется и вставляется без правок.
Составь регламент приёма заявки команды «Лист» только по заметкам ниже.
Дай цель, вход, выход, роли, последовательность, таблицу условий и исключений,
подтверждение выполнения, вопросы к владельцу. Не придумывай цену, SLA или
программный интерфейс. Неизвестное помечай «Требует решения владельца».
Сохрани остановку нестандартного формата.
Заметки:
Клиент пишет в общую почту. Координатор в тот же рабочий день создаёт карточку
с клиентом, видом макета и желаемым сроком. Если размера или текста нет,
координатор просит дополнить и ставит «Ожидает данных». Если данные есть,
дизайнер проверяет их до конца следующего рабочего дня. При неясном сроке
дизайнер задаёт вопрос координатору, не обещает дату клиенту. Руководитель
согласует дату до передачи в работу. После согласования координатор сообщает
клиенту дату и меняет статус на «В работе». Копию сообщения кладёт в карточку.
Нестандартный формат передают руководителю; обычный маршрут до его решения
приостанавливается. Рабочие дни понедельник–пятница; праздники в примере
не учитываются.
Что менять под себя: подставьте название команды, свой процесс и свои заметки. Если у процесса есть сроки, которых нет в исходнике, добавьте их в заметки до запуска промпта.
Вариации той же задачи:
Собери из заметок только таблицу «условие → действие → ответственный → след»
без остальных разделов.
Найди в заметках все места, где не назван ответственный или срок, и вынеси
их отдельным списком вопросов к владельцу.
Перепиши черновик регламента так, чтобы каждое действие начиналось
с роли, и сократи формулировки до одной строки на шаг.
Составь по этому регламенту три контрольные заявки: с неполными данными,
с полными данными и с нестандартным форматом. Для каждой укажи ожидаемый
статус и следующего ответственного.
Проверь черновик на противоречия между разделами и перечисли найденные
несоответствия с указанием строк.
Заполненный регламент с развилкой и подтверждением
Ниже — учебный эталон, собранный из тех же заметок. Данные вымышленные.
| Раздел | Содержание |
|---|---|
| Цель | Допустить полную заявку с согласованной датой к работе |
| Вход | Письмо клиента в общую почту |
| Выход | Карточка «В работе» с датой и копией сообщения клиенту |
| Координатор | Создаёт карточку в день обращения; при неполных данных ставит «Ожидает данных» и запрашивает недостающее |
| Дизайнер | Проверяет полную заявку до конца следующего рабочего дня; при неясном сроке задаёт вопрос координатору |
| Руководитель | Согласует дату либо решает вопрос нестандартного формата |
| Координатор | Сообщает дату клиенту, сохраняет копию сообщения, переводит карточку в «В работе» |
| Исключение | До решения по нестандартному формату обычный маршрут остановлен |
| Открытый вопрос | Владелец версии в исходнике не назван |
Развилка описана явно: неполные данные уводят заявку в «Ожидает данных», полные — на проверку дизайнеру, нестандартный формат — руководителю с остановкой обычного маршрута.
Подтверждение результата — это след, по которому видно, что шаг выполнен. Для координатора это карточка с датой и копией сообщения; для дизайнера — отметка о проверке; для руководителя — согласованная дата. В обзоре Process Street по AI SOP software перечислены те же элементы контроля: версии, согласования, назначения на роли, обязательные поля и история выполнения.
Проверьте роли, сроки и исключения
Проверка идёт по трём спискам. Роли: у каждого действия назван исполнитель, полномочия каждой роли понятны. Сроки: у каждого шага есть привязка ко времени или событию. Исключения: у каждой развилки есть условие и путь возврата в основной маршрут.
Прогоните регламент по контрольным заявкам. Заявка A приходит во вторник в 10:00 без размера — ожидается карточка и статус «Ожидает данных», дата клиенту не обещана. Заявка B приходит во вторник в 10:00 с полными данными и обычным форматом — проверка дизайнера не позже конца среды, затем согласование руководителем; без согласования статус «В работе» не ставится. Заявка C приходит с нестандартным форматом — уходит руководителю, обычный маршрут остановлен.
Отрицательная проба: «назначить дату автоматически и сразу перевести в работу». Она отклоняется по двум основаниям — дата требует согласования руководителя, а нестандартный формат требует его решения.
Проверьте, что сроки не конфликтуют. В учебном примере координатор работает в день обращения, дизайнер — до конца следующего рабочего дня, руководитель согласует дату до передачи в работу. Рабочие дни — понедельник–пятница; праздники в примере не учитываются.
Отдайте владельцу на сверку и пройдите процесс по тексту
Выделите отдельный шаг для сверки. Владелец подтверждает три вещи: границы процесса, список ролей и правила развилок. Отдельно он закрывает вопросы, помеченные как «Требует решения владельца»: в учебном примере это имя владельца версии и срок ответа клиенту.
Пройдите процесс по тексту от начала до конца, как если бы вы выполняли его впервые. Каждый шаг должен быть выполним без устных пояснений. Если для шага нужно спросить коллегу, значит, в регламенте не хватает условия или ответственного.
В документации Scribe описан похожий цикл правок: после генерации документ редактируют, добавляют подсказки, обновляют шаги и аннотируют скриншоты, а затем делятся ссылкой или встраивают в другую документацию.
Зафиксируйте версию. У текста должны быть дата, автор правки и список изменений. В обзоре Process Street по AI SOP software в число требований к таким системам входят контроль версий, согласование перед публикацией и запись о том, какая версия действовала в момент выполнения работы.
Обновляйте версию при изменении процесса
Регламент устаревает в момент, когда меняется процесс: появляется новый инструмент, меняется роль или срок. Правило обновления простое: изменение процесса — новая версия текста с датой и описанием правки.
В справке Scribe указано, что SOP обновляют при каждом изменении процесса или практики, а проверку на точность полезно проводить регулярно, например в конце квартала. Там же перечислены частые ошибки: сложный язык, слишком много действий в одном шаге, непоследовательный формат и отсутствие обновлений.
Храните рядом с регламентом список открытых вопросов. Пункт, закрытый владельцем, переносится в текст; новый вопрос добавляется в список. Так открытые вопросы остаются на виду при каждом обновлении версии.
Частые вопросы
Как написать регламент с помощью нейросети, если есть только переписка в чате?
Соберите из переписки короткие утверждения по схеме «кто, что, когда» и удалите оценочные слова. Полученный текст вставьте в промпт как заметки. Модель соберёт структуру, а факты и сроки вы проверите вручную.
Что делать, если модель придумала срок или цену?
Удалите придуманное и добавьте запрет в промпт: «Не придумывай цену, SLA или программный интерфейс». Неизвестные места помечайте как «Требует решения владельца» и закрывайте их вместе с владельцем процесса.
Сколько ролей должно быть в регламенте одного процесса?
Столько, сколько реально участвует в маршруте. В учебном примере их три: координатор, дизайнер и руководитель. Каждая роль должна быть связана с конкретным действием или решением.
Чем отличается черновик от согласованной версии?
Черновик содержит пробелы и вопросы к владельцу. Согласованная версия содержит закрытые вопросы, дату, автора правки и список изменений. Публиковать черновик как рабочий документ нельзя.
Как часто обновлять регламент?
При каждом изменении процесса, а также при плановой проверке на точность. В справке Scribe назван ориентир — проверка в конце квартала. Дата последней проверки ставится в сам документ.