Notification KPIs: measure a consistent workflowKPI уведомлений: считайте один и тот же процесс
A high delivery rate says little about the workflow if some orders never generated a notification. A large send count may reflect retries, and an opened email does not establish collection or acceptance of a new appointment time. A useful report connects three levels: events requiring communication, messages for those events and expected customer actions. Each level needs its own denominator and observation window.Высокая доля доставки мало говорит о процессе, если часть заказов вообще не создала уведомлений. Большое число отправок может означать повторы, а открытое письмо не доказывает, что клиент приехал или подтвердил перенос. Полезный отчёт связывает три уровня: события, по которым требовалась связь, сообщения по этим событиям и ожидаемые действия клиента. Для каждого уровня нужны собственный знаменатель и время наблюдения.
Start with events requiring communicationНачните с событий, требующих сообщения
Define the unit of observation first: a verified event for a particular order, recipient and communication purpose. One order can produce several distinct events, while receiving the same event again does not create another. Keep the event identifier and rule version establishing the communication requirement. Otherwise, a configuration change during the week may appear to improve performance when it only changes which cases are counted.Сначала определите единицу наблюдения: подтверждённое событие по конкретному заказу, получателю и цели сообщения. Один заказ может породить несколько разных событий, а повторная доставка того же события не создаёт новое. В отчёте сохраняйте идентификатор события и версию правила, по которому сообщение требовалось. Иначе изменение настройки посреди недели может выглядеть как улучшение результата, хотя изменился только состав учитываемых случаев.
Show the path from all qualifying events to messages created. Separate queued work, missing contacts, contact restrictions and suppression of obsolete messages. Each exception needs a reason and must not silently disappear from the original cohort. Build the cohort by business-event time and update outcomes as they arrive. Display the report’s refresh time and the source of any delayed data alongside it.Показывайте путь от всех подходящих событий к созданным сообщениям. Отдельно видны очередь, отсутствующий контакт, остановка по ограничению связи и отмена устаревшего сообщения. У каждого исключения есть причина; его нельзя незаметно убрать из исходной группы. Группу формируйте по времени бизнес-события, а результаты дозаполняйте по мере поступления. Рядом укажите момент обновления отчёта и источник задержанных данных.
Keep messages separate from attemptsНе смешивайте сообщения и попытки
A logical message may have several attempts. Count them separately: attempts explain channel workload, while unique messages with evidenced outcomes explain customer coverage. Provider acceptance is not delivery, and delivery is not reading. If a channel does not supply a particular signal, retain an unknown result and label the limitation. Do not replace missing confirmation with either assumed success or automatic failure.Для логического сообщения может существовать несколько попыток. Считайте их отдельно: нагрузку канала объясняют попытки, охват клиента — уникальные сообщения с проверенным результатом. Принятие запроса сервисом не равно доставке, а доставка не равна прочтению. Если канал не предоставляет определённый сигнал, оставьте результат неизвестным и подпишите ограничение. Не заменяйте отсутствие подтверждения успехом или автоматическим отказом.
In a hypothetical example, 120 events required communication, 100 messages were sent and 20 await review. Of those sent, 90 have confirmed delivery, 6 failed and 4 remain unknown: 90 + 6 + 4 = 100. Confirmed coverage of the original cohort is 90 / 120 × 100 = 75%. Reporting only on sent messages hides events where communication has not started. These figures illustrate the calculation, not a SABSUS result.Учебный пример: по 120 событиям требовалось сообщение, 100 отправлено, 20 ожидают разбора. Среди отправленных подтверждена доставка 90, отказ получен по 6, результат 4 неизвестен: 90 + 6 + 4 = 100. Подтверждённый охват исходной группы равен 90 / 120 × 100 = 75%. Отчёт только по отправленным скрывает события, на которых связь ещё не началась. Эти цифры иллюстрируют расчёт, а не результат SABSUS.
Separate event delay from channel delayРазделите задержку события и канала
The timeline includes event occurrence, system receipt, message queuing, send attempt and delivery confirmation. A long event-to-delivery time may originate before notification: staff recorded readiness late or the source transmitted data slowly. Separate intervals identify who can address the cause. Agree on time zones and missing timestamp handling before comparing locations. Otherwise, apparent channel delays can conceal upstream operational problems.Временная линия включает возникновение события, его получение системой, постановку сообщения в очередь, попытку отправки и подтверждение доставки. Большое время от события до доставки может возникнуть ещё до уведомления: сотрудник поздно подтвердил готовность или источник передал данные с задержкой. Раздельные интервалы показывают, кто способен исправить причину. Согласуйте часовые пояса и обработку отсутствующих отметок, прежде чем сравнивать подразделения.
Do not rely only on average times for completed messages. Show the delay distribution and age of unfinished work, especially the oldest exception. If only delivered messages count, long-running failures disappear from the timing metric. Set operational thresholds from customer commitments and the workflow’s hours. A breached threshold should lead to identifiable events, an owner and the next review deadline rather than merely colouring a total.Не ограничивайтесь средним временем завершённых сообщений. Покажите распределение задержек и возраст незавершённой очереди, особенно самое старое исключение. Если считать только доставленное, длительно застрявшие случаи не ухудшат показатель и станут незаметными. Рабочий порог задают из обещания клиенту и режима процесса. При превышении отчёт должен открывать конкретные события, ответственного и следующий срок проверки, а не только окрашивать итог.
Measure action within a suitable windowИзмеряйте действие в подходящем окне
An order-received message may require no customer action. A request to select a time expects a confirmed choice; a pickup-ready message can be connected to physical collection under the established process. Define the expected action in advance and link it to the same order. A link click remains an intermediate signal. Comparing every notification type by clicks is misleading because the messages serve different purposes.Для сообщения «заказ получен» клиентское действие может вообще не требоваться. Для предложения выбрать время результатом будет подтверждённый выбор, для готовности к выдаче — фактическое получение по принятому процессу. Определите ожидаемое действие заранее и свяжите его с тем же заказом. Переход по ссылке остаётся промежуточным сигналом. Сравнивать все типы уведомлений по кликам некорректно: у них разные задачи.
For a settled assessment, use events whose full observation window has elapsed. Display recent messages separately as a cohort still awaiting outcomes. Handle cancellations and order changes with an explicit rule while preserving original membership. Higher collection after notification does not establish causation: product mix, readiness times or collection arrangements may have changed. Compare similar periods and record those changes before attributing improvement to messaging.Для завершённой оценки берите события, у которых прошло полное окно наблюдения. Недавние сообщения показывайте отдельно как ещё незрелую группу. Учитывайте отмены и изменения заказа с явным правилом, сохраняя исходный состав. Рост доли получения после уведомления не доказывает его причинный эффект: могли измениться ассортимент, сроки готовности или условия выдачи. Сравнивайте похожие периоды и отмечайте такие изменения до вывода об улучшении.
Reconcile the totals with individual casesСверьте итог с отдельными случаями
When reviewing SABSUS, request a selected event cohort and reconstruct its metrics manually. Include a retry, unknown delivery, late response and suppressed message. Verify which source timestamps and report definitions are available in the selected configuration. Acceptance succeeds when a manager can explain a discrepancy down to an individual case and the duty employee can see the work required. An attractive percentage alone is insufficient.При проверке SABSUS попросите показать одну выбранную группу событий и восстановить из неё показатели вручную. Включите повтор, неизвестную доставку, поздний ответ и отменённое сообщение. Уточните доступность исходных отметок и определения отчёта в выбранной конфигурации. Приёмка успешна, когда руководитель объясняет расхождение до конкретного случая, а дежурный видит работу, которую нужно выполнить. Красивый процент без такого перехода недостаточен.
Ownership of messages and exceptionsОтветственность за сообщение и исключение · Measuring changes in team workloadКак измерить изменение нагрузки команды
Quick answersКороткие ответы
Why can high delivery coexist with poor coverage?Почему высокая доставка не означает полный охват?
The denominator may contain only sent messages. Events without a created message and unresolved exceptions then fall outside the metric.В знаменателе могут быть только отправленные сообщения. События без созданного сообщения и неразобранные исключения тогда остаются за пределами показателя.
Does a retry increase coverage?Повторная попытка увеличивает охват?
It increases the attempt count. Coverage changes only when a unique message receives the defined outcome confirmation.Она увеличивает число попыток. Охват меняется, только когда уникальное сообщение получает предусмотренное подтверждение результата.
How should missing delivery confirmation be handled?Что делать с отсутствующим подтверждением доставки?
Show the outcome as unknown and explain which evidence the channel supplies. Investigate through the established process rather than substituting a guess.Показывать неизвестный результат отдельно и объяснять, какой сигнал предоставляет канал. Проверять его по установленному процессу, не подменяя догадкой.