Pre-payment check
Every sales page should show format, price, what is included, what is not included, digital delivery, and refund boundary.
- Product name.
- Price or path to price.
- What is included.
- Who it does not fit.
pre-launch
checklist
Trust checklist before sales launch
This page turns trust into a concrete check: are prices, rules, limits, support, privacy, email delivery, and recovery path visible?
Before ads and live payments, every sales door should pass the trust checklist.
Result check
The scroll should have not only beautiful text, but limits, next step, save path, and recovery.
- Reading boundary.
- Next step.
- Archive.
- Recover path.
Support check
Support should know what to do with lost link, payment success but no result, duplicate charge, refund, and deletion request.
- Lost link macro.
- Refund review.
- Email logs.
- Data deletion path.
What OmenHall should do
- Check trust checklist before release.
- Compare product pages with legal policies.
- Check email templates against privacy.
- Check mobile CTA and disclosure proximity.
What OmenHall should not do
- Do not launch ads without visible policy pages.
- Do not launch live Stripe without refund/recover flow.
- Do not hide age boundary.
- Do not make a demo from a real user question.
FAQ
Short answers
Is this public or internal?
It is public in spirit, written so users see product discipline. Detailed operational playbooks remain internal.
Why should a trust checklist sit near sales?
Because trust breaks exactly where the user pays, waits for email, or tries to recover access.