VetFamily: изпълними Klaviyo flow спецификации (25.09.2026)

Нищо от този документ не е пуснато в Klaviyo. Всяка промяна изисква одобрение на собственика и минава през migration plan-а в края (draft, QA, изключване на стария flow, без дублиране). Базирано на EMAIL-STRATEGY-BG.md (решенията там са задължителни, несъгласия са флагнати отделно накрая), audit/, data/, analysis/ в тази папка, revenue-system-2026-09-16/FLOW-PLAYBOOKS.md и SEGMENTS-AND-ROUTING.md (по-стара спецификация, доразвита тук), review-2026-09-15/klaviyo-ids.json (14 съществуващи native шаблона), CURRENT-SCOPE.md.

Метрики (потвърдени в акаунта): Placed Order Ra8Kp7, Checkout Started VUpmhV, Started Checkout S7c3Ma (по-богат payload, виж EVENT-KEYS.md), Added to Cart UziSrr (жив, ~800+ event/мес; старият TfZ9cH е мъртъв, 0-33/мес), Viewed Product SRVnyc, Fulfilled Order WxqpUy, Delivered Shipment SEgEQc.

Продуктови ID (правило: филтрираме по ProductID, не по име): Артро Плюс 30 табл. 8357886263644, Омега 3 (масло) 8756703494492, Бурканите 14763697996124, Вълчан 15152759505244, Пробиотик 9500559933788.

Сегменти (потвърдени размери, audit/SEGMENT-COUNTS.csv): Engaged 90D QNyJe6 4050, Engaged 30D Te4HJu 2203, Unengaged 180D Wemjib 1873, Suppress Email Engage VCyUFv 1918, VIP VgiZyH 1876, NO Marketing UBKsQt 33843 (глобален suppression), List cleaning Wkf6ds 8833, Купили Артро VVzXcp 1979, Купили Омега XBtgj2 12860, Котки SgwpLN 13478 (извън обхват, не се ползва).

Съществуващи 14 native шаблона (klaviyo-ids.json, VF BP V2): W01 SAMccp Добре дошли, W02 UQXBCH Избор по нужда, W03 Tm3Kmh Писмо от лекаря, W04 Yz4TbW Помощ при избор, B01 RYADDz Разгледан продукт, B02 WqkeaP Помощ преди покупка, B03 TPCMkV Последващо писмо, P01 UXBS8C Благодаря за поръчката, P02 TCWwxY Как върви, R01 VbuD2h Проверка на наличното, C01 TyMLfu Стълбите, C02 V3DSrE Погледнете етикета, C03 TKAM3T Артро и Омега, C04 Skib7R Лично писмо Омега. Това са source шаблони от предишен пакет, не доказателство че вече са вързани към live съобщения, изисква проверка при build.

Потвърдени флагове (GraphQL read 25.09.2026), важни за цялата стратегия: welcome оферта има 3 активни Shopify code batch-а с различен %: най-стар (2023-07-27) = 15%, двата по-нови (2025-04-08 и 2026-05-16) = 10% — все още неразрешено кое остава единствено; код fullmargin (100% отстъпка, ACTIVE, без usage limit, стартирал 2024-12-12, риск, извън обхвата на този документ да се маха); Артро наличност 16 бр. потвърдени на живо (срещу собственическа оценка 60-66); дозировка на ТЕКУЩАТА 30-табл. Артро формула вече е потвърдена (arthro-theme-content.json, SKU 9.3, виж по-долу).

1. Обобщена таблица

2. Общ договор за всеки flow (важи за всички по-долу, не се повтаря всеки път)

• Вход изисква MARKETING_ELIGIBLE: subscribed, не в UBKsQt NO Marketing, не в Wkf6ds List cleaning, валиден пазар (BG).
• Всяко писмо проверява наново преди изпращане: consent, suppression, нова поръчка, refund/cancel, активен проблем (оплакване), наличност, изтекла оферта.
• Purchase exit е задължителен на всеки recovery flow (F02-F05): Placed Order спира веднага, дори при неплатен COD.
• Frequency cap (раздел 8 от стратегията): максимум 1 маркетингово писмо/ден от кампании, максимум 5/7 дни общо (кампании + flows), Smart Sending 16ч кампании / 24ч flows с оферта.
• Приоритет при застъпване: транзакционно > checkout (F05) > cart (F04) > browse (F03) > onboarding след доставка (F07) > replenishment (F09) > welcome опашка (F01) > кампания > cross-sell (F10) > winback (F12).
• Никой flow не пуска отстъпка, която не съществува проверено в Shopify (виж data/OFFERS-VERIFIED.csv за кое е safe_for_email).

F01. Welcome (P0)

Основа: Uis229 (live, 32 702,77 €/365д, 3,47 €/получател). Шаблони W01-W04.

Цел: нов абонат избира продукт по нужда и прави първа поръчка с една, непротиворечива оферта.

Допустимост: нов валиден абонат, 0 успешни поръчки (lifetime Placed Order = 0), subscribed, BG пазар.

Тригер: Added to List (welcome list/popup). Ако абонатът вече е купувач (напр. купил като гост, после се абонира), не влиза в discount версията, а в customer education вариант (виж F01-E1b).

Профилни филтри: Pet property съществува ли (Куче / Котка / Имам и двете / неизвестно) - определя клона.

Изключения: профил с активна поръчка същия ден не получава welcome discount push (приоритетът е на транзакционното писмо).

Изход: всяка поръчка спира веднага останалите welcome писма с оферта; профилът минава в F06/F07.

Smart sending: 24ч (има оферта).

Стъпки

Писма

KPI: база 3,47 €/получател, 32 703 €/365д (audit/KEEP-IMPROVE-REPLACE-RETIRE.csv); Email 1 куче VJFRZs е топ по RPR в целия акаунт (7,77 €). Хипотеза за тест: единна оферта (без 10%/15% разминаване) намалява объркването в чата на клиента и unsub-a на E1, без обещан % ръст, докато няма A/B данни.

QA сценарии: 1) абонат купува между E1 и E2 → E2-E4 не тръгват, вижда F06/F07; 2) Pet = "Имам и двете" → влиза в комбиниран клон, не в dog-only; 3) абонат без Pet property → вижда избор, не dog реклама; 4) вече unsubscribed преди E1 изпращане → suppress; 5) абонат от Wheelio (Syt2Dm) абонамент → влиза само веднъж в общата логика, не дублира welcome; 6) COD поръчка направена преди E4 → E4 не излиза, зачита се като покупка.

Зависимости: [РЕШЕНИЕ] на собственика за 10% срещу 15% преди публикуване (потвърдено с GraphQL read 25.09.2026: 3 активни Shopify code batch-а — 2023-07-27=15%, 2025-04-08 и 2026-05-16=10%; препоръка 10%, тъй като е по-новите два batch-а); премахване на клиника-текста от W01 template; довършване на draft E2/E3 за cat и both-pets клонове (XzwZgG, RdDLBh, Wpya7T, Wv2auz в момента draft).

F02. Site abandon (P2)

Статус: липсва в акаунта, нов.

Цел: леко напомняне за посетител без конкретен продуктов интерес (сесия без Viewed Product/Add to Cart, но със site engagement сигнал, ако е налична такава метрика).

Допустимост: абонат, посетил сайта, без Viewed Product/Cart/Checkout събитие в последните 24ч, без покупка.

Тригер: [ПРОВЕРИ] дали в акаунта има собствена site-session метрика; ако не, F02 отпада до техническа проверка и приоритетът остава P2.

Стъпки: 1 писмо T+24ч с общ избор (стави/козина/хранене), 1 писмо T+72ч само ако няма продуктов интерес по-нататък (иначе преминава в F03).

Писма: F02-E1 общ избор, нов модул, без оферта. F02-E2 напомняне, нов модул.

KPI: без база (нов flow); хипотеза за тест: допълнителни кликове към продуктови страници спрямо контрол, не приход директно (твърде общ сигнал за приходна атрибуция).

QA сценарии: 1) профил веднага гледа продукт → преминава в F03, не получава F02-E2; 2) без email consent → не влиза изобщо; 3) вече в welcome опашка → welcome има приоритет; 4) unsub между E1 и E2 → suppress; 5) видима поръчка между E1 и E2 → purchase exit.

Зависимост: потвърждение дали има подходяща тригер метрика в акаунта; иначе остава на хартия.

F03. Browse abandon (P1)

Основа: SnMJWv (live, 24 114,20 €/365д, 1,10 €/получател, keep в KEEP-IMPROVE-REPLACE-RETIRE.csv).

Цел: връща вниманието към конкретния разгледан продукт, без ескалация на отстъпка.

Допустимост: Viewed Product събитие, без Added to Cart/Checkout/Placed Order след него.

Тригер: Viewed Product SRVnyc. Динамични полета налични: Name/ProductName, ImageURL, URL, Price, Currency (EVENT-KEYS.md).

Профилни филтри: re-entry минимум 14 дни и ново разглеждане (по стратегия и по FLOW-PLAYBOOKS F02).

Изключения: Added to Cart/Checkout/Placed Order по същия продукт след тригера спира flow-а (приоритет на F04/F05).

Изход: cart, checkout или поръчка прекратяват веднага.

Стъпки

Писма: F03-E1 B01 RYADDz (Разгледан продукт), F03-E2 B02 WqkeaP (Помощ преди покупка), F03-E3 B03 TPCMkV (Последващо писмо). Без нова оферта, ако собственикът не реши друго.

KPI: база RPR 365д: UbdCsY 1,11 €, RWVYJv 1,03 €, VetesB 1,17 € (audit/FLOW-MESSAGE-PERFORMANCE.csv), общо 8 390 + 7 557 + 8 167 € = ~24,1 хил. €/365д. Хипотеза: продукт-специфичен клон (Артро/Омега) вдига click rate спрямо общия текст, тества се без предвиден %.

QA сценарии: 1) разгледал Артро, после купил Омега → exit по всяка поръчка, не само по продукта; 2) разгледал 2 продукта в 1 сесия → само последният активира клона; 3) ProductID не в каталога (напр. спрян SEREBRO) → generic fallback, не се показва спрян продукт; 4) unsub между E1 и E2; 5) вече в welcome discount опашка → welcome приоритет по-висок.

Зависимост: none извън копи/дизайн ревизия.

F04. Cart abandon (P1)

Основа: WQv2gW "SM | Abandoned Cart Flow - Middleware" (live, 16 868,08 €/365д, 2,99 €/получател, improve). VFRwq4 "SHOPIFY" вариант е retire (мъртва метрика TfZ9cH, 0 €/365д).

Цел: връща конкретната изоставена количка с точен продукт/линк.

Тригер: Added to Cart UziSrr (единствената жива метрика; TfZ9cH не се използва повече). Payload: Product Name, Variant Name, ProductID, URL, ImageURL, Price, Quantity (EVENT-KEYS.md).

Профилни филтри: без активна Checkout Started (S7c3Ma/VUpmhV) в последните 24ч за същия профил (иначе минава в F05, за да не се дублира натиск).

Изключения: checkout или поръчка спират веднага.

Изход: purchase exit, checkout exit.

Стъпки

Писма: F04-E1/E2/E3 реюз на WQv2gW структурата, но с премахнат SEREBRO testimonial (заменя с реален Артро/Омега отзив) и деактивирани draft AB-тестове (или ги активираме истински, не оставяме полу-конфигурирани).

Честота/collision: правило от KEEP-IMPROVE-REPLACE-RETIRE.csv - VFRwq4 се архивира изцяло (дублира WQv2gW на мъртва метрика); Wnjjhm (checkout) получава взаимно изключване с този flow, за да няма 2 паралелни recovery писма в същия прозорец.

KPI: база 2,99 €/получател, Ur469Q (Email 1) 5,02 €, YyhDs3 (Email 2) 2,53 €, RdjAHj/WABfeL (Email 3 варианти) 1,87/1,46 €. Хипотеза: премахването на SEREBRO testimonial и добавяне на релевантен продукт-отзив не пада под текущия RPR, тества се 4 седмици.

QA сценарии: 1) mixed кошница Артро + Омега → и двата продукта се показват, водещ по стойност определя CTA; 2) COD поръчка направена преди E3 → purchase exit веднага, дори неплатена; 3) Артро изчерпан между E1 и E2 → E2 показва наличния вариант или "очаквайте", не мъртъв линк; 4) профил вече в active checkout flow (F05) → не получава F04 same-day; 5) unsubscribed между стъпки → suppress; 6) реентри: същият продукт добавен пак в количката до 7 дни → не стартира паралелна серия (re-entry минимум 7 дни).

Зависимости: архивиране на VFRwq4 в Klaviyo (собственик одобрява), подмяна на SEREBRO testimonial с текущ отзив, решение дали F04-E3 носи код.

F05. Checkout abandon (P1)

Основа: Wnjjhm "SM | Checkout started - Shopify" (live, 5 142,38 €/365д, 2,25 €/получател, improve).

Цел: довършва вече започнатата поръчка (по-богат сигнал от cart, клиентът е стигнал до checkout).

Тригер: препоръка да се мигрира от VUpmhV (Checkout Started, по-беден payload) към S7c3Ma (Started Checkout, структурирани Items с ProductID/SKU/ImageURL/ProductURL - виж EVENT-KEYS.md), както е решено в стратегия т.10 ред F05: "по-късно на S7c3Ma". Докато метриката не е потвърдена като достатъчно обемна, стартираме на VUpmhV и следим обема на S7c3Ma за превключване.

Профилни филтри: взаимно изключване с F04 (само едно от двете активно в прозорец от 24ч).

Изход: Placed Order спира веднага, независимо дали COD е платен.

Стъпки

Писма: реюз на Wnjjhm структурата (YaKcMQ, VEF2jk, TaAPQQ, SxzMed), с премахнат SEREBRO testimonial от Email 2 (VEF2jk).

KPI: база 2,25 €/получател; YaKcMQ 3,18 €, VEF2jk 1,92 €, TaAPQQ 1,97 €, SxzMed 1,46 €. Хипотеза: без ескалация 5→10→15%, а само 1 евентуален код в E3, приходът на получател не пада значимо (не се обещава конкретен %).

QA сценарии: 1) checkout стартиран, после cart на друг продукт → checkout flow има приоритет (F05 > F04); 2) COD чекаут без плащане → покупка все пак спира flow-а; 3) мигрирал между VUpmhV и S7c3Ma същия ден → дедупликация по checkout token, не 2 паралелни серии; 4) Артро изчерпан по време на checkout поредицата → E2 не обещава "запазена бройка"; 5) unsub между стъпки; 6) валидна оферта в E3 изтекла преди E4 → E4 отпада, не изпраща стар срок.

Зависимости: решение кой checkout metric е канонична (VUpmhV сега, S7c3Ma след потвърден обем), одобрение за евентуален код в E3.

F06. Благодарност след поръчка, по брой поръчки (P1)

Основа: ThEpRb "PG | Post-Purchase Flow" (live, 1 822,14 €/365д, 0,22 €/получател, improve) - сегашният conditional split е по книга/PDF купувачи, не по продукт.

Цел: лична благодарност от автора, различна за първа срещу повторна поръчка, без discount push.

Тригер: Placed Order Ra8Kp7.

Клонове: alltime order count = 1 срещу >= 2 (замества стария книга/не-книга split).

Стъпки: F06-E1 T+1ч благодарност от автора (различен текст за 1-ва/2+ поръчка); при бъдеще - интеграция с F07 onboarding, за да няма дублиращо съдържание.

Писма: F06-E1a (1-ва поръчка) P01 UXBS8C, F06-E1b (2+ поръчка) вариант на P01 с "рутина" тон.

KPI: база 0,22 €/получател (най-слаб жив flow до Uwr6rF); ThEpRb Email 1 XdYsiY има най-добър RPR в цялата серия 1,99 €. Хипотеза: единично точно писмо вместо 6-имейлова верига с 0-конверсийни звена (SAXkWr, ViUiiA) не намалява прихода на получател, докато чисти дублиращото съдържание.

QA сценарии: 1) първа поръчка съдържа и Артро, и Омега → едно писмо с двата продукта, не 2 отделни; 2) COD поръчка → благодарността излиза при Placed Order, не чака плащане потвърждение; 3) поръчка само на пробиотик (не в основния каталог) → generic благодарност; 4) клиент с 2+ поръчки, но връща предходната → изчаква разрешаване на проблема; 5) profile unsub веднага след поръчка → все пак получава транзакционното (не маркетингово) съобщение, ако е separирано; 6) split shipment на същата поръчка → не удвоява писмото.

Зависимости: решение дали остатъчните P02/R01 модули (checkin, refill проверка) остават самостоятелни стъпки или се сливат тук; изтриване на легacy книга-клона.

F07. Onboarding по продукт след доставка (P0)

Основа: WYnQ3a "Омега 3-Инфо Помпа" (live, 777,74 €/365д, единично писмо, работи) + P01/P02 шаблони. SNPgwY (Артро) и Уwr6rF нямат работещ onboarding по продукт.

Цел: правилна употреба веднага след доставка, за да има резултат (и оттам втора поръчка).

Тригер: Delivered Shipment SEgEQc (предпочитано); ако delivery покритие липсва за поръчката, fallback на Fulfilled Order WxqpUy + логистичен буфер и текст "когато пристигне" (не "вече получихте").

Клонове по ProductID: Омега 8756703494492, Артро 8357886263644, Буркани 14763697996124/Вълчан 15152759505244. При bundle (Артро+Омега) - модули за двата продукта в едно писмо, не 2 паралелни серии.

Стъпки на клон

Писма: Омега E1 реюз WYnQ3a QY68T6 (жив, единствен инфо-имейл, 5,4% bounce rate за проверка). Артро E1 нов модул (P01/P02 база). Буркани/Вълчан E1 нов модул.

KPI: база Омега 0,29 €/получател (777,74 €/365д), най-висок bounce rate в акаунта (5,4%) - изисква технически преглед на списъка/темплейта, не само копи. Артро/Буркани нямат база (нов клон); хипотеза: onboarding писмо намалява грешна употреба и увеличава дела на клиенти, преминаващи във F09 replenishment навреме, без обещан конкретен %.

QA сценарии: 1) поръчка с Артро + Омега в едно пращане → едно писмо, 2 секции, не 2 имейла същия ден; 2) split shipment (Омега пристига по-рано от Артро) → всеки продукт тръгва при своя Delivered Shipment; 3) delivery данни липсват за поръчката → fallback на Fulfilled Order с "когато пристигне"; 4) клиент подава оплакване за продукта → пауза на E2, преминава към обслужване; 5) нова поръчка на същия продукт преди E2 → не дублира идентично съдържание; 6) неизвестен любимец (без Pet property) → dozировъчният текст остава по тегло, не приема dog по подразбиране.

Зависимости: разследване на 5,4% bounce rate при Омега списъка; съдържание за Артро/Буркани onboarding (ново копи); component map за bundle поръчки.

F08. Молба за отзив (P1)

Статус: липсва, нов.

Цел: реален отзив с разрешение за бъдеща употреба, не само звезда.

Тригер: Delivered Shipment SEgEQc, D+14 (Буркани/козметика) до D+21 (добавки, за да има реален ефект преди питане).

Профилни филтри: без отворен ACTIVE_PROBLEM (оплакване се обслужва отделно, не се пита за отзив).

Стъпки: F08-E1 D+14/21 молба (по продукт, реален линк за отзив); F08-E2 напомняне само ако няма реакция и няма нова релевантна причина да не се пита отново.

Писма: F08-E1 нов модул "как е [продукт]" + линк за отзив, F08-E2 кратко напомняне.

KPI: без база (нов flow). Хипотеза за тест: дял оставени отзиви спрямо разгледали писмото, не приход директно.

QA сценарии: 1) клиент вече оставил отзив (ако има webhook/поле) → не пита пак; 2) поръчка с рефъндирана позиция → изключва се от искането за тази позиция; 3) активно оплакване → пропуска се искането до разрешаване; 4) клиент купил 2 продукта → едно писмо, избор кой отзив да остави, не 2 отделни искания; 5) unsub между E1 и E2.

Зависимости: избор на review provider (ако вече има интегриран инструмент, F08 не се дублира - виж FLOW-PLAYBOOKS F17); съгласие за повторна употреба на разказ/снимка преди публикуване.

F09. Replenishment по продукт и количество (P0)

Основа: SNPgwY "Артро | Replenishment Flow" (live, 0 получатели, стар SKU филтър), X9PBMg "Бурканите | Replenishment" (live, 0 получатели, стар филтър), Uwr6rF "PG | Replenishment Flow Final" (live, 2 496,87 €/365д, 0,26 €/получател, но 100% SEREBRO/deworming логика по FLOW-STRUCTURE.md - replace присъда).

Цел: напомня точно преди да свърши количеството, по реалното количество купено, без отстъпка по подразбиране.

Тригер: Fulfilled Order WxqpUy или Delivered Shipment SEgEQc (предпочитано, ако покритието позволява) + Items/ProductID филтър.

Replenishment математика (формула от заданието)

дни запас = закупени единици x дози в единица / дневна доза - логистичен буфер

Омега 3 (потвърдено от PDP, src/data/products.ts): дозиране "1 помпичка на 5-10 кг дневно". За еталонно куче 20 кг PDP дава директно готови стойности: 300 мл ≈ 2,5 месеца (~75 дни), 500 мл ≈ 4 месеца (~120 дни), 1000 мл ≈ 8 месеца (~240 дни). Формулата зад тези числа не е публикувана като мл/помпичка, затова взимаме готовите PDP стойности като база, вместо да прекалкулираме сами:

За кучета извън ~20 кг: пълна помпичка-скала по тегло е потвърдена на PDP (omega-theme-content.ts dosageModal, 25.09.2026): до 5кг = 1 помпичка/ден, 5-15кг = 1-2, 15-30кг = 2, над 30кг = 3. Точен мл обем на 1 помпичка не е публикуван, затова дните-до-допълване за тегла различни от ~20кг не могат да се изчислят прецизно. Вместо да обещаваме грешен ден, F09-Омега праща въпрос-базиран имейл ("Колко тежи любимецът ви и колко пъти на ден давате?") при неизвестно тегло, не твърдение "точно сега свършва".

Артро Плюс 30 табл.: дозата по тегло на ТЕКУЩАТА формула е намерена и потвърдена (25.09.2026) в src/data/arthro-theme-content.json, SKU 9.3 (текущата жива 30-табл., 39,00 €): до 5кг = ½ табл. през ден (~60 дни на опаковка), 5-15кг = ½ табл. на ден (~60 дни), 15-30кг = 1 табл. на ден (~30 дни), 30-45кг = 2 табл. на ден (~15 дни), над 50кг = 3 табл. намалени до 2. Това прави изчислен refill ден технически възможен (по аналог на Омега), но е решение за собственика дали да замени сегашния въпрос-базиран подход ("Как върви приемът?") с изчислен ден — засега F09-Артро остава въпрос-базиран, докато не се вземе решение.

Буркани/Вълчан: дневна дажба зависи от тегло и няма публикувана таблица в проверените файлове. [ПРОВЕРИ] - същият въпрос-базиран подход: "Колко остава в буркана?" вместо изчислен ден.

Клонове и стъпки

Писма: R01 VbuD2h (Проверка на наличното) като база за всички клонове, дублиран и адаптиран по продукт.

KPI: база Uwr6rF 0,26 €/получател (най-слаб replenishment в акаунта заради SEREBRO логика); SNPgwY и X9PBMg имат 0 €/получател заради счупен филтър, но Артро и Буркани са в текущ обхват (154 078 € и 51 963 € годишен нетен приход - data/PRODUCT-FACTS.md), затова P0. Хипотеза: правилен ProductID филтър + въпрос-базиран подход при непотвърдена дозировка връща поне частта от 0-получателския обем в измерим канал, без обещан конкретен €.

QA сценарии: 1) клиент купил 2 опаковки Артро наведнъж → refill изчислението/въпросът зачита количеството, не като 1 опаковка; 2) клиент купил и Артро, и Омега → получава едно писмо на клон, приоритетът решава кое първо, не 2 паралелни imейла същия ден; 3) Артро изчерпан в склада точно когато трябва да излезе E1 → съобщение "новата формула идва" + waitlist вместо продажбен push (стратегия раздел 4); 4) нова поръчка на същия продукт преди E2 → старата задача се анулира, ново изчисление; 5) неизвестно тегло на кучето → въпрос-базиран имейл, не грешно твърдение за ден; 6) profile купил стария 90-табл. Артро (permanently discontinued) → не му предлагаме несъществуващ SKU, насочва се към 30-табл. или waitlist за нова формула.

Зависимости: Артро доза потвърдена (виж по-горе, arthro-theme-content.json); Буркани/Вълчан порции по тегло все още нямат публикувана таблица в проверените файлове — остава [ПРОВЕРИ] само за тях; проверка на живата наличност на Артро преди активиране (P0 сигурност: потвърдени 16 бр. на склад, 25.09.2026); поправка на ProductID филтрите в Klaviyo (текущите ползват остарели имена).

F10. Втора покупка / cross-sell (P1)

Основа: частично покрито в ThEpRb, тук отделен flow.

Цел: Омега купувач без Артро (7+ г. куче, ако е известно) вижда стави-съдържание; храна купувач вижда Омега.

Тригер: Placed Order Ra8Kp7 с ProductID Омега, без lifetime Артро поръчка (сегмент S-OMEGA-NO-ARTRO по стратегия т.9); аналогично за Буркани/Вълчан без Омега.

Стъпки: F10-E1 D+14 разлика в ролята на двата продукта (C03 TKAM3T Артро и Омега база); F10-E2 D+21 избор на разфасовка/FAQ, ако не е купено.

Изход: покупка на другия продукт, проблем, пазар/наличност спират серията. Re-entry минимум 180 дни.

Писма: F10-E1 C03 TKAM3T, F10-E2 C04 Skib7R (Лично писмо Омега, реюз за Артро→масло посоката).

KPI: без директна база (нов flow, извлечен от ThEpRb остатъци); Артро годишен приход 154 078 €, Омега 89 861 € (data/PRODUCT-FACTS.md) - хипотеза: attach rate между двата расте спрямо контролна група, без обещан %.

QA сценарии: 1) клиент вече има bundle поръчка (Артро+Омега в 1 order) → изключва се от cross-sell (component map потвърждава и двете); 2) кучето е под 7 г. (ако възрастта е известна) → без Артро-специфично твърдение за стави при млад любимец, generic позициониране; 3) неизвестна възраст → показва общата роля, не гадае; 4) клиент купил Артро между E1 и E2 → exit; 5) COD поръчка неплатена все още → не брои като "без Артро", изчаква изход на recovery.

Зависимости: потвърден component map за bundle продукти (иначе рискуваме да продаваме вече купено); данни за възраст на любимеца, ако се ползва за таргетиране (иначе - без възрастово твърдение).

F11. VIP (P2)

Статус: липсва, нов. Сегмент VIP VgiZyH вече съществува (1 876 профила, >=3 поръчки и >500 € за 12 мес.) - [РЕШЕНИЕ] прагът >500 € е висок при AOV 40,83 €, стратегията предлага преразглеждане.

Тригер: влизане в VIP сегмента (>=3 успешни поръчки за 180 дни, последна <=90 дни, без нерешен проблем).

Стъпки: F11-E1 T+0 благодарност + реална привилегия (ранен достъп или конкретен комплект); F11-E2 T+5 напомняне само при истински срок и липса на покупка.

Изход: re-entry минимум 90 дни с нова оферта, не всеки ден в статус VIP.

Писма: F11-E1 нов модул "благодарност + ранен достъп", F11-E2 напомняне на същия модул.

KPI: без база (нов flow); хипотеза: задържане (retention) на VIP сегмента расте спрямо контрол, не конкретен €.

QA сценарии: 1) клиент влиза и излиза от VIP прага многократно за кратко → re-entry cooldown 90 дни пази от спам; 2) активно оплакване → не влиза докато не се разреши; 3) няма реален "ранен достъп" наличен в момента → E1 се отлага, не изпраща празна привилегия; 4) VIP клиент в момента в друг recovery flow → recovery има приоритет; 5) unsub между E1 и E2.

Зависимости: [РЕШЕНИЕ] праг за VIP сегмента; дефиниране на реалната "привилегия" (ранен достъп до MedPaw или конкретен пакет).

F12. Winback (P1)

Основа: XUB8KR "PG | Customer Winback" (live, 12 180,07 €/365д, 0,79 €/получател, keep с бележка да се тества по-дълъг delay).

Цел: връща клиент, пропуснал обичайния си цикъл, вместо фиксиран прозорец.

Тригер: сегмент-базиран вместо чист 30-дневен delay: пропуснат изчислен цикъл (F09 E/prозорец) при известен продукт, или T+90 дни от последна успешна поръчка при неизвестен цикъл (медиана 50 дни магазин / 77 дни Артро - data/PRODUCT-FACTS.md т.5).

Стъпки: F12-E1 T0 лично "има ли нещо, с което можем да помогнем"; F12-E2 T+7 една релевантна новост/оферта при допустимост; F12-E3 T+14 избор на предпочитания, не по-голям процент.

Изход: покупка спира веднага; re-entry минимум 180 дни и нов цикъл.

Писма: F12-E1/E2 реюз на XUB8KR (RUirBM, RhhnZa), F12-E3 нов модул "избор на предпочитания".

KPI: база RUirBM 0,51 €/получател, RhhnZa 1,07 €/получател (Email 2 надминава Email 1 - препоръка в audit да води с този ъгъл). Хипотеза: тригер по продуктов цикъл (77 дни Артро) вместо фиксирани 30 дни намалява преждевременните winback писма към клиенти с все още достатъчен запас, без обещан % ръст.

QA сценарии: 1) клиент с известен Артро цикъл (77 дни) получава E1 на ден 90, не ден 30; 2) клиент направил поръчка точно преди изпращане → exit; 3) неизвестен продуктов цикъл → fallback на 90 дни от последна поръчка; 4) активно оплакване → не влиза; 5) вече в F09 replenishment опашка за същия продукт → replenishment има приоритет пред winback.

Зависимости: потвърждение на реалния repurchase cycle по продукт (77 дни Артро е memory данни, не пряко Klaviyo).

F13. Sunset (P1)

Основа: R4h5sL "Supress Email Engage sunset flow" (draft, английски stock template, improve).

Цел: намалява натиска към неангажирани, вместо тихо да продължава да ги маркетира.

Тригер: влизане в Wemjib Unengaged 180D (1 873 профила) или VCyUFv Suppress Email Engage (1 918 профила).

Стъпки: F13-E1 T0 "кои теми искаш да получаваш" (превод и персонализация на SQGWXf); F13-E2 T+14 кратък избор за по-рядко получаване или отказ (превод на RAERHZ).

Изход: без реакция → изключване от общите промо аудитории, не автоматично suppression на целия акаунт; служебните съобщения се пазят.

Писма: F13-E1/E2 преведени и персонализирани версии на SQGWXf/RAERHZ (в момента draft, unedited Klaviyo stock, на английски).

KPI: база 0 € (никога не е бил активен); 1 918 + 1 873 = 3 791 профила чакат. Хипотеза: активирането намалява оплаквания/spam rate на цялостния лист, измерва се спрямо текущия spam rate (audit/METRICS-12M.csv), не обещан конкретен %.

QA сценарии: 1) профил реагира с клик в E1 → връща се в Engaged поток, не завършва sunset; 2) профил вече unsubscribed → не влиза (вече е извън маркетинг обхвата); 3) активна поръчка/чакащ refill за същия профил → не изключва от служебните съобщения; 4) профил, който случайно е в списъка заради bounce, не заради незаинтересованост → преразглежда се преди изключване; 5) нова реална активност (клик/поръчка) след изключване → re-entry само тогава, не автоматично.

Зависимости: превод на двата темплейта, [РЕШЕНИЕ] за точния праг на "изключване от промо аудитории" (само общи кампании или и flows с оферта).

F14. Waitlist / launch MedPaw (P1, подготовка)

Основа: нов, "launch модел" от стратегия т.11 и FLOW-PLAYBOOKS F15.

Статус: не старира без потвърден SKU, етикет, цена и наличност (data/PRODUCT-FACTS.md т.4: MedPaw е все още в предпечатна фаза, нито едно SKU няма цена/наличност в Shopify).

Тригер: изричен waitlist сигнал (клик в "новата формула идва" писмо, или форма) → сегмент S-WAIT-MEDPAW.

Стъпки: T-14 интерес (тийзър, за Артро-купувачи първо), T-7 обяснение (механизъм/съставки, само след одобрен етикет), T0 release, T+3 FAQ, T+7 демонстрация, T+12 финал само при реална оферта. 7 стъпки общо, календарни, с проверка за stock/offer expiry/purchase на всяка стъпка.

Писма: всички нови модули; нищо не се пише за състав/ефект преди одобрен етикет (стратегия раздел 4).

Изход: покупка спира продажбените стъпки; купувачи преминават към F07/F09 за новата формула.

KPI: без база (продукт все още не съществува в продажба). Хипотеза само след потвърдена дата: конверсия на waitlist сегмента, не приход предварително.

QA сценарии (условни, преди активиране): 1) waitlist профил вече купил стария Артро междувременно → не се третира като "загубен", получава и двете съобщения по контекст; 2) launch датата се отложи → календарните стъпки не изпращат остарял T0; 3) няколко waitlist интереса едновременно (Allergy + Dental) → един приоритетен launch, останалите чакат; 4) наличност изчерпана веднага след launch → стъпките след T0 не обещават наличен склад; 5) профил извън BG пазара по грешка → изключва се преди T-14.

Зависимости: SKU, одобрен етикет, потвърдена цена и наличност преди каквато и да е стъпка над T-14; собственическо одобрение на всяко claim (алергия/дентал изисква повишено внимание по правилата за claims).

F15. Back in stock (P2)

Статус: липсва, нов. Приоритетна цел: Артро (при изчерпване на 30-табл. опаковката) и изчерпани вкусове Буркани.

Тригер: реална заявка за конкретен вариант ("уведоми ме"), после потвърдена продаваема наличност за същия вариант.

Стъпки: F15-E1 T0 кратко известие с точния вариант; F15-E2 T+48ч само ако все още има наличност, няма покупка и заявката е уместна.

Изход: re-entry само при нова заявка и ново възстановяване на наличност.

Писма: нов модул "вече е налично".

KPI: без база (нов flow). Хипотеза: request-to-purchase конверсия, а не обещан общ приходен ръст.

QA сценарии: 1) заявка за Артро при наличност 16 бр. (текущо ниско ниво) → не се пуска "back in stock" push, докато не е реално попълнен склад (стратегия раздел 4: не push-ваме масово при ниска наличност); 2) вариант отново изчерпан веднага след E1 → E2 не се изпраща; 3) заявка за вкус на Буркани, който е спрян за постоянно → известие, че вкусът не се връща, вместо мълчание; 4) клиент купил друг вариант междувременно → без покупка на точно заявения продукт, серията продължава; 5) множество заявки за различни варианти → всяка проследена отделно, не сборна.

Зависимости: технически back-in-stock механизъм в Shopify/Klaviyo (native capability за проверка), потвърдена реална наличност преди всяко изпращане.

14. Retire списък (точни flow ID)

Всички останали "мъртви заради счупен филтър, но продуктът е в обхват" (SNPgwY Артро, X9PBMg Буркани) НЕ се архивират - те се преизграждат вътре в F09, не се третират като retire.

15. Migration план (нищо не е live, всичко чака одобрение)

1. Draft first. Всеки нов/преработен flow (F01-F15) се строи като draft клонинг в Klaviyo, паралелно на живия оригинал, никога не презаписва directно live flow-а.
2. QA на draft-а по сценариите по-горе (минимум 5 на flow) с тестови профили преди какъвто и да е реален трафик; проверка на dynamic data fallback-ите за липсващи полета.
3. Собственическо одобрение на: welcome оферта %, VIP праг, Артро наличност преди push, кой checkout metric е канонична, дали F09-Артро/Буркани минават с въпрос-базиран текст или чакат потвърдена дозировка.
4. Изключване на стария flow (status off, не delete) в същия момент, в който новият draft минава на live - никога двата активни едновременно на едно и също събитие (правилото "no simultaneous duplicates").
5. Малък pilot преди пълен обем, където е приложимо (напр. F09 нов Артро клон - първо малка тестова аудитория, после цялата VVzXcp 1 979).
6. Rollback: ако новият flow показва проблем (rev/получател пада >25% или spam/unsub над прага от стратегия т.8), старият flow се връща на live веднага, новият се спира; версия на стария се пази експортирана преди всяка смяна, за да има какво да се върне.
7. Ред на изпълнение по приоритет: P0 (F01 фикс, F04/F09 replenishment преработка, retire списъка) → P1 (F03/F05/F06/F07/F08/F10/F12/F13) → P2 (F02/F11/F15) → F14 чака продуктова готовност отделно от този ред.

16. Несъгласия и отворени точки към собственика (отделно от стратегията, не са решени тук)

• Формулата за Омега replenishment разчита на PDP готови стойности за 20 кг куче ("~2,5/4/8 месеца"), не на самостоятелно изчислена мл/помпичка стойност - ако собственикът иска точна per-kg таблица за други тегла, трябва отделен PDP data extract, не приблизителна екстраполация тук.
• Артро и Буркани replenishment остават на въпрос-базиран текст, докато няма потвърдена дневна доза - това е по-консервативно от "изчислен ден", но е нарочно, за да не се обещае грешен момент за нова поръчка.
• F02 (Site abandon) е приоритет P2 по стратегията, но практически зависи от метрика, която не е потвърдена да съществува в акаунта - може да остане само на хартия, докато не се провери технически.