Автоматизация жизненного цикла клиента
Автоматизация жизненного цикла клиента сопоставляет события клиента с явно заданными переходами между этапами и задачами проверки с назначенными ответственными. Задайте подтверждения для входа на каждый этап и выхода из него, проверяйте поступающие события по этим правилам и рассматривайте предлагаемый переход до обновления записи клиента.
Этот пример подготавливает запись о решении по жизненному циклу. Он охватывает планирование состояний и поля аудита со ссылками на отдельные руководства по квалификации, онбордингу и подготовке материалов.
Автор: Ai Flowi · Опубликовано
пример конфигурации, а не результаты испытания
описано в каталоге; не проверено Ai Flowi в производственной среде
1. Определите состояния с проверяемыми критериями
Этап жизненного цикла должен описывать то, что ваша команда может проверить. Для каждого этапа запишите определение состояния, подтверждения входа и выхода и ответственную роль. Избегайте меток, которые подразумевают поведение клиента, не наблюдаемое в разрешённых исходных данных.
Для предлагаемых правил используйте состояния «запрос получен», «прошёл квалификацию для обсуждения», «онбординг согласован» и «активная проверка». Это иллюстративные бизнес-состояния, а не встроенные функции продукта. Перечислите разрешённые переходы и те, что требуют уточнения. Клиент может оставаться на этапе, пока выясняются недостающие подтверждения; неопределённость не требует принудительного перехода.
Ведите версии определения жизненного цикла. Более позднее изменение правил может сделать старую запись недостаточной для нового этапа, но не должно переписывать причину первоначального решения. Сохраняйте версию правил с каждым предложенным и утверждённым переходом.
2. Подготовьте требования к событию и текущему состоянию
Вам нужны разрешённый источник событий, известная запись текущего состояния, рабочее пространство и письменные правила переходов. Для первой конфигурации вручную передайте искусственно составленное событие и снимок его текущего состояния одним пакетом JSON. Включите идентификатор клиента, идентификатор события, тип события, время события, текущий этап, ссылку на источник и соответствующие подтверждения завершения.
Отличайте время события от времени получения и записывайте часовой пояс, когда важен порядок дат. Определите, как проверяются повторяющиеся идентификаторы и запоздавшие события. Событие, пришедшее после более нового решения, не должно автоматически перезаписывать это решение только потому, что было доставлено позже.
Для точных правил переходов доступ к модели не нужен. Если заметки о событии требуют интерпретации, настройте учётную запись провайдера и API-ключ через справочник подключения модели; этот провайдер взимает плату за интерпретацию заметок. Для любых последующих действий в Sheets используйте руководство по учётным данным , чтобы настроить разрешённый доступ Google вне пакета события.
3. Проверьте предложение по жизненному циклу
Передайте подготовленный пакет во вход data компонента JSON Operations. Задайте operations как "JQ Expression" и напишите проверенное выражение query для ожидаемой структуры, разрешённых типов событий, обязательных подтверждений и правил переходов. Возвращайте предложение с текущим этапом, запрошенным следующим этапом, применённым правилом, ссылками на источники и причиной проверки.
Требуйте известное текущее состояние до предложения перехода. Отсутствующая ссылка на клиента, неизвестный этап или отсутствие подтверждений предшествующего этапа должны приводить к исключению для проверки. Не создавайте текущее состояние из догадки модели и не трактуйте пустое поле как самый ранний этап жизненного цикла, если письменные правила явно не задают такой смысл.
Для точных типов событий решение о переходе может оставаться детерминированным. Если заметку о событии в свободной форме нужно интерпретировать, используйте Structured Output отдельно с полями для заявленных подтверждений события и неизвестных сведений. Проверьте извлечение до передачи принятых фактов в правило перехода; интерпретация текста не должна определять граф разрешённых состояний.
4. Направьте предложения на проверку назначенным ответственным
Используйте руководство по маршрутизации Condition для сравнения поля предложения по жизненному циклу review_status с ready.
Искусственно составленное событие завершения онбординга может прийти после более нового решения, переведшего клиента в состояние «активная проверка». Оцените событие отдельно относительно указанного в нём состояния и последнего состояния: старые подтверждения могут объяснять историю, не разрешая новый переход сейчас. Если правила допускают только переход из «онбординг согласован» в «активная проверка», событию, которое ссылается на «запрос получен», не хватает необходимого предшествующего состояния. Сохраните это предложение как исключение, даже если заметка о завершении звучит убедительно. Порядок поступления не должен стирать более позднее утверждённое решение или придумывать промежуточный этап.
Определите задачу проверки для каждого разрешённого перехода: ответственную роль, данные для проверки и действие, которое разрешает утверждение. Прикрепите ссылку на утверждённые материалы, когда этап требует подготовки информации для клиента. Выбор ссылки не отправляет материал и не подтверждает его получение клиентом.
При планировании жизненного цикла разделяйте состояния «событие наблюдалось», «переход предложен», «переход утверждён» и «запись обновлена». Ветка, дошедшая до Chat Output, означает показанное предложение. Ответственная команда всё ещё должна его утвердить, а позднее проверить любую запись данных. Не объединяйте эти состояния в один флаг «завершено».
5. Утвердите переход с учётом последнего состояния клиента
Покажите пакет решения по жизненному циклу в Chat Output, используя input_value для предложения, ожидающего утверждения. Непосредственно перед утверждением сравните предоставленный снимок с достоверным текущим состоянием клиента. Если появилось другое решение, оцените переход относительно более нового состояния вместо применения старого предложения без изменений.
Соблюдайте правила утверждения из контрольного списка готовности, сохранив с решением версию правил жизненного цикла, сравнение с последним состоянием и причину отступления от правил.
Только для сохранения статуса проверенный сценарий обновления статуса в Sheets показал 34 пройденные проверки из 34 выполненных. Передаваемый в нём текст статуса не обеспечивает соблюдение этих правил жизненного цикла. Любая запись перехода требует утверждения и отдельной проверки предполагаемой настройки сохранения.
6. Сохраните запись решения, пригодную для аудита
Ожидаемый результат содержит идентификаторы клиента и события, предыдущий этап, предлагаемый следующий этап, подтверждения входа или выхода, версию правил, ответственную роль, решение по проверке и результат записи, если он известен. Сохраняйте отклонённые предложения с причинами. Такая история позволяет проверяющему отличить недопустимый переход от допустимого, ожидающего недостающей информации.
Проверьте повторное событие, неизвестный этап, запоздавшее событие, отсутствие подтверждений входа и два предложения на основе одного старого состояния. Убедитесь, что каждый случай остаётся объяснимым и утверждение не означает сохранение. Успешная запись статуса не подтверждает актуальность снимка, использованного при утверждении; проверьте, не изменило ли состояние конкурирующее решение.
Считайте исправление утверждённого перехода новым решением по проверке с собственными подтверждениями. Удаление прежнего решения скрыло бы причину, по которой клиент оказался на записанном этапе. Если завершение онбординга позднее оспаривается, определите, какое подтверждение завершения отзывается, проверьте, какие последующие решения от него зависели, и передайте возникшее противоречие сотруднику, выполняющему ответственную роль. Эта рабочая таблица не отменяет последующие действия автоматически. Её полезный результат — история затронутых переходов и вопрос об уместном текущем этапе, без выдуманной операции отмены или переписывания хронологии событий.
Когда планирование этапов жизненного цикла клиента следует оставить ручным?
Эта схема не планирует контакты с клиентами, не поддерживает актуальное хранилище состояний и не гарантирует безопасность одновременных переходов. Если обновления жизненного цикла редки или требуют суждений за пределами предоставленных данных, проверенной рабочей таблицы может хватить. Используйте систему с надлежащим управлением состоянием и параллельными изменениями, когда запись клиента могут менять несколько участников.
Работу для отдельных этапов оставьте в соответствующих руководствах: подтверждения для квалификации, задачи онбординга и материалы для развития отношений с лидами. Эти правила жизненного цикла определяют подходящую задачу проверки; они не повторяют процессы генерации материалов.
Подтверждающие данные событий и входные данные для предложения по жизненному циклу
| Компонент | Точные имена входов | Настройки для подготовки | Выходной порт |
|---|---|---|---|
| JSON Operations | data, operations, query | Используйте предоставленный пакет события и текущего состояния и проверенные правила переходов; выдавайте review_status и поля аудита. | data_output |
| Condition | data_input, key_name, operator, compare_value | Задайте operator как "equals" для сравнения review_status с ready; явно отделяйте исключения жизненного цикла. | true_output |
| Chat Output | input_value | Покажите предлагаемый переход и задачу проверки с назначенным ответственным, не считая это утверждением. | message |
| Structured Output | input_value, model, output_schema, system_prompt | Необязательная отдельная интерпретация текста: извлеките подтверждения события и неизвестные сведения до оценки правил. | structured_output |
| Language Model | model, api_key | Настройте доступ к провайдеру только для необязательного пути извлечения из заметок. | model_output |
| Upsert Row | google_account, spreadsheet_id, sheet_title, key_column, row_data, value_input_option | Необязательная отдельно проверенная запись аудита: используйте event_id как ключ, подготовьте row_data и значения "RAW"; отдельно проверьте одновременную запись. | result |
Расход токенов при автоматизации жизненного цикла клиента
Тарифы: 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 и моделей не включено.