Audit lifecycle email drop-offs and generate fix recommendations

Export email and journey data from Customer.io or HubSpot for the lifecycle sequence you want to audit. Include sends, delivered, opens, clicks, unsubscribes, spam complaints, journey exits, delays, segment criteria, branch logic, and goal or conversion events. Pull GA4 data for the landing page or app destination when the email drives a click outside the email platform. Add baseline conversion or activation metrics so the audit does not stop at opens and clicks. Put everything into Google Sheets with one row per lifecycle message or journey step.

For every email or journey step, write the behavior the user is supposed to take next. Examples include verify email, complete setup, invite teammate, connect integration, book a call, view pricing, return to product, read a case study, or request support. Add the target segment, timing delay, entry criteria, exit condition, CTA, destination URL, and owner next to each message. This makes it obvious when the email copy asks for one action while the workflow logic expects another. The journey map becomes the reference point for all diagnosis and test recommendations.

Use the workbook to mark emails with low click rate, poor downstream conversion, high unsubscribes, high complaints, sharp journey exits, or weak progression to the next behavior. Compare each weak point against surrounding emails so you do not overreact to naturally lower-intent steps. Classify each issue as likely copy, CTA, timing, segment, deliverability, destination, tracking, or product-friction related. Prioritize the 5-10 issues closest to activation, conversion, expansion, or meeting booking. This prevents the audit from becoming a long list of cosmetic email edits.

Open Claude and paste the prompt below with the priority drop-offs, journey map, metrics, segment rules, timing, branch logic, destination URLs, and email copy. Ask it to diagnose whether each issue is caused by unclear value, weak subject line, wrong CTA, too much copy, poor timing, broad segmentation, message-to-page mismatch, missing proof, broken tracking, or a bad exit condition. Require the model to cite evidence from the metrics and copy before recommending a fix. Copy the diagnosis into Google Sheets next to each weak point as the root-cause hypothesis, not as final truth. If the data points to segment or timing problems, do not accept a copy-only recommendation.

Diagnose lifecycle email drop-offs from this data.

Journey goal:
{{journey_goal}}

Journey map:
{{journey_map}}

Email performance data:
{{email_metrics}}

Email copy and CTAs:
{{email_copy}}

Segment rules and timing:
{{segment_and_timing}}

Post-click conversion data:
{{post_click_data}}

For each weak point, output:
1. Likely root cause
2. Evidence from the metrics
3. Evidence from the copy or CTA
4. Evidence from timing, segment, or destination data
5. One testable hypothesis
6. Recommended fix
7. Revised subject line, if needed
8. Revised CTA, if needed
9. Segmentation or timing fix, if needed
10. Test priority

Do not blame copy when the data suggests segment, timing, destination, or tracking problems.

Open Claude and paste the prompt below with the approved root-cause diagnosis, original email copy, segment rules, timing rules, and destination context. Ask it to draft fixes that match the diagnosed cause: revised subject lines, preview text, body copy, CTA, proof blocks, and microcopy for copy problems; timing, segment, branch, suppression, or exit-condition changes for journey problems; and landing-page or in-app alignment notes for destination problems. Copy each recommendation into the test roadmap with the hypothesis, affected segment, primary metric, guardrail metric, and implementation owner. Keep each recommendation tied to one hypothesis so the later test result is interpretable. Do not rewrite every email when the issue is actually logic, timing, or tracking.

Draft lifecycle email fixes based on these diagnoses.

Root-cause diagnoses:
{{root_cause_diagnoses}}

Current email copy:
{{current_email_copy}}

Brand voice:
{{brand_voice}}

Journey constraints:
{{journey_constraints}}

For each priority issue, return:
1. Hypothesis being tested
2. Revised subject line
3. Revised preview text
4. Revised body copy
5. Revised CTA
6. Timing or segment rule change, if needed
7. Destination or landing-page note, if needed
8. What should not change in this test
9. Success metric

Do not invent proof points or promise product behavior that is not true.

Move each recommendation into a test roadmap in Google Sheets. Include hypothesis, affected segment, current baseline, expected metric movement, primary success metric, guardrail metric, test duration, sample-size note, owner, implementation effort, and rollback condition. Prioritize based on business impact, confidence, and effort instead of editing convenience. Mark fixes that should be launched immediately because they repair broken tracking, broken links, or incorrect logic. The roadmap should make it clear what you are testing and what result would change your mind.

Before launching any test, QA links, UTMs, conversion events, goal criteria, suppression rules, journey exits, branch logic, unsubscribe behavior, and CRM field updates. Test with at least one internal user or test contact that matches the target segment. Confirm that users leave the sequence when they complete the intended behavior and do not receive irrelevant follow-ups. Launch only the first 2-3 highest-priority fixes so you can monitor them closely. Document the baseline metric and launch date in the roadmap before changes go live.

After the test window, compare results against the baseline and guardrail metrics. Open Claude and paste the prompt below with the baseline, test result, segment notes, copy changes, journey-rule changes, and any sales or support feedback. Ask it to summarize what improved, what got worse, what was inconclusive, and whether the root-cause hypothesis was supported. Copy the learning into the lifecycle playbook, then have the lifecycle owner decide whether to keep, roll back, iterate, or run a follow-up test. Add winning patterns, failed hypotheses, segment notes, and tracking lessons so each audit compounds instead of becoming a one-off cleanup project.

Analyze lifecycle test results and update the playbook.

Test roadmap:
{{test_roadmap}}

Baseline metrics:
{{baseline_metrics}}

Post-test metrics:
{{post_test_metrics}}

Guardrail metrics:
{{guardrail_metrics}}

Qualitative feedback:
{{qualitative_feedback}}

For each test, return:
1. Result: keep, roll back, iterate, or inconclusive
2. Evidence for the result
3. Whether the hypothesis was supported
4. Segment-specific learning
5. What changed in user behavior
6. What to test next
7. Playbook rule to add
8. Tracking or QA lesson

Focus on behavior change, not only opens or clicks.