When to trigger a post-purchase follow-upКогда запускать follow-up после покупки
Post-sale automation needs more than a newly created sale record. The order may be unfulfilled, payment unresolved, or a member of staff may already have replied. Define the event, conditions and cancellation rules before configuring a send. Each trigger can then be explained and tested.Автоматизация после продажи должна знать больше, чем факт создания чека. Заказ мог не исполниться, платёж — остаться неизвестным, а клиент — уже получить ответ от сотрудника. Опишите событие, условия и отмену действия до настройки отправки. Тогда каждое срабатывание можно будет объяснить и проверить.
Define the event and its authoritative sourceОпределите событие и источник результата
For a feedback request, define what completed service means. Payment, collection and delivery are different events; the appropriate moment depends on the workflow. Record the status source, order identifier and event time. Importing old sales should not automatically be interpreted as completion today.Для запроса обратной связи определите, что означает завершённое обслуживание. Оплата, выдача и доставка — разные события; нужный момент зависит от процесса. Запишите источник статуса, идентификатор заказа и время события. Импорт старых продаж не должен автоматически восприниматься как сегодняшнее завершение.
Separate eligibility from execution: an event may create a staff task when there is insufficient information to message a customer. Confirm supported events and data-transfer delays. Without a reliable signal, use human review rather than substituting an approximate status.Разделите условие отбора и действие: событие может лишь создать задачу сотруднику, если данных недостаточно для сообщения. Уточните поддерживаемые события и задержки обмена. При отсутствии надёжного сигнала выбирайте проверку человеком, а не подменяйте его приблизительным статусом.
Recheck eligibility immediately before actionПроверяйте условия перед самым действием
Eligibility should include the relevant purchase type, verified profile and permitted channel. Before sending, recheck refunds, complaints, messaging opt-outs, existing appointments and recent contacts. Conditions may have changed since the queue was built, so initial selection alone is insufficient.В отбор включите нужный тип покупки, подтверждённый профиль и разрешённый канал. Перед отправкой повторно проверьте возврат, жалобу, отказ от сообщений, уже назначенный визит и недавние контакты. Условия могли измениться после создания очереди, поэтому исходного отбора недостаточно.
Define an unambiguous order for exclusions. For example, an active service issue goes to its owner instead of a repeat-purchase invitation. Keep the reason with the decision so staff can see why an action did not occur. Not every exclusion is a technical failure.Порядок исключений должен быть однозначным. Например, активный сервисный вопрос направляется его владельцу, а не в приглашение к повторной покупке. Храните причину пропуска рядом с решением, чтобы сотрудник видел, почему действие не произошло. Не считайте все исключения техническими ошибками.
Segment selection and contact rulesОтбор клиентов и правила контакта
Distinguish repeated events from new purchasesНе путайте повтор события и новую покупку
An order can emit the same update more than once. Define a key linking the action to the order and workflow type, then verify how the configuration prevents repetition. A telephone number alone is insufficient: different purchases by one person may require separate legitimate service actions.Один заказ может прислать обновление несколько раз. Определите ключ, связывающий действие с заказом и типом сценария, и проверьте, как конфигурация предотвращает повтор. Не используйте только телефон: разные покупки одного человека могут законно требовать разных сервисных действий.
An unknown sending result does not mean nothing was sent. Check available channel acknowledgment and the action log before retrying. Distinguish a created task, a send attempt, confirmed delivery and a customer reply. These states should not collapse into a single “processed” measure.Неизвестный результат отправки не равен неотправленному сообщению. Перед повтором проверьте подтверждение в доступном канале и журнал действия. Разделите созданную задачу, попытку отправки, подтверждённую доставку и ответ клиента. Эти состояния нельзя сворачивать в один показатель «обработано».
Handle changes and stopping the workflowОбработайте изменения и остановку сценария
A refund after queue creation, profile correction or preference change should be reevaluated before execution. Specify which actions cancel, which transfer to staff and how sent-message history remains visible. Changing a rule should not rewrite the explanation of an earlier decision.Возврат после создания очереди, исправление профиля или изменение предпочтений должны повторно оцениваться до исполнения. Опишите, какие действия отменяются, какие переводятся сотруднику и как сохраняется уже отправленная история. Изменение правила не должно переписывать объяснение старого решения.
Assign an owner and a way to stop new actions when behavior is unexpected. After a correction, review the accumulated queue so resuming does not send stale invitations. Confirm pause controls, rule versions and available logging before enabling the workflow.Назначьте владельца сценария и способ остановить новые действия при неожиданном поведении. После исправления проверьте накопленную очередь: возобновление не должно отправлять устаревшие приглашения. Возможность приостановки, версии правил и доступный журнал уточняют в системе до включения процесса.
Test triggers and the useful outcomeПроверьте срабатывания и полезный результат
Count eligible events, exclusions, executed actions and failures separately. Measure repeat purchases over a consistent observation period without attributing every return to automation. Also track contact opt-outs and erroneous repeated messages.Считайте подходящие события, исключённые случаи, выполненные действия и ошибки отдельно. Долю повторных покупок измеряйте по одинаковому периоду наблюдения, не приписывая весь возврат автоматизации. Следите также за отказами от контакта и ошибочными повторными сообщениями.
Acceptance includes a repeated event, late refund, changed contact, unknown sending result and a staff reply before execution. Define the expected action and checkable evidence for each case. Accept the workflow based on those outcomes, not merely an enabled switch.Приёмка включает повтор одного события, поздний возврат, смену контакта, неизвестный результат отправки и ответ сотрудника до запуска. Для каждого случая заранее определите ожидаемое действие и проверяемый след. Сценарий принимают по этим исходам, а не по наличию включённого переключателя.
How history changes the retention decisionКак история меняет решение об удержании
Quick answersКороткие ответы
Should every purchase trigger a message?Нужно ли отправлять сообщение после каждой покупки?
No. Establish its purpose, timing and exclusions first. Repeated or frequent purchases may require frequency limits, while an open issue may need staff handling.Нет. Сначала определите пользу, подходящий момент и исключения. Повторные или частые покупки могут требовать ограничения частоты, а открытая проблема — участия сотрудника.
Can a send be retried after a timeout?Можно ли повторять отправку при тайм-ауте?
Only after checking the previous attempt and the agreed retry rule. A timeout may indicate a delayed acknowledgment rather than an unsent message.Только после проверки результата предыдущей попытки и предусмотренного правила повтора. Тайм-аут может означать задержку подтверждения, а не отсутствие отправки.
Where could AI fit in this workflow?Где использовать AI в таком процессе?
If available, evaluate drafting or classification with factual checks. Contact eligibility, order state and allowed actions should remain grounded in verifiable rules and data.Если функция доступна, можно проверить подготовку текста или классификацию с контролем фактов. Право на контакт, состояние заказа и допустимость действия должны опираться на проверяемые правила и данные.