# Aftercare: a customer lifetime playbook Prepared 9 September 2026. Interactive report for LTVMoneyRaw. > The next sale starts with _being useful._ Stay close after the purchase. Answer the small questions. Solve the frustrating ones. Recommend something only when it makes their life better. 01 / **Support comes first** Resolve before recommending. 02 / **Permission sets the pace** Up to 2 proactive touches / 30 days. 03 / **Useful beats urgent** A good answer can be “you’re all set.” THE PROPOSAL A Telegram assistant connected to orders, approved product knowledge, and a human support team. It remembers what the customer chooses to share and looks for a useful next step. Higher lifetime value is the hypothesis; incremental profit and customer trust are how we test it. Interactive strategy, not a live bot. “Aftercare” is a working concept. All customers, products, prices in USD, and conversation outcomes are fictional. The example catalogue covers culinary knives and accessories. ## Same shop. _Very different lives._ Context changes the conversation. Explore what the assistant remembers, when it speaks, and when a sale should never enter the chat. ↳ These are designed scenarios, not testimonials. A helpful no-sale conversation is a successful outcome. Age, name, job, and language never substitute for a stated need. ## Earn the right _to send the next message._ A purchase creates a chance to invite someone in. The customer decides whether that becomes an ongoing conversation. 1 ### Invite at a useful moment Place a “Care & help on Telegram” link on the order confirmation and a QR code in the parcel. Explain what the assistant does before the customer opens it. No imported phone lists. 2 ### Connect with permission The customer starts the bot. Match an order through an authenticated shop session and a short-lived, single-use token. Never identify an order from a Telegram username alone. 3 ### Let them choose the pace Offer support only, occasional care tips, or care plus relevant products. Ask language, time zone, and a preferred window. Each choice is separate; nothing is preselected. Telegram bots cannot initiate the first conversation. The user must start it. [Telegram bot documentation ↗](https://core.telegram.org/bots#how-are-bots-different-from-humans) AN EXAMPLE, NOT A FIXED DRIP CAMPAIGN ### The first 90 days Every touch must earn its place ### The pilot contact policy - At most 2 proactive messages in a rolling 30-day window, with at least 14 days between them. Care tips and product messages share the cap. - Use a customer-selected local window. Proposed default, if accepted: 10:00–18:00. Ask for the time zone; Telegram does not supply it. - After two unanswered proactive messages, pause indefinitely until the customer re-engages and confirms preferences. A click alone does not reset the pause. - After “not interested,” suppress that category for 90 days. After “stop,” cancel all queued proactive messages immediately. Never send a re-permission campaign to opted-out customers. - Schedule reminders for real customer needs. Durable knives have no automatic replacement clock. ### Know which kind of message it is Customer-initiated support Answer right away, including at night. Never delay requested help to satisfy a campaign cap. Necessary service update Delivery, a requested refund update, or a safety notice. Keep it factual, match channel preferences, and include no promotional add-on. Proactive care or product idea Optional outreach. Apply purpose-specific permission, contact caps, relevant context, and quiet hours. “Just a tip” is never a way around the policy. Open ticket or recent recovery Pause recommendations until the case is closed, the customer confirms the resolution, and a 7-day recovery buffer passes. These numbers are conservative pilot choices, not established optimal conversion rates. Marketing rules depend on the market; the UK ICO includes private social messages in electronic mail marketing. Validate the launch market and consent wording before launch. [ICO guidance ↗](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/) ## Should we send _anything at all?_ Change the customer’s situation. See the policy decide before any message is written. This tests proactive product outreach; requested support always has its own path. The demo uses deterministic policy rules. It has no access to customer data and sends no messages. ## Sound like someone _who paid attention._ The assistant can be easy to talk to while being clear that it is AI. It should never pretend to be a friend, a human colleague, or someone who personally used a product. SKIP THE SCRIPTED SALES VOICE “Elevate your culinary journey! Our premium accessories are the perfect companion to your purchase. Don’t miss out!” USE THE CUSTOMER’S ACTUAL CONTEXT “You mentioned the knife lives in a drawer. This $12 guard fits your 20 cm blade. If you already have a cover that fits, you’re sorted.” Only after a confirmed need and a compatibility check. ### A practical writing standard - Answer the question in the first sentence. Usually 2–4 short sentences are enough; give longer steps when the task needs them. - Ask one useful question at a time. Reuse confirmed context so the customer does not have to repeat it. - Use contractions and familiar words. Match the customer’s language and level of detail. Default to no emoji in complaints or payment issues. - State the price, the reason it fits, and the limitation. Show at most one main recommendation and one cheaper or no-purchase alternative. - No fabricated scarcity, fake personal anecdotes, guilt, exaggerated praise, or “I was thinking about you.” - Say what is unknown. “I can’t confirm that fit from the catalogue. I’ll ask the team.” Keep approved facts unchanged when rewriting. FIRST MESSAGE / PROPOSED COPY > “Hi, I’m the shop’s AI assistant. I can help with your order, care questions, and choosing accessories. You can ask for a person anytime. Would you like support only, occasional care tips, or care tips plus relevant product ideas?” Then offer separate buttons, record the selection, and ask about timing only if they choose proactive messages. A refusal never reduces support quality. Writing edited with [Humanizer v3.0.0 ↗](https://github.com/blader/humanizer/blob/main/SKILL.md). Its useful contribution is removing inflated, generic prose. Transparent AI identity follows [NN/G’s discussion of AI humanization ↗](https://www.nngroup.com/articles/humanizing-ai/). ### A service playbook for the questions that actually arrive ? Product knowledge & everyday advice + **Example:** “Can this go in the dishwasher?” “The care guide for your knife says to wash it by hand and dry it straight away. A dishwasher can damage its handle and edge.” Retrieve the exact SKU’s approved guide. Ask about the material or model if unknown. Link the relevant guide; do not add a cleaning-product pitch to a complete answer. Images can help identify a model, but a low-confidence visual guess cannot establish compatibility. ! Damage, a defect, or a disappointing order + **Example:** “The tip arrived chipped.” “I’m sorry it arrived like that. Please leave it unused. I can help start a replacement or return review. Can you send a photo of the tip?” Create a case, attach the order and the customer’s message, and route to a human. Never diagnose a dangerous defect from a photo or encourage use of a damaged blade. Apply the actual store policy and applicable customer rights. Give a response estimate from the staffed queue, not an invented promise. Keep the case open until the fix is confirmed. $ Payments, duplicate charges & refunds + **Example:** “I think I was charged twice.” “Let’s check the two payments. Please don’t send card details here. I’ll open a secure order-check page so the team can compare the payment references.” Retrieve transaction status from the payment provider through an authenticated flow. Distinguish pending authorization from a settled charge only after verification. A human approves refunds and exceptions. Quote the provider’s confirmed refund timeline; never promise bank settlement. Telegram’s payments documentation assigns payment disputes to the merchant, provider, and banks. [Payment responsibilities ↗](https://core.telegram.org/bots/payments) ↗ Advice that could lead to a purchase + **Example:** “Do I need a more expensive knife for tomatoes?” “Your current knife may just need sharpening. Has it started slipping on the skin? We can check that before you spend money on another one.” Diagnose the job and constraints. Offer a free adjustment or existing tool first when suitable. If a purchase solves the actual problem, explain why, check stock and fit, and offer an optional checkout link. Answer a customer’s explicit shopping question even if they chose support only; it does not opt them into later marketing. ↔ A human, a voice note, or something outside scope + “I’ll pass this to the support team with the details you’ve already shared.” Send that only after the case is successfully created. If the handoff fails, say so and show the store’s verified support route. Offer “Talk to a person” throughout the experience. With permission, transcribe voice notes and confirm uncertain amounts or model names. Translate faithfully and pass the original to the human team. For unrelated questions, briefly explain the shop’s scope and redirect. Hand over after two unsuccessful clarification attempts, any request for a human, unclear compatibility, a dispute, or a possible safety issue. ↳ **Support targets for the pilot:** automated acknowledgement within 10 seconds; human review within 4 staffed hours; a next-business-day estimate outside the published schedule. These are proposed service targets, subject to actual staffing. Only report a case, refund, or order action as complete after the tool confirms success. ## A catalogue of products. _A memory of needs._ A good recommendation starts with a job the customer wants done. The commercial opportunity follows from a verified match. | Product | Useful when | Verify before offering | When to skip | | --- | --- | --- | --- | | 20 cm chef’s knife$85 · SKU CK20 | Customer needs an everyday preparation knife. | Use case, experience, handle preference, budget. | Current knife solves the task or only needs care. | | Fitted blade guard$12 · SKU BG20 | Customer stores the knife in a drawer or transports it. | Exact blade dimensions and approved fit. | Already owns a fitting cover; no storage need. | | Sharpening service$25 · SKU SS01 | Edge has dulled and customer wants someone else to maintain it. | Blade eligibility, location, turnaround, shipping cost. | Possible defect or existing unresolved claim. | | 1000-grit whetstone$39 · SKU WS10 | Customer wants to learn sharpening and has time to practise. | Approved blade guidance, skill, accessory requirements. | They prefer a service or dislike maintenance. | | Compact cutting board$48 · SKU CB30 | Customer needs a stable work surface that fits their space. | Dimensions, material care, budget, available surface. | Suitable board already owned or fit unknown. | ### First, exclude bad matches Remove owned equivalents, unverified compatibility, unavailable stock, budget mismatches, unsupported markets, and rejected categories. No purchase is an explicit candidate. A gift order is not proof the buyer owns or uses the item. ### Then rank useful candidates Proposed score: need match 40%, verified fit 30%, stated timing 20%, preference fit 10%. Require a current reason in the customer’s own words. Start with a reviewed threshold of 80/100; treat weights and threshold as hypotheses. Margin may break a tie between equally helpful options. Store the rejected alternatives and a plain-language reason for the final choice. If there is no qualifying candidate, send nothing. ### The facts each product needs SKU, approved description, current price and currency, stock timestamp, dimensions, compatible SKUs, exclusions, material, care instructions, warranty policy version, images, landing page, shipping regions, and contribution margin. ### The context worth remembering Verified orders and returns; consent purpose, timestamp and copy version; language and time zone; stated needs, budget and exclusions; ticket status; contact history and reactions. Tag every preference with its source, confidence, date, and expiry. Let the customer review, correct, or delete preferences. Do not infer income, sensitive traits, family situation, or emotional vulnerability. “Small kitchen” is useful if they told us; a guessed salary is not. EXAMPLE DECISION RECORD Customer need “It goes in a drawer.” · confirmed today Owns CK20 chef’s knife · verified order Candidate BG20 guard · $12 · stock checked before send Fit CK20 → BG20 · approved compatibility table Decision Offer one option, if contact policy allows Reason Protects the edge during drawer storage Alternative Keep the fitted cover they already own ## Give the assistant _good information. And limits._ Use AI to interpret a question and write a clear response. Keep consent, contact limits, money, and factual checks in deterministic application code. 01 ### Telegram Messages, buttons, optional voice notes → 02 ### Secure intake Webhook validation, identity, deduplication → 03 ### Policy + context Permission, support state, catalogue, order history → 04 ### Reply or handoff Verified answer, logged result ### Suggested implementation Cloudflare Pages This report and, later, an authenticated preference interface. No bot tokens, order data, or admin functions in a public static page. Workers + Queues Authenticated webhooks, intent routing, and asynchronous work. Cron triggers find due outreach; a fresh policy evaluation precedes every send. A per-customer Durable Object can serialize decisions and protect contact caps. D1 or the existing customer database Customer identity links, consent history, preferences, tickets, event log, send reservations, and experiment assignment. The existing commerce platform remains the source for orders and catalogue facts. Approved knowledge + language model Retrieve SKU-specific facts and shop policies. Require structured candidate answers, source IDs, and an escalation reason. Validate references and amounts before the final humanizer pass. Commerce, payments & support connectors Read authenticated order status; use hosted checkout for purchases. Create tickets in the existing helpdesk. Keep refunds and policy exceptions with authorized staff. ### What happens before a send 1. Authenticate the event; deduplicate Telegram update IDs and commerce event IDs. 2. Load a fresh customer and consent record. Cancel if preferences changed. 3. Check support state, time zone, contact budget, and recent unanswered messages. 4. Retrieve current price, stock, fit, and policy. Fail closed for proactive offers when a source is stale or unavailable. 5. Reserve one contact slot atomically. Use customer + trigger + policy version as the decision key. 6. Draft, check facts and tone, then call Telegram. Record the message ID and confirmed status. 7. Release failed reservations. For ambiguous timeouts, reconcile or hold for review; do not blindly resend a potentially delivered message. Telegram supports webhook secret validation and rate-limit retry timing. Cloudflare Queues delivers at least once, so consumers must handle duplicates. [Telegram API ↗](https://core.telegram.org/bots/api#setwebhook) · [Queue delivery guarantees ↗](https://developers.cloudflare.com/queues/reference/delivery-guarantees/) Data, privacy & customer controls + Proposed entities: Customer, IdentityLink, ConsentEvent, Preference, Order, Product, Compatibility, SupportCase, Trigger, Decision, OutboundMessage, and ExperimentAssignment. Log consent scope, copy version, source and timestamp; withdrawal is an immediate event that cancels pending work. Show /preferences, /stop, /human, /privacy, and /delete in the bot menu; recognize equivalent plain language. Allow separate care and product permissions and a temporary pause. “Stop” defaults to all proactive outreach, with support still available on request. Keep necessary service routing separate. Minimize data sent to the model, redact card details, store secrets in backend bindings, encrypt stored data, and restrict staff access by role. Customer text and retrieved documents are untrusted input, never tool instructions. Verify order access server-side. Test cross-customer isolation. Proposed retention: raw conversation text for 90 days, then delete or redact unless an open case or applicable record obligation requires it. Retain only necessary structured preferences while the relationship is active; reconfirm stale needs. Keep a minimal suppression record to avoid contacting opted-out people again. Final durations, lawful bases, processor terms, access/export/deletion handling, and cross-border transfers require review for the actual launch market. Failures, observability & operator ownership + Honor Telegram retry\_after for explicit rate limits. Mark a blocked or unreachable chat as suppressed; never move to a different channel to bypass it. Put exhausted work in a dead-letter queue for operations review. A model timeout falls back to a factual acknowledgement and a case if the helpdesk confirms it. Record policy reason, source versions, scheduled and actual local time, model version, message ID, outcome, latency and cost with redacted logs. Track duplicate sends, opt-out processing delay, connector freshness and queue age. Never count API acceptance as a read receipt; standard bot delivery does not establish attention. The support lead owns escalations and recovery. Merchandising owns fit and catalogue facts. Operations owns permissions, suppression and send reliability. The analyst owns experiment assignment and margin calculations. An authorized operator can pause all proactive sending without shutting down inbound support. Implemented here: an interactive report, fictional examples, policy simulation, and economics calculator. Proposed for a later build: the Telegram bot, customer database, connectors, message scheduler, payments flow, and support console. ## Make the relationship _worth more. Prove it._ Count the contribution from additional purchases after the costs of serving them. A purchase after a message may have happened anyway. THE MATH (Treatment repeat rate − holdout repeat rate) × net order value × contribution margin − incremental program cost = incremental contribution per eligible customer. Assumes one repeat order per repeat buyer and the same order value and margin in each group. Net order value is after discounts and refunds, excluding tax; contribution margin deducts product, fulfillment, shipping subsidy, and payment costs. Program cost includes extra support labor, AI, messaging operations, and amortized setup cost. Replace the assumptions with actual cohort data. This is a 90-day illustration, not measured LTV or a forecast. ### Run a fair comparison Randomize eligible, opted-in customers at customer level before outreach. For the first adequately powered experiment, split 50/50 between the companion and a holdout receiving the same support and necessary service updates. Only proactive care and product messages differ. Keep assignment stable across repeat orders. Stratify by prior spend, recency, and first product where practical. Exclude staff and test accounts before assignment. Analyze everyone as assigned, including customers who never reply. Capture all shop orders in the window, subtract returns after a defined maturation period, and prevent overlapping campaigns from contaminating the comparison. Choose sample size from baseline rates, the smallest useful lift, 80% power, and a predeclared 5% significance level. A 100-customer operational pilot tests reliability; it cannot establish a small commercial effect. Keep running beyond 90 days if necessary. Report confidence intervals and predeclared segments, and avoid stopping as soon as results look positive. The comparison follows established controlled-experiment methods; the exact design above is this plan’s recommendation. [Kohavi et al., A/B Testing Intuition Busters ↗](https://exp-platform.com/abtestingintuitionbusters/) ### A scorecard with consequences Primary 90-day incremental contribution per assigned customer, with uncertainty. Customer Resolution rate, repeat contacts for the same issue, satisfaction after resolution, opt-outs, blocks and complaints. Commercial Repeat purchase rate, days to second order, net order value, returns and accessory attach rate. Operational Handoff success, factual accuracy, duplicate sends, time to resolution and total service cost. Proposed review triggers: any consent violation or duplicate send pauses outbound automation; any incorrect payment or safety advice escalates immediately. Review a ≥1 percentage-point rise in 30-day opt-outs or blocks against the pre-pilot baseline, or a ≥5-point drop in satisfaction. Small samples require case review; these are operating thresholds, not claims of statistical significance. How this becomes a lifetime-value model + Historical contribution LTV is the sum of net order contribution less attributable service and retention costs per customer across their observed relationship. Track it by acquisition cohort so older customers do not appear better simply because they have had more time to buy. For forecasting, model expected monthly order contribution minus ongoing service and retention costs, discount each future month by (1 + monthly discount rate)month, and sum over an explicit horizon, such as 12 or 24 months. Show uncertainty and validate predicted retention against mature cohorts. Acquisition cost is already sunk for the existing-customer outreach decision; include it when evaluating whole-business customer economics. Do not label 90-day results as proven lifetime lift. Revenue and margin-based definitions of customer value differ. This plan uses contribution so service and product costs remain visible. [Shopify’s CLV analysis overview ↗](https://www.shopify.com/blog/customer-lifetime-value-analysis) ## Start small enough _to listen closely._ Launch support and controlled recommendations in stages. Commercial proof may take longer than the initial build and operational pilot. DAYS 1–14 ### Prepare the facts Choose the market and catalogue. Review 30 historical support questions with permission. Write approved care and payment answers. Define compatibility, consent wording, staffing and baseline metrics. OWNER · SUPPORT + MERCHANDISING Exit: each pilot SKU has verified facts, exclusions, and a named maintainer. DAYS 15–30 ### Make support reliable Build order linking, inbound support, human handoff and preference controls. Run offline scenarios for mistakes and edge cases. Shadow drafts with staff before customer use. OWNER · ENGINEERING + SUPPORT Exit: isolation, opt-out, duplicate prevention and handoff acceptance checks pass. DAYS 31–60 ### Learn with 100 people Invite up to 100 eligible customers voluntarily. Review every proactive draft manually. Use one product category and the shared contact cap. Ask for feedback after resolved cases. OWNER · OPERATIONS + ANALYST Exit: no unresolved critical failures; support team can handle the actual volume. DAYS 61–90+ ### Test incremental value Run the powered randomized comparison. Audit messages weekly. Expand only when contribution improves with acceptable uncertainty and customer outcomes remain healthy. OWNER · ANALYST + BUSINESS LEAD Exit: evidence supports expansion, or revise the approach and continue observing. ### Acceptance checks before live outreach - Opt-out after scheduling cancels the queued message. Bot block suppresses retries. - Concurrent triggers cannot exceed caps; daylight saving and unknown time zones behave correctly. - Open payment tickets and unresolved defects suppress all recommendations. - Wrong-size and owned products are rejected. Unavailable stock and stale prices produce no offer. - Replayed webhooks produce no duplicate response or action. Ambiguous sends are reviewed. - A person can take over with the case context. Refunds require an authorized decision. - Customer data cannot cross accounts; malicious text cannot invoke unauthorized tools. - Experiment assignment and all net orders reconcile to commerce records. ### Decisions needed from the business Actual brand and voice samples; catalogue and compatibility rules; country, languages and customer age requirements; commerce platform, payment provider and helpdesk; margin and returns data; support staffing and hours; privacy owner; budget and acceptable payback period. ### Estimate effort from real volume Monthly operating cost = conversations × average model cost + escalations × handling minutes × loaded staff cost per minute + platform costs + content maintenance. Add engineering, integration and legal review as setup costs. Use measured pilot volumes to budget. A larger model, more automated messages, or a discount does not automatically improve the customer’s outcome. THE FIRST RELEASE ### A customer can ask. A person can step in. _A useful suggestion can wait._ ## What this plan _is built on._ Platform constraints and external guidance are linked below. The product strategy, contact limits, story outcomes, ranking weights, and pilot targets are proposed choices to test. - [Telegram · Bots: an introduction](https://core.telegram.org/bots). User-initiated chat and the bot platform’s identity and interaction model. - [Telegram · Bot API](https://core.telegram.org/bots/api). Webhook secret validation, update IDs, send responses, and retry_after behavior. - [Telegram · Bot Payments API](https://core.telegram.org/bots/payments). Payment provider integration and responsibility for disputes. - [ICO · Electronic mail marketing](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/electronic-and-telephone-marketing/electronic-mail-marketing/). UK guidance covering direct messages, permission and opt-out. Market-specific, not universal legal clearance. - [Humanizer · Writing skill, v3.0.0](https://github.com/blader/humanizer/blob/main/SKILL.md). An editorial reference for removing generic AI patterns. It is not evidence of improved sales. - [Nielsen Norman Group · Humanizing AI Is a Trap](https://www.nngroup.com/articles/humanizing-ai/). A design perspective supporting clear AI identity and useful, task-focused interaction. - [Cloudflare · Queue delivery guarantees](https://developers.cloudflare.com/queues/reference/delivery-guarantees/). At-least-once delivery and the need to handle duplicate processing. - [Cloudflare · Pages Direct Upload](https://developers.cloudflare.com/pages/get-started/direct-upload/). Deployment of this static report through Wrangler. - [Kohavi et al. · A/B Testing Intuition Busters](https://exp-platform.com/abtestingintuitionbusters/). Experiment interpretation and common pitfalls. In Proceedings of KDD, 2022. - [Shopify · Customer lifetime value analysis](https://www.shopify.com/blog/customer-lifetime-value-analysis). Customer value models and the distinction between revenue and profitability. ### Boundaries of the report No customer data, brand catalogue, historical conversion rates, jurisdiction, support capacity or operating budget were supplied. English and USD are illustrative choices. This public report contains no real customer records and collects no analytics. The proposed service needs authenticated integrations, business review and a measured pilot before it can contact customers. No lift in LTV is guaranteed. Kitchen-knife examples assume lawful culinary products and eligible customers. Before expanding to other categories or markets, confirm applicable product, age, delivery and marketing requirements. Tone and timing should be tested with local customers, not copied across languages word for word. # Complete customer stories All people, products, prices, dialogue and outcomes below are fictional scenarios. ## Maya: The first-timer Maya has just moved into a small flat and started cooking most evenings. She bought her first chef’s knife and is worried about damaging it. - Bought: 20 cm chef’s knife · $85 - Told us: Small kitchen; drawer storage - Preference: Care + useful products - Timing: Europe/London · 10:00–18:00 ### What to remember - Use everyday words; explain one thing at a time. - Confirm storage before suggesting a guard. - No knife upgrade: the current one does the job. ### The conversation **DAY 3 · MAYA STARTS THE CONVERSATION** **Maya**: Can I put the knife in the cutlery drawer? **AI shop assistant**: A fitted guard will protect the edge in a drawer. Keep the blade clean and dry before putting it away. Do you already have a cover for it? **Maya**: No, just the cardboard it came in. **AI shop assistant**: The BG20 guard fits your knife and costs $12. It covers the blade for drawer storage. I can show you that one if you’d like. **Maya**: Yes please, send the details. **CHECKOUT IS OPTIONAL · NO FOLLOW-UP NUDGE** ### Outcome and follow-through Illustrative outcome: a $12 guard solves a stated storage need. The purchase is optional; a fitting cover she already owns would be just as good. Day 17: one opted-in care tip can be considered in her preferred window. Check contact history and purchase status first; do not pitch another guard. ## Leo: The professional Leo works in a restaurant kitchen and already owns a full knife roll. He wants quick, exact answers about maintenance, not an introduction to cooking. - Bought: 20 cm chef’s knife · $85 - Told us: Experienced; already owns guards - Preference: Relevant products, when useful - Timing: Europe/Berlin · 09:00–11:00 ### What to remember - Do not recommend a second guard or basic starter kit. - Ask how he maintains the edge before naming a tool. - Judge product fit from his use case, not his job title. ### The conversation **DAY 12 · LEO ASKS ABOUT MAINTENANCE** **Leo**: Need a different stone for this steel? **AI shop assistant**: Which stone are you using now? I’ll check it against the care guide for your knife. **Leo**: A 1000-grit water stone. It’s in good shape. **AI shop assistant**: That matches the approved guide for your model. Keep using it; you don’t need our stone. Follow the knife’s guide for the sharpening angle. **DAY 45 · SCHEDULED PRODUCT IDEA SUPPRESSED** **Internal decision**: He already owns an equivalent tool. No current unmet need. Send nothing. ### Outcome and follow-through Illustrative outcome: the conversation ends without a sale because his current whetstone is suitable. A useful answer protects his time and avoids a duplicate purchase. If Leo later asks for a sharpening service, check his location, eligible blade, turnaround and total shipping cost. Do not infer that a busy job means he wants one. ## Sam: The careful spender Sam cooks for a shared household and said they want to keep extra spending under $15. After several months, cutting tomatoes has become frustrating. - Bought: 20 cm chef’s knife · $85 - Told us: Accessory budget under $15 - Preference: Care tips only - Timing: America/Chicago · 17:00–18:00 ### What to remember - Keep the stated budget as a ceiling, not a target. - Care-only permission blocks proactive product offers. - A shopping question does not change future permissions. ### The conversation **DAY 75 · SAM ASKS FOR HELP** **Sam**: It struggles with tomatoes now. Do I need a better knife? **AI shop assistant**: It may need sharpening. Has the edge chipped, or has it gradually become less sharp? **Sam**: No chips. Just gradually worse. Trying not to spend much. **AI shop assistant**: A new knife isn’t the first step. Our sharpening service is $25 before any shipping, which is over the $15 limit you mentioned. A local service may cost less. The care guide can help you check the edge before deciding. **LATER · NO PRODUCT OUTREACH** ### Outcome and follow-through Illustrative outcome: no purchase today. Sam gets a next step and honest pricing. The assistant does not pressure them to buy a $39 stone or stretch their budget. Future care tips must still meet the cap and timing policy. The assistant does not send promotional messages unless Sam separately changes that preference. ## Nora: The gift buyer Nora bought a knife as a housewarming gift for her brother. She wants the recipient to get the care instructions without giving a shop his contact details. - Bought: Gift order · chef’s knife - Told us: Gift for another person - Preference: Support only - Timing: No proactive window selected ### What to remember - Mark the order as a gift; do not add it to her owned tools. - Do not ask for the recipient’s Telegram username. - The recipient can independently choose to start support. ### The conversation **DAY 1 · NORA ASKS ABOUT THE GIFT** **Nora**: This is for my brother. Are the care instructions in the box? **AI shop assistant**: Yes, this gift pack includes the care card. I can also share the digital guide here. **Nora**: The digital one would be useful. Please don’t send him offers. **AI shop assistant**: Here’s the guide for that model. We don’t have his details and won’t contact him. Your preference is support only, so you won’t get product messages either. **DAY 30 · GIFT-BUYER UPSELL SUPPRESSED** **Internal decision**: Recipient and buyer are distinct. No marketing permission or personal-use need. ### Outcome and follow-through Illustrative outcome: Nora receives the care guide she requested. No cross-sell, seasonal anniversary campaign, or contact with her brother is created. If the recipient later starts the bot, verify access through the gift support process without exposing the purchaser’s payment details. Obtain the recipient’s own preferences. ## Ellis: The let-down buyer Ellis was excited about a new knife. The tip arrived damaged and the payment statement looks wrong. They need ownership and a clear next step. - Bought: 20 cm chef’s knife · $85 - Told us: Chipped tip; possible double charge - Preference: Previously opted into product ideas - Timing: Support requested now ### What to remember - The open case overrides all product triggers. - Do not diagnose the charge from an unverified screenshot. - A confirmed resolution plus 7 days comes before any new offer. ### The conversation **DAY 2 · ELLIS REPORTS A PROBLEM** **Ellis**: The tip is chipped. And I think you charged me twice. **AI shop assistant**: I’m sorry it arrived like that. Please leave the knife unused. Can you send a photo of the tip? Don’t include any card details. **Ellis**: Sent. I just want someone to sort this out. **AI shop assistant**: The support case is open and includes your photo and order. The team will check the damage and payment references. They’re next available tomorrow at 09:00, your time. **AUTOMATION · RECOMMENDATIONS PAUSED** **Internal decision**: Fictional case creation succeeded; the published staffing schedule supplies the response time. No refund is promised before review. ### Outcome and follow-through Illustrative outcome: a human takes the case with the order context. A queued board recommendation is cancelled. Recovery is measured by resolution, not an immediate second purchase. When the team resolves both issues, ask whether everything is settled. Only after confirmation and a 7-day buffer can existing permissions be considered again. Unresolved payment issues keep the pause active. ## Inés: The busy regular Inés is a returning customer who writes in Spanish and prefers Saturday mornings. She asked for a board that fits a 32 cm space, then went quiet. - Bought: Chef’s knife and fitted guard - Told us: Board space 32 cm; budget $50 - Preference: Care + products · Saturday 10:00–12:00 - Timing: Europe/Madrid · customer-selected ### What to remember - Keep the chosen language and local schedule. - Verify the board’s full dimensions and $48 price. - Two unanswered proactive messages mean pause, not more reminders. ### The conversation **DAY 0 · INÉS SHARES A FUTURE NEED** **Inés**: Más adelante necesito una tabla. Tengo 32 cm de espacio y un presupuesto de 50 dólares. **AI shop assistant**: Lo guardo: hasta 32 cm y 50 dólares. ¿Quieres que te avise un sábado si hay una que encaje? **Inés**: Sí, los sábados por la mañana. **DAY 35 · SATURDAY · BOTH LIMITS CLEAR** **AI shop assistant**: La tabla CB30 mide 30 × 20 cm y cuesta 48 dólares. Encaja en el espacio que me comentaste. Te puedo pasar los detalles. Si ya lo resolviste, no necesitas otra. Puedes pausar estos mensajes en /preferences. **NO REPLY · SECOND UNANSWERED PROACTIVE TOUCH** **Internal decision**: Pause future outreach until Inés returns and confirms her preferences. API send success is not proof she read it. ### Outcome and follow-through Illustrative outcome: one relevant, permitted message goes out on a Saturday. When it becomes the second unanswered touch, automation pauses indefinitely. There is no urgency sequence. English summary: she stated her space and budget, accepted Saturday product ideas, and received one fitting board suggestion. After the day-0 conversation, a permitted day-14 care tip was unanswered. The day-35 board suggestion is the second unanswered proactive touch, so the next outreach review pauses automation. Use reviewed local-language copy in production. # Full journey examples ## Day 0: Make support easy to find. CUSTOMER-INITIATED ONBOARDING An order-confirmation link or parcel QR opens the bot. The customer presses Start. Offer secure order linking, explain AI identity and human help, then capture separate care and product choices. Buying from the shop is not the same as opting into Telegram outreach. > “I can help with your order and care questions. You can talk to a person anytime. Which messages would you like: support only, care tips, or care plus relevant products?” No start or no proactive permission? Keep help available and send no campaign. ## Day 3: A first useful care note. OPTIONAL CARE · CONTACT SLOT 1 If delivery is confirmed, care permission exists and there is no open issue, offer one SKU-specific care tip in the chosen window. Skip if the same tip was already covered in chat. Product promotion is not required. > “The care guide for your knife recommends hand washing and drying it straight away. That helps protect the handle and edge. You can pause tips anytime in /preferences.” This uses the same contact budget as product messages. A support-only customer receives no tip. ## Day 17: Return to something they asked about. OPTIONAL PRODUCT IDEA · CONTACT SLOT 2 At least 14 days after the day-3 tip, and only with product permission and a recent stated need, consider one fitting accessory. Re-check ownership, stock, budget, support status and whether the first touch got a reply. Two allowed slots do not mean two messages are owed. > “You mentioned keeping the knife in a drawer. The $12 BG20 guard fits your model. If you already found a cover, you’re all set. You can pause product ideas in /preferences.” No current need? Stay quiet. If this becomes the second unanswered proactive message, pause future outreach. ## Day 45: Maintenance follows use, not a timer. RE-EVALUATE · NO AUTOMATIC SEND A durable knife should not be replaced every few weeks. Only revisit maintenance if the customer requested a reminder or mentioned declining performance. Confirm whether they want a service or to learn; do not infer sharpening need from elapsed days alone. > “You asked for a reminder to check the edge around now. Is it still cutting cleanly, or has it started slipping on tomato skins?” Permission, contact limits, silence pauses and local time still apply to the requested reminder. ## Day 90: Review the program before scaling. BUSINESS REVIEW · CUSTOMER SILENCE IS VALID Compare customer outcomes and incremental contribution with the assigned holdout. Review opt-outs, complaints, support failures and returns. Customers with no new needs may receive nothing for the entire month. > Internal review: “Did we resolve more issues? Did contribution improve after costs? Did customers feel the messages were useful?” Do not turn the day-90 review into a blanket win-back campaign or a message asking opted-out customers to opt in again. # Simulator rules and starting economics The product outreach simulator checks, in order: established bot chat; product permission; open issue or recovery buffer; unanswered messages; category rejection; rolling contact cap; spacing; ownership and fit; availability; budget and need; known local time and quiet hours. It returns all blocking reasons and never sends a real message. A case with only a quiet-hours restriction is deferred for a fresh evaluation. Requested support uses a separate path. The default contribution scenario assumes 1,000 eligible customers, a 16% treatment repeat rate, 12% holdout repeat rate, $85 net repeat order value, 45% contribution margin, and $1.20 extra program cost per eligible customer. It produces 40 additional orders, $1,530 extra order contribution, $1,200 extra program cost, and $330 incremental contribution ($0.33 per eligible customer). These are assumptions, not measured outcomes or a forecast. The 1,000-customer figure is a scenario population for projecting the per-customer difference, not the sample size of a statistically powered experiment.