Expandi ProductPurchased mailboxes
Designed one checkout for domains and mailboxes, two things that bill differently, from a spec of rules about money.
Customers wanted email in the same sequences as LinkedIn: domains registered in their name, mailboxes on them, ready to send. The brief wasn't research; it was a billing spec with ten rules. Domains are paid yearly and never renew, mailboxes renew monthly, and both had to fit one payment.
- payment for domains and mailboxes together
- 1
- payment failures, each with a designed state
- 8
- rounds to get the billing page right
- 8
- Most buyers had never set up a sending domain, and a wrong choice costs them months of deliverability.
- Mailboxes bought on different days renew on different days, which turns an invoice into a puzzle.
- Agency owners and SDR leads adding email to LinkedIn outreach, buying for a team.
- Not deliverability experts, so they never see a DNS screen.
- I read each billing rule as a state the user must never reach, and designed backwards from those.
- Recommendations went into defaults rather than copy: two domains suggested, one on Gmail and one on Outlook, because spreading providers protects deliverability.
- Three steps, domains, mailboxes and review, with the order visible beside every one.
- One payment, eight designed failure states, and a confirmation that turns into assigning mailboxes to senders.
- Eight rounds on the billing page, until it held up against every one of the ten rules.
- In development: designed, prototyped in code and signed off.
- A customer goes from no email setup to ready to send without leaving the product, in about ten minutes in prototype tests.
(Keep browsing)
