Remember the contextA first knife. A small kitchen.
a.
AftercareAI shop assistant · human help available
···
A FEW DAYS AFTER DELIVERY
How should I store the knife?
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 guard?
Yes, I doHelp me find one
✓
Help → trust → relevanceThe relationship creates the opportunity.
AN ILLUSTRATIVE CONVERSATION
01 /Support comes firstResolve before recommending.
02 /Permission sets the paceUp to 2 proactive touches / 30 days.
03 /Useful beats urgentA 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.
02 / CUSTOMER STORIES6 different starting points
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.
03 / JOURNEY & TIMINGA calendar with room for silence
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.
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 ↗
04 / THE DECISION LABInteractive
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.
05 / VOICE & SUPPORTPlain. Warm. Specific.
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.
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 ↗
↗ 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.
06 / PRODUCT LOGICFit before margin
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.
Illustrative catalogue · USD sample prices, not live offers
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.
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
07 / SYSTEM BLUEPRINTA buildable proposal
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
Authenticate the event; deduplicate Telegram update IDs and
commerce event IDs.
Load a fresh customer and consent record. Cancel if
preferences changed.
Check support state, time zone, contact budget, and recent
unanswered messages.
Retrieve current price, stock, fit, and policy. Fail closed
for proactive offers when a source is stale or unavailable.
Reserve one contact slot atomically. Use customer + trigger +
policy version as the decision key.
Draft, check facts and tone, then call Telegram. Record the
message ID and confirmed status.
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 ↗
·
Queue 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.
08 / MEASURING VALUERevenue is only part of the story
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.
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 ↗
09 / THE FIRST 90 DAYSProposed delivery sequence
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.
10 / SOURCES & ASSUMPTIONSReviewed 9 September 2026
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.
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.