Before anyone books a demo, somebody has to justify it internally.
A platform lead who wants to embed payments does not need another article. They need a number they can put in front of a CFO, built from their own book of merchants, with the cost side shown rather than hidden. This is that number.
- 2
- Rails, priced apart
- 3
- Ways to carry the fee
- 0
- Figures we supply
Your book, your rates, your number. Every figure below comes from a field you filled in. Change anything and the right hand column moves.
Your platform
Card 55%45% Bank
Who carries the fee
What you charge
What it costs you
The part that actually travels
The number is useless until somebody else sees it.
Whoever ran this model is not the person who approves it. They have to walk into a room and defend the cost line, and a figure on a web page does not survive that room.
So the model stays open to everyone and the thing worth trading an email for is the version they can take with them, edit, and argue with.
- The model as a spreadsheet, with your figures already in it
- The cost assumptions written out, so the card line can be challenged
- The three fee structures side by side on one sheet
- What changes at 2x and 5x your current volume
What would happen next
The sheet sends now. Everything after it is decided by the answer above.
This is a concept build, so nothing is actually sent. The email carries the sheet and nothing else, because the thing somebody asked for should not arrive wrapped in a pitch. One button, and it is the sheet. No logo wall, no booking link, and the sheet is a link on the domain rather than an attachment, since an unexpected spreadsheet from your payments provider is the exact shape of a phishing attempt. Open the real email ↗
The vertical routes what follows: your answer maps to the articles Payload has already published for it, and to nothing else. A platform that serves law firms is not sent real estate material.
You did not tick the box, so the sheet and one follow up if it does not open is the entire relationship. That is not a downgraded experience, it is the one you chose.
You ticked the box, so a second record is written with its own timestamp, source, and the exact wording you agreed to. Under CASL what you have to produce later is when and how consent was given, and against what scope. A consent buried inside a download record cannot answer any of that, and a scope that only exists in a privacy policy cannot either.
It also means the promise is now a constraint on the sender. Articles for your vertical, plus a handful of things a year that change what the product does. The moment somebody sends a webinar invite against this record, the consent stops covering it, and that is a decision made at the box rather than at the send.
Reaching the demo page is a decision the reader makes, not a step the sequence forces. form_step_complete fires here with the vertical attached, which is the same signal the demo form captures on its first screen, so one person is one record across both. See the whole flow →