Автоматизация онбординга клиентов
Автоматизация онбординга клиентов превращает согласованные требования клиента в повторяемый список задач по настройке с распределённой ответственностью и зависимостями. Начните с утверждённой библиотеки задач, сопоставьте её с предоставленными требованиями и проверьте недостающие данные, прежде чем кто-либо приступит к выполнению списка.
Пример ниже подготавливает план онбординга для утверждения человеком. Его результат — список задач с распределённой ответственностью; создание учётных записей, назначение встреч и доставка приветственных сообщений здесь не рассматриваются.
Автор: Ai Flowi · Опубликовано
пример конфигурации, а не результаты испытания
описано в каталоге; не проверено Ai Flowi в производственной среде
1. Отделите согласованный объём работ от запрошенного
Соберите принятый объём работ, требования клиента и текущий статус настройки. Запрошенная клиентом интеграция должна оставаться в плане запросом, пока ответственная команда не подтвердит, что она включена в объём работ. Сохраняйте это различие в результате, чтобы черновик случайно не обещал выполнение работ.
Создайте библиотеку задач с идентификатором задачи, правилом применимости, обязательными входными данными, предшествующими задачами, ответственной ролью и подтверждением завершения. Отделяйте роли от конкретных исполнителей: модель может выбрать утверждённую роль, но человека должен назначить руководитель команды. Срок становится обязательством только после того, как кто-то его принял.
2. Подготовьте разрешённые входные данные и доступ
Подготовьте рабочее пространство и утверждённую библиотеку задач онбординга. Настройте учётную запись провайдера и API-ключ по справочнику учётных данных модели; провайдер взимает плату за обращения к модели для выбора задач. Для первого черновика вставьте разрешённый пакет требований в Chat Input. Укажите версию объёма работ и идентификаторы источников, не включая учётные данные и закрытые ссылки доступа.
Если библиотека находится в Knowledge Base, до создания черновика сравните найденные идентификаторы задач с утверждённой библиотекой. Проверьте выбранный knowledge_base и возвращённые источники: поиск может пропустить обязательную задачу, поэтому одна лишь релевантность источника не подтверждает, что список онбординга охватывает все необходимые действия.
Отделяйте принятие списка задач от готовности учётных данных: команда может утвердить последовательность задач, пока доступ к месту публикации остаётся неразрешённым. Зафиксируйте нерешённый вопрос с доступом при передаче на публикацию вместо отметки о завершении задач настройки клиента.
3. Составьте пакет сопоставления требований и задач
Настройте Knowledge Base.search_query для поиска задач, относящихся к утверждённому продукту и требованиям клиента, и включите include_metadata для ссылок на источники. Задайте осмысленное значение top_k , подходящее для вашей библиотеки задач, затем проверьте пропущенные записи. Отдельно включите общие обязательные задачи из утверждённой библиотеки, чтобы поиск не определял само наличие обязательного требования.
Используйте справочник полей Parser для оформления найденных записей задач в пакет онбординга.
В вымышленном запросе на настройку предположим, что утверждённой задаче нужен идентификатор ресурса от клиента и что она зависит от проверки доступа. Пакет требований содержит идентификатор, но не завершённую проверку доступа. Включите задачу настройки с сохранением зависимости и отметьте, что она заблокирована до подтверждения доступа; не исключайте её из-за невозможности начать сейчас. Если поиск вернул задачу настройки без обязательной предшествующей задачи, найдите эту задачу в библиотеке до составления порядка работ. Так можно отличить неполный результат поиска от недостающей информации клиента.
Для первоначального предложения проверяющий может объединить этот пакет с требованиями клиента и вставить общий текст в Chat Input. Такая явная передача не позволяет утверждать, что одна лишь совместимость портов объединяет несколько документов или сохраняет нужный порядок.
4. Сформируйте список задач онбординга с ограничениями
Направьте пакет требований из порта Chat Input message во вход извлечения списка задач Structured Output input_value. Его вход model получает выход Language Model model_output. Определите output_schema для идентификатора задачи, ссылки на требование, предлагаемой ответственной роли, идентификаторов предшествующих задач, недостающих данных, подтверждения завершения и статуса проверки.
Настройте system_prompt так, чтобы задачи выбирались только из предоставленной библиотеки. Требуйте записи о недостающих данных, если клиент не сообщил необходимую подробность. Укажите модели сохранять зависимости и отмечать требования без утверждённой подходящей задачи; она не должна придумывать задачу, системное разрешение или дату завершения ради закрытия пробела.
Автоматизация списка задач онбординга клиентов должна отличать задачи, готовые к выполнению, от заблокированных задач. Наличие предшествующей задачи в списке не означает её завершение. Сохраняйте зависимую задачу заблокированной до проверки подтверждения завершения и отличайте задачи, для которых нужны сведения от клиента, от задач, требующих внутреннего решения об объёме работ.
5. Проверьте ответственность и порядок зависимостей
Проверьте предлагаемый список задач в Chat Output, передав его JSON на input_value. Сравните идентификаторы задач с библиотекой, проверьте, есть ли для каждого утверждённого требования задача или зафиксированный пробел, и найдите циклические зависимости. Ответственный участник команды назначает людей и согласовывает плановые сроки после проверки полноты охвата.
Храните проверенный список задач вместе с неразрешёнными вопросами. Внешне полный список может вводить в заблуждение, когда задачи зависят от неизвестных разрешений доступа. Не отмечайте задачу завершённой только потому, что создан документ; для завершения нужны подтверждения, заданные в библиотеке задач.
ИИ-чат-бот для онбординга клиентов может собирать уточнённые требования, но эти ответы всё равно требуют проверки списка задач. Приём данных через Chat Input и показ через Chat Output здесь работают внутри Playground. Развёртывание в канале взаимодействия с клиентами требует работ с отдельно определённым объёмом за пределами этой конфигурации.
6. Отдельно подготовьте утверждённый документ
Используйте общую процедуру подготовки документа и обработки сбоев; для этого списка задач перенесите утверждённые идентификаторы задач, принятые назначения, зависимости и недостающие данные в initial_text, указав принятую версию объёма работ в title.
Связанный сценарий создания документа из формы сообщает о результате: Пройдены 42/42 проверки
после преобразования CR+LF в LF для проверенных полей формы и создания документа; этот результат не охватывает поиск задач, выбор зависимостей и утверждение онбординга.
Отличайте неприменимую задачу от задачи, исключённой из-за нерешённого вопроса об объёме работ. Например, требование клиента может упоминать вариант услуги, который ещё не принят. Сохраните требование как вопрос об объёме и укажите любую утверждённую задачу, которая применялась бы при принятии этого варианта; не назначайте такую условную работу как обязательство. Если объём меняется после проверки, пересмотрите затронутые правила применимости и зависимости вместо добавления произвольной задачи. Утверждённая библиотека остаётся основой выбора, а новая версия объёма объясняет изменение списка.
Каковы проверки при принятии и ограничения автоматизации адаптации клиентов?
Готовый результат должен содержать исходную версию объёма работ, выбранные задачи, порядок зависимостей, утверждённые назначения, подтверждения завершения и видимый список недостающих данных. Используйте искусственно составленные пакеты с неподдерживаемым запросом, отсутствующими сведениями о разрешениях, противоречивыми требованиями и пустой библиотекой задач. Принимайте черновик только тогда, когда неподдерживаемая работа остаётся отмеченной, а обязательные задачи сохраняют зависимости.
Предоставление доступа, создание ресурсов и обязательства по доставке требуют отдельно утверждённой работы за пределами этого черновика списка задач. Если все клиенты используют одинаковый список без выбора задач, фиксированного документа может хватить. Для изменений после онбординга используйте руководство по планированию жизненного цикла для определения переходов между этапами вместо превращения списка задач в неявный механизм жизненного цикла.
Выбор задач из библиотеки и входные данные для списка задач клиента
| Компонент | Точные имена входов | Настройки для подготовки | Выходной порт |
|---|---|---|---|
| Knowledge Base | knowledge_base, search_query, top_k, include_metadata | Найдите утверждённые задачи онбординга, сохраните метаданные источников и проверьте полноту поиска. | retrieve_data |
| Parser | input_data, mode, pattern | Выберите "Parser" для оформления фактических столбцов задач в утверждённый пакет онбординга. | parsed_text |
| Chat Input | input_value | Вставьте пакет задач вместе с согласованными требованиями клиента для подготовки черновика. | message |
| Language Model | model, api_key | Выберите разрешённый доступ к модели для извлечения данных онбординга. | model_output |
| Structured Output | input_value, model, output_schema, system_prompt | Ограничьте выбор идентификаторами задач и ролями из утверждённого пакета. | structured_output |
| Chat Output | input_value | Покажите зависимости задач, недостающие данные и предлагаемые роли для утверждения. | message |
| Create Document | google_account, title, initial_text | Необязательный отдельный шаг: создайте документ онбординга из утверждённого заголовка и текста списка задач. | document |
Расход токенов при автоматизации онбординга клиентов
Тарифы: Go от USD8 в месяц при годовой оплате (USD10 помесячно), Plus от USD16 (USD20 помесячно), Pro 100 от USD80 (USD100 помесячно), Pro 200 от USD160 (USD200 помесячно) и Pro 500 от USD400 (USD500 помесячно), от 5,000 до 250,000 Flowi Tokens в месяц с возможностью пополнения; 1 токен за каждый запуск узла; использование сторонних API и моделей не включено.