WooCommerce 11.0 continues Checkout Recovery as a beta feature. A manual recovery email should be tested against order status, payment state, customer address, opt-out state, extension filters, and previous sends. Do not assume every draft or failed checkout is eligible, and do not discover the rule by sending to live customers.
Use this for store owners, agencies, support teams, and extension developers testing Checkout Recovery on staging or with synthetic customer addresses before enabling it on a production store.
Quick answer
WooCommerce 11.0 Checkout Recovery Manual Send Status Matrix should be handled with a narrow evidence-first workflow: build synthetic orders, record eligibility inputs, run one manual send, then verify the result before making broader changes.
What to check first
- Create synthetic checkouts for checkout-draft, pending payment, failed, cancelled, processing, completed, refunded, and one custom order status.
- Record whether each order has a valid billing email, a customer account, a payment attempt, consent evidence, an unsubscribe state, and a previous recovery send.
- Run the manual-send action once per case and capture the admin response, email log row, recipient, template, order note, and any extension filter result.
- Repeat one eligible case after changing its status and repeat one ineligible case after restoring the missing requirement.
- Confirm that preview, staging, and test orders cannot enter a live recovery queue or contact a real address.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build synthetic orders | Create synthetic checkouts for checkout-draft, pending payment, failed, cancelled, processing, completed, refunded, and one custom order status. | Every tested status has an expected and observed result with a reason. |
| Record eligibility inputs | Record whether each order has a valid billing email, a customer account, a payment attempt, consent evidence, an unsubscribe state, and a previous recovery send. | Paid, completed, refunded, opted-out, and invalid-address cases do not receive an accidental recovery message. |
| Run one manual send | Run the manual-send action once per case and capture the admin response, email log row, recipient, template, order note, and any extension filter result. | Changing one eligibility input changes only the expected case, not unrelated orders. |
| Change one variable | Repeat one eligible case after changing its status and repeat one ineligible case after restoring the missing requirement. | The email log, order note, and customer inbox agree on recipient, template, timestamp, and send count. |
Why this usually happens
- Order status alone does not describe customer identity, payment state, or previous recovery activity.
- Extensions can add custom statuses or filters that change the eligibility result.
- A manual action may use a different validation path than an automated recovery schedule.
- Copied production data can contain real email addresses even when the store is running on staging.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case_id: CR-STATUS-04
order_status: checkout-draft
payment_state: unpaid
customer_email: recovery-test@example.test
unsubscribed: false
previous_send_count: 0
extension_filter: allow
expected_result: manual_send_available
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build synthetic orders
- Record eligibility inputs
- Run one manual send
- Change one variable
- Approve only proven states
Decision rule
Allow a manual recovery send only when the order meets the documented eligibility rule, the recipient is controlled during testing, and the evidence shows no prior opt-out or duplicate send. Keep the feature in pilot status until custom statuses and extensions pass the same matrix.
What to tell the client or owner
Provide the WooCommerce version, feature flag state, test order IDs, statuses, payment states, recipient domain, opt-out state, previous sends, extension filters, observed result, and email log rows.
Production verification checklist
- Every tested status has an expected and observed result with a reason.
- Paid, completed, refunded, opted-out, and invalid-address cases do not receive an accidental recovery message.
- Changing one eligibility input changes only the expected case, not unrelated orders.
- The email log, order note, and customer inbox agree on recipient, template, timestamp, and send count.
Mistakes to avoid
- Do not use a real customer address in the test matrix.
- Do not treat checkout-draft as automatically eligible without checking the remaining inputs.
- Do not test only the button state and skip the actual mail log and inbox.
- Do not enable automation while manual sends still produce unexplained differences.
Questions teams ask during testing
Should a failed payment order receive a recovery email?
Only if the store's approved rule treats that state as abandoned and the message does not conflict with a payment-failure or retry email. Test both workflows together so customers do not receive contradictory messages.
Can a custom order status be eligible?
An extension may alter eligibility, but the result must be tested and documented. Capture the filter owner and returned value instead of assuming a custom label behaves like a core status.
When HandL WP should help
HandL WP should help when recovery emails send to paid customers, skip valid abandoned checkouts, duplicate another order email, or behave differently across custom statuses. We can build the matrix and trace the eligibility decision through WooCommerce and the mail layer.
If this is active on a production site, test WooCommerce checkout recovery safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Checkout recovery concurrency and total tests
After eligibility is proven, run the scheduled-job duplicate-send race test so manual, scheduled, and retry paths share one durable send key. Then use the coupon, tax, shipping, and currency total test to reconcile the recovered cart with the final payment and analytics values.
Helpful references