A GHL-centered customer journey with automated production, versioned brand and reading prompts, private PDF delivery, and a Slack alert for every successful sale.
4 GHL drafts saved12 native email templates saved6 n8n drafts saved inactiveThe public landing route and $19.99 offer were browser-verified October 19. The October 21 private inventory confirms the reusable assets. Payment, generation, inbox delivery and the complete customer journey still require testing.
Recommendation: keep GHL as the customer layer and use n8n with a durable order/item ledger for generation and recovery. The design supports automatic fulfillment. The build now has 4 GHL drafts and 6 inactive n8n drafts. Runtime connections and end-to-end acceptance tests remain incomplete. Nothing has been activated or sent.
Keep the native GHL purchase journey. A verified paid event creates the order, starts a separate Slack notification, and queues production only when that item has complete, correctly matched inputs.
Select a view. Green marks an eligible handoff, gold a decision, and rose an exception. The diagram shows the durable outbox design. The saved draft currently selects native GHL G04 for sale alerts; n8n A6 is an inactive alternative. Both paths require delivery testing.
Paid + complete, validated, correctly matched intake = Ready. A form submission, page visit or pipeline movement does not prove payment.
Confirmed direction: fully automated production, validation and delivery, with no routine human approval. Proposed internal target: 5–15 minutes after payment and complete inputs; this is not a measured result or public promise. Set the customer delivery SLA after end-to-end timing tests.
Thank You must show a neutral verification state when payment is unknown. It must never enqueue work.
Recommended: retain GHL for checkout, customer records, email and support. Use n8n with a durable order ledger for generation, validation, files and recovery. The lowest total cost depends on hosting, volume and operator time.
GHL stays the team’s customer workspace. n8n routes paid items, calls the calculation/model services, renders PDFs and coordinates guarded delivery. A database stores immutable order/item records and atomic claims; execution history is not the ledger.
Use the existing managed n8n host only after checking capacity, backups, restore, credentials and monitoring. Community software is free, but infrastructure and maintenance still cost money.
GHL has Payment Received, custom webhooks, GPT, Slack, email and Documents & Contracts. A native design may suit a short, simple output.
Prototype the long-form report renderer, per-item data binding, concurrent repeat orders, conditional chart/card sections, evaluator, private PDF attachment and recovery before choosing it. Native document capability alone does not prove this complete reading pipeline.
| Component | Proposed owner | Reason / build check |
|---|---|---|
| Funnel, form, checkout, CRM and support | GHL | Reuse native editable pages and saved templates. Prove attempt-to-item correlation; current form saves contact fields only. |
| Payment truth | Payment provider, reconciled through GHL | Success trigger is the signal. Verify provider transaction, actual order/items, total, mode and entitlement. |
| Orchestration and recovery | n8n | Product routes, provider calls, retries, timers and reconciliation. Persist checkpoints before side effects. |
| Order/item and event record | Transactional database | Unique keys, atomic job and send claims, immutable input/report versions, outbox and audit history. |
| Facts and interpretation | Chart / tarot method + AI writer + evaluator | Calculate or record evidence first. Writer and evaluator use versioned contracts and structured outputs. |
| Report and delivery | PDF renderer + private storage + GHL email adapter | GHL Send Email supports templates and optional attachment URLs; the messaging API supports HTML and attachment URLs. Prototype pinned template rendering with order-specific values and a unique item PDF. Do not assume a template ID performs merge substitution. |
| Sales notification | GHL G04 selected; n8n A6 alternative | Independent of generation. Deduplicate by paid order, reconcile unknown outcome, record acknowledgement. |
| Service | Published baseline | Budget implication |
|---|---|---|
| GHL premium actions | $0.01 per execution after 100 lifetime free actions per eligible subaccount | Payment webhook bridge: $1 per 100 sales at 1 action/order. Native Slack as another premium action: $2 per 100 sales for both. Excludes intake, callbacks, other actions and agency rebilling. Premium pricing |
| Workflow Pro | $10/month includes 10,000 premium actions; then $0.008/action | Compare total premium volume. External AI charges are separate. Plan details |
| GHL GPT | Base token pricing mirrors OpenAI; zero platform markup stated | Selected model, input/output tokens, evaluator and repairs determine cost. Agency rebilling may apply. Do not use a historical fixed GPT fee. Model pricing |
| LC Email | $0.675 per 1,000 emails | Count confirmations, delivery, follow-ups and exceptions. Authentication, provider path and actual account billing still need verification. LC Email |
| n8n Community | Free software; self-hosting costs excluded | May have low incremental cost on existing capacity. Budget hosting, backup, security updates and operator time. Community features |
| n8n Cloud | Starter €20/month annually: 2,500 executions, 5-minute execution limit. Pro €50/month annually: 10,000 executions, 40-minute limit | Schedules, callbacks and retries consume executions too. Confirm current plan limits before purchase. n8n pricing |
This calculator covers the payment bridge and 4 routine LC emails per order only. It excludes GHL subscription, n8n, AI, chart engine, storage, PDF generation, retries, taxes and operator time.
Uses standard metered rates without the free allowance or Workflow Pro. Actual account billing and pilot cost remain unmeasured.
Avoid the idle-polling cost trap. A 1-minute n8n schedule can create 43,200 executions in 30 days before any orders arrive. Use persisted due_at timers and bounded reconciliation, with the actual n8n hosting and wait/execution behavior tested. Timers cover known jobs only. To recover a missed payment event while pursuing the unmeasured 5–15 minute target, propose incremental provider-payment reconciliation at no more than 5-minute intervals, using a persistent cursor, overlap and deduplication. A 5-minute n8n schedule still uses 8,640 runs in 30 days before jobs, callbacks or retries: Cloud Starter is insufficient, and Pro’s 10,000 allowance may also be insufficient. Prefer maintained self-hosted n8n or a monitored host/database worker for this scan if available. A longer interval requires a looser recovery promise. Retain a separate daily money audit and monitor-health alerts; confirm cadence and recovery SLA before release.
For each SKU, record writer/evaluator input and output tokens, repair rate, chart costs, render time, storage, email count, n8n executions, support time and total paid-to-accepted time. Compute both infrastructure cost and total operating cost. Select the cheapest option that passes identity, recovery and delivery tests at expected concurrency. Pin approved model versions; do not trade output quality for an unmeasured token saving.
| Workflow | Trigger | Actions | Result | Failure / stop rules |
|---|---|---|---|---|
| Intake prerequisite | Valid native form submitted | GHL saves contact fields; orchestration stores immutable intake ID, product/version, timestamp and consent separately. | Generate checkout-attempt correlation. Never match only on latest contact fields or email. | Invalid/ambiguous input stays out of production. Multiple-tab and repeat-order matching must pass QA. Paid items Awaiting Details have their own aging clock: propose reminders at +24h and +48h, then an owner case at +72h, subject to approved service terms. Recheck completion, refund and hold before each action; do not wait for ready_at to monitor these items. |
| A1 · Order paid | GHL Payment Received filtered to Success and approved product/source, then downstream provider verification | Authenticate the event using the provider-supported verification method, then validate provider account, mode, status, amount/currency and order/items. Enforce quantity 1 per product line in the pilot; unsupported quantities become owner exceptions. Persist event; upsert 1 order, 1 job per item; enqueue E07 once per order and a separate deduplicated sale-alert outbox entry. Resolve the transaction to its actual order/items before fulfillment. | Ready if correctly matched intake is usable; otherwise Awaiting Details + E08. | Pending/declined does not queue. A pending payment is reconciled before a new charge attempt is permitted. Duplicate events return existing state. Unknown product/price or mismatch creates owner exception. |
| A2 · Produce | Paid item becomes Ready | Set ready_at once; enqueue job. Calculate chart or run configured product method. Draft from structured results; produce private versioned PDF. | Run deterministic checks and a separate automated content evaluation. Pass records a validation decision for the exact input/report version; repairable failures regenerate within bounded attempts; persistent failures enter Exception Hold. | Reuse the job key and existing valid results. Missing/invalid customer inputs request clarification; missing engine configuration holds for the owner. Transient engine/file errors use up to 3 infrastructure attempts; content failures use up to 2 repair attempts after the initial generation, then hold and alert. |
| A3 · Validate and deliver | Automated checks pass for the current input/report version | Recheck current payment/refund/dispute state, order identity, recipient, current intake version, current releasable validation, file checksum and delivery key. Dispatch the validated PDF automatically using E10. | Record provider message ID, accepted_at and delivery callbacks separately. | Refund/case/wrong recipient/missing artifact blocks release. Timeout after send is reconciled before any resend. |
| A4 · Deadline watch | Persisted warning/due timers plus bounded known-job recovery scan | Scan active incomplete items against immutable ready_at/due_at regardless of pipeline stage. Exclude accepted dispatches, cancelled items and confirmed fully refunded items. Warn owner at the configured warning threshold, proposed 80% of the customer SLA; mark overdue at due_at. Timing remains configurable until measured. | Send E09 automatically once when overdue, using factual delay wording without an invented ETA. A later specific ETA requires operational evidence. Accepted dispatch ends the production-to-send SLA; later bounce creates a separate delivery-failure case. Track confirmed-delivery timing separately. | Alert deduplication per item/threshold. Stage changes and retries never restart the clock. |
| A5 · After delivery | All non-cancelled order items have a provider delivery event, or documented send-accepted fallback | Schedule 1 E11 per order at +2 days and 1 E12 at +5 days from the last eligible item delivery basis. Recheck every item and order eligibility before sending. | Record delivery basis; fallback is never reported as confirmed inbox delivery. | Suppress for bounce, refund/dispute, unresolved case, relevant opt-out or reply needing help. Feedback eligibility is not sentiment-based. |
| Support and refund handling | Inbound reply, bounce, refund/dispute event or owner action | Open order-linked case; hold affected production/delivery and follow-ups. Reconcile money status with provider. | Owner resolves; E14 follows confirmed refund outcome. Resume only affected item after checks. | Do not treat moving a pipeline card as proof of refund. Partial refunds need item allocation and explicit disposition. |
| Reconciliation | Incremental verified-payment recovery scan, proposed ≤5 minutes if targeting rapid delivery; separate daily money audit and persisted item due timers | Read provider-paid changes with a persistent cursor and overlap; deduplicate and compare against ledger/jobs to recover missed webhooks. Separately compare validated reports against send/delivery logs and unsent Slack outbox entries. Daily money audit remains a second control. | Recover missed events through the same idempotent paths; alert owner on unresolved mismatch. | No blind workflow replay. Unknown send outcome goes to reconciliation. If the provider cannot resolve it, open a manual exception; an owner decides and records any resend after checking available message evidence. |
GHL: native pages, forms, checkout, CRM, order-view pipeline, sender and support conversations.
Payment provider: payment and refund authority.
n8n: persisted orchestration, product routing, generation, PDF assembly, retries, scheduled reconciliation and delivery coordination.
Durable database: order and item ledger with unique keys and atomic claims. Select the supported host before build; contact fields and n8n execution history are not the order ledger.
Automated validator: checks calculated facts, content structure, PDF integrity and correct order/recipient. Successful readings deliver without a human step. The owner receives exception alerts; the team also receives a deduplicated alert for each successful sale.
1 order per provider order. Pilot quantity is fixed at 1 per product line, giving 1 fulfillment job per line. Multiple units require order + line + unit keys and separate intake before quantity can be increased. The visible pipeline mirrors item state:
Awaiting Details → Queued → In Production → Automated Validation → Ready to Send → Sent → Delivered, when confirmed
Hold / Problem is a separate case state. Keep payment state, fulfillment state and delivery state separate so a refund or bounce is never hidden by a stage change.
Store order/item/payment IDs, product and price version, amount/currency, contact + order-bound delivery email, intake ID and immutable snapshot, method/template version, ready/due timestamps, report checksum/version, validation decision and validator version, message ID, delivery status and case/refund state.
Official trigger and integration references: Payment Received, Custom Webhook, Documents & Contracts custom values. Trigger delivery is not proof of correct item/recipient mapping.
The brand guide provides tone. The reading document provides 5 specialized prompts plus a master prompt. Their rules must be reconciled with the paid SKU before any prompt is allowed to generate a customer report.
The factual contract wins if a style instruction conflicts with accurate service information. Keep customer questions and free text inside data fields, not instructions. Do not hot-reload a changing Google Doc for each order: save an approved version and hash, record it on the job, and test revisions against reference cases.
| Paid offer | Supplied prompt mapping | Evidence and release condition |
|---|---|---|
| Existing astrology / catalog Astral Love, $19.99 | Birth Chart Psychic Reading | Fits the existing birth-date/time/place form. Calculate placements, valid houses/aspects and dated transits. Include the 7 thematic sections and exactly 3 personalized reflection questions. This existing SKU maps by ID to the supplied Birth Chart prompt. The similarly named tarot prompt stays unmapped; chart-engine validation is still required. |
| Soulmate Love Reading, $18.99 | Deep Soulmate Psychic Reading, proposed mapping | Keep the catalog’s recorded 5-card spread. Confirm actual product ID and spread-to-section contract. Potential partner descriptions are symbolic possibilities, not facts about identity, appearance or arrival dates. |
| Past Love Reading, $18.99 | Past Love and Heart Connection Reading | Use 6 recorded cards with licensed imagery, positioned interpretations and closure/boundary guidance. Never infer private feelings as fact or encourage waiting indefinitely. |
| 5-Question Reading, $19.99 | Five-Question Psychic Tarot Reading | Collect exactly 5 questions after payment. Preserve order and wording. Each answer group references the card(s) recorded for that question. The source does not fix the total number of cards; approve that spread. Include synthesis and 3 practical suggestions. |
| Soulmate Love Letter, $9.99 | Dedicated prompt missing | The catalog promises 1,000+ words. The master prompt is not a substitute for a letter-specific contract. Prepare and approve its prompt, sample and rubric before activation. |
| Supplied “Astra Love Psychic Reading” | Unmapped tarot prompt | This prompt explicitly uses tarot. The existing catalog calls “Astral Love Reading” a birth-chart product. Do not route by the similar name, rename the current product, or silently replace astrology with tarot. Confirm whether this is a separate SKU or a renamed offer. |
Return product and input versions, required sections, narrative, source references, reflection questions, uncertainty notes and evaluator evidence. Bind every named chart fact to engine output, and every tarot interpretation to a saved card/position. Render only validated fields into the report template.
The source asks for an email reading. Proposed adapter: the full reading lives in a PDF; a concise E10 email introduces it. Confirm that packaging before public copy promises it.
Resolve historical place/timezone before astrology. Unknown birth time excludes rising sign and houses; omit or label affected Moon placements and aspects. Transits need a calculation date and actual calculated results.
Tarot uses an approved deck, spread, selection and reversal method. Record the draw once per item, retain it through retries, and check image rights. The language model cannot invent or redraw the cards to make the story fit.
Require completeness, source-grounded facts, non-repetition, relevance to supplied context, respectful uncertainty, no invented third-party thoughts and no fear-based or guaranteed outcomes. Use an evaluator with isolated instructions and a versioned rubric; ask for explicit pass/fail reasons tied to the rubric. A model’s self-rating alone is insufficient. Uncertain outputs fail closed; repairable content gets at most 2 repair attempts after the initial generation before an owner exception.
Compare sample outputs against the source documents before launch, and rerun reference and adversarial regression cases whenever the model, prompt or rubric changes. Include short/long customer contexts, unrelated instructions inside a question, missing facts, contradictory cards/placements, unsupported timing requests, distress and questions outside the service scope.
| Prompt | Completeness rubric |
|---|---|
| Birth Chart | Core Essence; Soul Purpose; Love and Relationships; Career and Abundance; Challenges and Healing; What Lies Ahead only where calculations support it; Loving Message for Her Soul; exactly 3 personalized reflection questions and a loving close. Use second-person headings where needed for inclusive delivery. |
| Deep Soulmate | 8 themes: love-life energy; potential soulmate qualities; connection atmosphere; symbolic meeting circumstances; signs of compatibility; cautious timing; practical action now; future love journey. End with an affirmation. This is separate from the catalog’s 5-card count. |
| Past Love | 8 themes: connection story; lessons; unresolved feelings; symbolic other-person perspective; continuing impact; reconciliation or closure; present guidance; next chapter. End with the requested letter-style message. This is separate from the catalog’s 6-card count. |
| Five-Question | Exactly 5 original questions in order. Each has Cards and Their Message, What This Means for You, Beneath the Surface, Guidance From the Cards, and a Loving Takeaway. Then include the Bigger Picture, exactly 3 practical suggestions, and a Final Message. Every answer must use its saved associated draw. |
| Astra Love tarot / Love Letter | Hold the unmapped Astra Love route and missing Letter contract. Define required sections only after product mapping/prompt approval; do not infer them from the master prompt. |
Card count and narrative section count are different checks. Required headings may be rendered as flowing report sections; never meet a word target through filler or invented personal facts.
The documents contain useful voice guidance and several operating claims that are not yet verified. The proposed interpretation below makes the workflow reviewable without silently changing the offer.
| Source conflict | Proposed handling | Decision / evidence needed |
|---|---|---|
| Brand: 400 words maximum, no lists. Reading prompts: detailed sections, 5 answers and reflection questions. | Confirmed by Jason: the 400-word maximum applies to support and delivery emails. The paid astrology reading uses the confirmed target of 1,400–2,200 words. Other paid products retain separate length decisions. Customer-facing prose stays warm and natural, with short paragraphs following the brand guide. | Word-limit scope and astrology target confirmed. The workflow email pack uses 8 fresh native exports with short-paragraph copy adjustments; the reusable GHL library remains unchanged. Operational tables/maps can remain structured. Retain the existing Letter specification of 1,000+ words pending its missing prompt. |
| Brand says never mention AI and describes personally created / channeled readings. | Use a warm voice without fabricated human authorship. If asked how it is made, answer accurately about automated interpretation and calculated/recorded inputs. Never invent a personal channeling session. | Approve truthful production disclosure and customer-support wording. |
| Brand says 24–48 hours; old funnel promises instant, 24h or up to 72h; prior plan proposes 5–15 minutes internally. | Keep the public SLA unset until timed full-journey tests. Start the clock when paid and usable inputs are both present. Use factual delay notices. | Approve 1 customer promise with capacity margin and escalation coverage. |
| Brand says 60-day guarantee and refund arrival in 5–7 business days; older copy has other guarantees. | Do not publish or automate these claims from the style guide. Report provider-confirmed refund facts without promising bank settlement. | Approve actual refund/redo terms and link functioning policies. |
| Brand mentions bonuses, 3-email soulmate sequence, video, sketches and love spells. | Exclude those extras from this 5-product fulfillment scope. Do not create bonuses, a video route or a free sketch promise automatically. | Separate product scope and release evidence if any are intentionally offered. |
| Brand lists credit, debit and Apple Pay only. | Use actual checkout configuration, market and provider capability. | Verify available payment methods in the intended checkout. |
| Warm examples reference divine concepts; final boundary asks religious neutrality. | Use inclusive spiritual reflection and customer agency; avoid asserting divine authority. Mirror a customer’s beliefs respectfully without imposing them. | Confirm the wording boundary in approved samples. |
| Prompts assume “her”; identity and pronouns are not established by the 6-field intake. | Use second person and the provided name. Do not infer gender, orientation or private personal facts. | Optional pronouns only if useful and voluntarily supplied. |
| Brand discourages words such as “policy” or “deadline”. | Use plain, considerate wording, but never hide price, service limits, timing or refund terms. Internal operations can use precise labels. | Review service copy after the factual contract is approved. |
| Source supplies a US crisis number; customers’ locations are not fixed. | Keep high-distress and medical/legal/financial requests out of ordinary predictive content. Route to the defined support boundary and use location-appropriate resources when needed. | Approve escalation owner and response procedure before autonomous follow-up replies. |
Activation holds: the Astra/Astral Love product mismatch, the missing Love Letter prompt, product-specific paid-reading length standards, the actual SLA and refund terms require resolution before those affected routes can launch. They do not prevent building the shared order foundation and draft adapters.
| Internal key (proposed) | Catalog product | Price | Intake | Output specification | Funnel placement |
|---|---|---|---|---|---|
| AL-BIRTH | Astral Love Reading (Your Astrology Birth Chart Reading) | $19.99 USD existing offer | Before checkout: name, email, birth date, time or Unknown, city, country. Add exact/approximate/unknown certainty. | Calculated natal chart; relationships, strengths/challenges, career/life themes; calculated cycles only if included. | Reuse existing product and 4-step funnel. Review current binding before edits. |
| AL-SOULMATE | Soulmate Love Reading | $18.99 USD one-time | After payment: name, email, optional relationship context and focus. No mandatory birth details unless the approved method needs them. | 5-card reading; approved spread, recorded card selection, interpretations and synthesis. | Dedicated native product page/checkout and item intake. |
| AL-LETTER | Soulmate Love Letter (A message from your Soulmate) | $9.99 USD one-time | After payment: name, email, optional connection context and desired focus. | 1,000+ word reflective letter; never present it as another person’s actual thoughts. | Standalone offer first; optional add-on placement only after separate purchase/fulfillment tests. |
| AL-PAST | Past Love Reading (Your Ex-lover Reading) | $18.99 USD one-time | After payment: name, email, brief past-relationship context and focus. Use an alias for another person where possible. | 6-card tarot reading with licensed imagery, interpretation for each card and closing synthesis. | Dedicated native product page/checkout and item intake. |
| AL-FIVE | 5-Question Reading (Ask 5 Questions) | $19.99 USD one-time | After payment: secure instructions form with exactly 5 open-ended questions, optional context, and validation. | 5 clearly labeled questions, each with its own dedicated interpretation. Each question uses its recorded card(s); total card count and method need approval. | Dedicated checkout; thank-you and email both lead to the matched paid-order question form. |
This catalog baseline was read October 19; the October 21 GHL inventory still contains only the existing astrology product. It lists numeric prices without an explicit currency. The existing birth-chart offer is visibly USD. Jason confirmed USD one-time pricing for all 5 products in this chat. This is the configuration direction; the additional GHL prices have not been created.
The prompt-routing table adds a release hold for the Astra/Astral Love naming conflict and the missing dedicated Letter prompt. Catalog inclusion is not launch authorization. Use product IDs and approved contract versions, never a fuzzy name match.
First: complete the birth-chart route and shared order infrastructure.
Next: configure all 4 additional products as drafts, then enable each only when its input, sample, method, automated validation and delivery tests pass.
Later placement: related products can appear on a catalog page or through consented follow-up. A love-letter add-on remains optional, not selected by default. No recurring billing is proposed.
Known existing product: 6abd35524c307e7df3e5d543. Existing price: 6abd3560035320878709fb8c. Verify before edits.
Connected destination: #astraluna-sales in AstraLuna. GHL verified membership of this private channel. G04 contains the native Slack action and remains a draft. No test post has been sent.
Slack failure must not block the order confirmation, generation or delivery. Missing intake does not suppress a successful-sale alert; show “Awaiting details” if needed.
New AstraLuna sale Order: [[order_number]] Product(s): [[paid_items_summary]] Paid: [[actual_paid_amount_usd]] Time: [[paid_at_pht]] PHT Status: [[ready_or_awaiting_details]] Open order: [[verified_crm_order_url]]
Customer first name is optional. Exclude birth date/time/place, reading questions, complete report text and payment secrets. Use an actual access-controlled CRM link, not a fabricated URL.
A GHL Slack action after the same filtered Payment Received trigger can notify even if n8n is unavailable. It adds a premium execution and needs its own proven deduplication/unknown-outcome handling. G04 is the selected alert owner. A6 is an inactive outbox alternative with an owner gate that prevents posts. The native path still needs repeated-event, concurrent-order and unknown-outcome tests. Never activate both owners. GHL Slack action
Keep actionable exception alerts distinct from sales: order reference, failed stage, attempts, due time and safe operator link. Deduplicate by incident; resolve the alert when the underlying order is actually recovered.
No fixed page count, audio, portal or gift claim is added. The supplied SKU prompts determine required sections; reviewed output samples must establish final depth and design.
Every mandatory check must pass. A model saying its own output is good is not sufficient evidence. Keep the generator and evaluator separate, and use deterministic checks wherever possible.
Repair policy: allow at most 2 content-repair attempts after the initial generation for the same saved inputs/method results, then move the item to Exception Hold and alert the owner. Transient infrastructure errors have a separate bounded retry policy. Invalid customer data produces a secure clarification request. A repaired reading reruns every check before automatic delivery.
Validation before launch: assess the automation against real sample readings and reference cases. This is a system release check, not a human step on each customer order. Do not claim the proposed 5–15 minute target until timed end-to-end tests pass.
Capability references: GHL Send Email action and Send message API. The adapter must pin the saved template version and render order-specific values; it must not overwrite a contact’s latest report URL to drive concurrent orders.
Proposed pilot default: attach 1 validated PDF per product item to the reading-ready email. Use a filename such as AstraLuna_BirthChart_ORDERREF.pdf, without birth date or other sensitive input in the filename. Keep the source PDF in private storage, never the public Media Library. Supply a short-lived signed retrieval URL to the mail provider only when required by the selected adapter; verify the provider actually retrieves and attaches the intended PDF before expiry. Check PDF MIME type, identity, checksum, size and final inbox attachment. Do not expose the signed provider-fetch URL as a permanent customer download.
If size or provider support requires links, use a private customer-authorized delivery endpoint with tested expiry and resend handling. Do not substitute a publicly shared Drive file. Email acceptance, provider-confirmed delivery and customer access are separate events.
Sample status: the 2 supplied documents contain brand rules and generation prompts, not finished sample readings. Their contents were processed for this design. Generate reference outputs from approved evidence and review their PDF layout and rubric before activation.
| Priority | Gap / edge case | Action and acceptance evidence |
|---|---|---|
| Before generation | 6-field contact intake has no proven immutable payment correlation | Prototype order-bound snapshot + secure attempt reference. Test 2 orders, 2 tabs and edited contact fields. If native correlation is unavailable, request verified post-payment intake. |
| Before generation | SKU naming and prompt conflicts; no Letter prompt | Approve a product-ID-to-contract manifest. Unknown ID or unresolved route becomes Exception Hold, never a default birth-chart reading. |
| Before sending | Saved templates still have specification placeholders | Prove native-template/send adapter, HTML-escape values, reject unresolved variables, attach the exact validated PDF and freeze recipient/content per order. |
| Before sending | Unknown email outcome, refund race or changed intake | Persist send request; reconcile before retry. Recheck entitlement and current version at release. Corrections invalidate prior validation and queued dispatch. |
| Before traffic | Sender, replies, policy links and promise consistency | Authenticate the owned domain, verify monitored Reply-To and a real inbox; reconcile page/email terms and measured SLA. |
| Before traffic | Outages, missed callbacks and operator absence | Test database restore, durable queues/timers, missed-event reconciliation, monitor health, owner and backup. Bound concurrency and pause new traffic when capacity threatens the promise. |
| Before traffic | Sensitive data and report access | Private storage, scoped credentials, short-lived intake access, retention/deletion rules, redacted logs and cross-customer denial tests. Do not put birth data in Slack or analytics. |
| Before expansion | Quantity, bundles, add-ons and partial refunds | Keep quantity 1 per line initially. Extend unit-level input/entitlement and item refund allocation before exposing quantities or bundles. |
| During pilot | No measured per-SKU cost or runtime | Track generation/evaluation tokens, repairs, elapsed time, delivery failures, exceptions, support time and contribution. Review after 10 orders or 7 days from actual launch. |
Current October 21 build: 4 GHL drafts, 6 inactive n8n drafts, 12 saved email templates, 1 product at USD 19.99 one-time, quantity 1, and the active 6-field birth form. The product, form and templates are reusable assets. No successful checkout-to-reading delivery has been verified.
12 native editable templates are saved: 5 product delivery variants and 7 service templates. The 8 message types below include the shared E10 family. October 21 inventory confirms the library; no active workflow or send is established by that inventory.
These existing service drafts are retained as the operational baseline. Apply the supplied brand voice after factual terms are settled, preserving price, order status, next steps and honest authorship. Jason confirmed that the 400-word maximum applies to support and delivery emails. Paid readings have a separate length standard.
[[variables]] are specification placeholders, not verified GHL merge tags. Map them to order-level values before deployment. Missing required values must block sending; use “Hi there” when no first name is available.
Sender display: AstraLuna. From and Reply-To: a confirmed, authenticated mailbox on the owned domain, still to be selected. Domain attachment does not establish email authentication or inbox access.
Trigger: Paid order verified; once per order
Subject: Your AstraLuna order is confirmed
Preheader: Your order details and what happens next.
Hi [[first_name]], Thank you for your order. We’ve received your payment for [[order_items_summary]]. Order: [[order_number]] Total paid: [[paid_amount_currency]] [[next_step_block]] We’ll email each completed reading here when it is ready. If you need help with your order, reply to this email. AstraLuna
Complete inputs: “We have the details needed for [[product_name]]. Your reading is due by [[due_at_customer_timezone]].” Missing inputs: “We still need your details for [[product_name]]. Complete them here: [[secure_intake_url]]. We’ll confirm your delivery date once we have everything.” For multi-item orders, render 1 next-step block per item. Do not promise a due date for incomplete items.
Trigger: Paid item lacks usable inputs: initial E08 request, guarded reminders at +24h and +48h, then owner escalation at +72h. Proposed sequence pending SLA approval; stop on usable intake, refund or hold
Subject: A few details for your [[product_name]]
Preheader: Complete the details for order [[order_number]].
Hi [[first_name]], Your payment for [[product_name]] is confirmed. Before we prepare your reading, we need [[missing_details_summary]]. Complete your details: [[secure_intake_url]] [[product_intake_guidance]] We’ll confirm your delivery date after we receive the information we need. If you’ve already submitted it, reply and we’ll check your order. AstraLuna
Birth-chart guidance: “If you don’t know your birth time, choose Unknown. We’ll explain which parts of the chart can’t be established.” 5-question guidance: “Enter 5 open-ended questions. For example: What patterns can I reflect on in my relationships? What should I consider as I approach a career change?” Use secure per-item access; a bare order number is not authentication.
Trigger: Awaiting Details becomes Ready; once per item
Subject: We have your details, [[first_name]]
Preheader: Your reading is now in the queue.
Hi [[first_name]], We’ve received the details for your [[product_name]], order [[order_number]]. Your reading is now queued. We expect to email it by [[due_at_customer_timezone]]. If you notice a mistake in the information you submitted, reply so we can check it before completing your reading. AstraLuna
This supplemental template extends the existing 7 service messages. Due date comes from ready_at plus approved product SLA, not from email-send time.
Trigger: Active paid item overdue or held for production/delivery failure; once per incident; exclude cancelled/refunded orders
Subject: An update on your AstraLuna reading
Preheader: A delivery update for order [[order_number]].
Hi [[first_name]], Your [[product_name]] is taking longer than expected. I’m sorry for the delay. We’ll email you with an update when we have more information. If you need help with your order or the timing no longer works for you, reply and we will help you explore the available options. AstraLuna
This local exemplar updates the delay wording to avoid the brand guide’s prohibited word “policy”. The saved GHL template still needs that scoped copy update; it was not edited here. This version needs no invented reason or ETA and can send automatically after activation. Preserve the original deadline. Use a separate factual follow-up only when a revised ETA is known. Suppress duplicate delay notices.
Trigger: Specific PDF version passes automated validation; release checks pass
Subject: Your [[product_name]] is ready
Preheader: Your personal reading is attached.
Hi [[first_name]], Your [[product_name]] is ready, and your PDF is attached. [[product_delivery_intro]] Take your time with it. You can save the PDF and return to it whenever you like. If you have trouble opening the file or notice an issue with your details, reply to this email and include order [[order_number]]. Created for personal reflection and entertainment. The interpretations are not guarantees of future events or outcomes. AstraLuna
Attachment mode is the proposed pilot default. A secure download-link mode needs its own copy, tested entitlement/access, expiry and resend rules. Do not render “attached” unless the correct validated PDF is attached.
Trigger: 2 days after all eligible order items complete; once per order
Subject: Were you able to open your reading?
Preheader: A quick check on your AstraLuna order.
Hi [[first_name]], I’m checking that you were able to open the readings in order [[order_number]]: [[order_items_summary]]. If the file didn’t arrive, won’t open, or contains an issue with your details, reply here and we’ll help. AstraLuna
No upsell in the service check-in. Once per order after its last non-cancelled item completes. Suppress if an unresolved support case already exists.
Trigger: 5 days after all eligible order items complete; once per order
Subject: How was your AstraLuna reading?
Preheader: We’d welcome your feedback.
Hi [[first_name]], If you’ve had time to explore your order, [[order_items_summary]], we’d welcome your feedback. What was clear, and what could we improve? You can reply directly to this email. Thank you for sharing your experience. AstraLuna
Ask eligible customers consistently, without filtering for positive experiences. Do not automatically publish replies or turn them into testimonials.
Trigger: Provider confirms refund; owner sends during pilot
Subject: Your AstraLuna refund confirmation
Preheader: Refund details for order [[order_number]].
Hi [[first_name]], We’ve confirmed a refund of [[refund_amount_currency]] for order [[order_number]], covering [[refunded_items_summary]]. Refund reference: [[refund_reference]] Your payment provider or bank controls when the refund appears in your account. If you have questions about this order, reply here. AstraLuna
Use confirmed refund details only. Do not promise a bank settlement date. Partial refunds retain the correct remaining item/payment state.
| Product key | Delivery paragraph |
|---|---|
| AL-BIRTH | Inside, you’ll find a plain-language interpretation of your birth chart, with sections on relationships, personal patterns, strengths and direction. [[birth_time_limitations_sentence]] |
| AL-SOULMATE | Inside, you’ll find your 5-card reading and reflections on the relationship themes explored by the cards. |
| AL-LETTER | Your personalized letter is ready to read. It is a creative reflection on romantic themes, not a statement of another person’s actual thoughts. |
| AL-PAST | Inside, you’ll find your 6-card reading, with card imagery and reflections on your past connection and moving forward. |
| AL-FIVE | Your reading addresses each of your 5 questions in its own section. Your original questions appear alongside their interpretations. |
Choose a single owner for the transactional receipt. If the provider sends the payment receipt, E07 supplies service next steps rather than pretending to be a second receipt. Marketing consent remains separate from purchase messages. No post-purchase promotion is enabled by this plan.
Saved build, October 21: the 10 workflows below are reviewable drafts. Offline tests cover payment replay, order identity, prompt versions, bounded retries and guarded delivery. Runtime credentials, immutable checkout/intake correlation, verified chart data, private PDF rendering/storage and sender setup are still required. No purchase, generation or delivery run has been performed.
| Workflow | Open saved draft | State |
|---|---|---|
| G01 | Paid order to fulfillment | GHL draft |
| G02 | Birth-details intake signal | GHL draft |
| G03 | Customer reply to support hold | GHL draft |
| G04 | Sale alert to astraluna-sales | GHL draft |
| A1 | Paid orders and intake signals | n8n inactive |
| A2 | Reading production and quality | n8n inactive |
| A3 | Private PDF and guarded delivery | n8n inactive |
| A4 | Recovery and reconciliation | n8n inactive |
| A5 | Customer messages and followups | n8n inactive |
| A6 | Independent sale alerts | n8n inactive alternate |
| Test group | Scenarios | Pass condition |
|---|---|---|
| Purchase | Successful, declined, pending and retried payments; exact amount/currency; direct Thank You visit. | Only verified successful payment creates a paid job; retry cannot double-charge; Thank You does not authorize fulfillment. |
| Identity and repeat orders | 2 orders by 1 customer; 2 browser tabs; changed contact birth fields; missing intake; mismatched email. | Every item uses its own frozen input and correct recipient. Ambiguous matching goes to clarification. |
| Events and recovery | Duplicate, delayed and out-of-order callbacks; missed webhook; send timeout. | 1 order/job/confirmation/delivery per intended action; reconciliation restores missing state without replaying money or delivery. |
| Reading quality | 3 trusted chart cases; unknown/approximate time; timezone/DST; ambiguous city; invalid dates. | Calculation is reproducible; no invented houses/rising sign; uncertainty and affected Moon placement handled. |
| Additional products | 5-card and 6-card counts; licensed card imagery; 1,000+ letter words; 5 distinct question answers. | Each product matches its approved sample, intake and output rubric; no fallback to astrology production. |
| Validation and release | Failed validation, corrected intake after validation, repaired draft, refund before dispatch, quantity 2. | Only the current validated version sends; corrections cancel pending release. Quantity 2 is blocked or held. Payment/case checks run again immediately before release. |
| Delivery and support | Correct PDF attachment; wrong-recipient negative test; bounce; inbound reply; resend. | No cross-order report; errors visible to owner; controlled resend preserves version and order-bound recipient checks. |
| Timing | Ready timestamp, configured warning/overdue thresholds, stage changes, delayed input. | Clock starts once when paid and ready; state changes do not reset it. Accepted/cancelled/refunded items stop active SLA alerts; bounce is tracked as a separate failure. Delay notices send once without inventing an ETA; any later ETA must be supported by operational evidence. |
| Public funnel | Native pages/editor, mobile/tablet/desktop, SSL, navigation, form errors, policy links and support. | Live routes work and all displayed claims match fulfillment. Domain availability alone is insufficient. |
| Prompt routing | Astra/Astral collision, missing Letter prompt, altered Google Doc, prompt instructions inside customer text, wrong SKU. | Only an approved product-ID/contract version runs. User text cannot override the contract. Unmapped routes hold. |
| Slack and outage recovery | Duplicate sale, missing intake, Slack error, unknown post result, n8n restart, database restore, timer/reconciliation outage. | 1 acknowledged sale alert per paid order; notifications do not block delivery. Recovery preserves keys and original due times, and alerts do not silently disappear. |
| Template adapter | Missing merge data, repeated customer orders, API template support, wrong attachment, attachment limit, Gmail/Outlook/Apple Mail. | Frozen order values and correct validated PDF reach the intended inbox through the selected supported sending path. |
| Launch | Test gateway flow, actual sender/inbox, approved product settings, explicit release authorization. | Document saved draft, published and live-verified separately. No claim of real-payment verification without an authorized controlled live test. |
| Decision | Proposed default | Why it matters |
|---|---|---|
| Sample readings | Generate reference outputs from the supplied prompts and verified method data | Proves report depth, voice, imagery, completion rubric and rendering. |
| Delivery / validation | Fully automated production and delivery confirmed. SLA pending measured runtime; proposed internal target 5–15 minutes | Sets the public promise, alert timing and exception handling. No per-reading human approval is required. |
| Currency / billing | USD one-time for all 5 confirmed by Jason; no subscriptions | Apply the confirmed currency to the listed catalog amounts during configuration. |
| Production method | Chart engine + grounded drafting; approved card/spread method for tarot products | Prevents invented chart data or inconsistent product outputs. |
| Sender / support | 1 authenticated, monitored mailbox on an owned domain | Live page still contains .com addresses and placeholder policy links. |
| Exception coverage | Named exception owner and backup; measured automation capacity | Routine orders are fully automated; held failures still need an accountable resolution path. |
| Refund / clarification | Approve exact terms before copy and automation activation | Current footer promises need real policy destinations and consistent terms. |
| Storage / delivery | Durable transactional ledger; private storage; PDF attachment for pilot | Host, provider attachment support and retention/access rules need technical validation. |
The original inventory contained 0 workflows. The authorized build then saved 4 GHL drafts and 6 inactive n8n drafts. The account retains 12 native email templates and 1 bound product. No activation, external send, payment-mode change or publication occurred.
Published platform rates and capabilities are linked beside the relevant recommendation. They are provider baselines, not a quote for this account. Private sender settings, live payment behavior, n8n hosting capacity, item correlation and email/PDF delivery require implementation tests.