Concept build · September 2026
The demo page payload.com does not have.
A teardown of payload.com found that every conversion action on the site is a modal with no URL, so there is nothing to advertise to, measure or link. This is the page that fixes that, the booking screen behind it, and the emails that follow. Then the same problem one step earlier, for the reader who is months away from buying anything. Built by Jacob Gilliam. Six links, roughly twenty five minutes.
Someone ready to talk
Acquisition. A stranger with intent becomes a booked meeting.
The demo page
Four screen form, qualification gate, and a reasoning layer you can toggle on.
Open → 02The booking screen
Where the calendar lives, and where the gate explains itself if it declines you.
Open → 03Everything after the submit
Four paths, seven emails written as code, and the reasoning behind each decision.
Open →Someone who is not ready yet
The other ninety percent of the traffic. A reader becomes a known person in a vertical.
The vertical page
They published a piece for construction platforms on 16 September. There is no page for anyone who reads it.
Open → 05The revenue model
What embedding payments earns a platform, and the one asset that survives the room where it gets approved.
Open → 06After the model
What happens to somebody who downloads a spreadsheet, which is not the same as a lead.
Open →What stops a send
Both flows run over the same contact record, so the rules that cancel a send are shared. This is the half of lifecycle work that never appears in a flow diagram and is the reason a sales team will tolerate one running.
| signal | what happens |
|---|---|
| They reply to anything | Every queued send in both flows cancels. A person answered, so the software has nothing useful left to say. |
| Somebody at Payload emails them | Suppressed for 14 days from that send, renewed by each new one. Marketing does not talk over a live human conversation, and a rep should never have to ask the CRM for permission to email a prospect. |
| An open opportunity on the record | Suppressed entirely until it closes. Sales owns the relationship at that point and a nurture email reads as the left hand not knowing. |
| They are in both flows at once | The demo flow wins and the model flow exits silently. Somebody who just booked a call does not need an email asking whether their spreadsheet arrived. |
| A meeting is already booked | Nothing that asks them to book can send. Path C's reminder is the obvious one, and it is the single most common automation embarrassment there is. |
| Unsubscribe or a hard bounce | Suppressed permanently, both flows, immediately. The bounce also joins the deliverability report grouped by recipient domain. |
Suppression is checked when the email sends, not when the person enrols. Enrolment is a snapshot and sending is the moment that matters, so a contact who was clean on Monday and got a call on Wednesday is still caught on Thursday. Getting this backwards is why a prospect who spoke to a human on Tuesday still receives "still want the thirty minutes?" on Friday.
Where it would actually live. Payload's sending domain already authorises HubSpot alongside SendGrid, Zendesk and Google Workspace, so the contact record is the natural place for these as properties, with the transactional sends staying on their own rail. Nothing here needs a new tool. It needs the send step to read five properties before it fires: last reply, last human email, open opportunity, upcoming meeting, and email status.
Start with the demo page and click the button in the bottom right. It turns on an annotation layer that explains what each element is doing and which teardown finding it answers. If you only read one page, read 03 or 05. Those are the two that are actually about email.
Built from the outside looking in, as a demonstration of what the system could be. Everything in it came out of a week inside payload.com: every conversion path clicked and logged against the address bar, the URL structure mapped, the DNS and the page tags read, and the full article archive sorted by vertical. Nobody at Payload was asked anything and no internal system was seen, so nothing here claims to describe how Payload works today. Where a flow names an owner it says "whoever owns" on purpose, because the org chart is not visible from out here and guessing at it is the fastest way to be wrong about something that matters.
Concept work. Not commissioned by Payload and not affiliated with Payload, LLC. Customer logos are Payload's own published assets and the quote is Bridgit Chayt's, from Payload's August 2026 Fifth Third announcement. Both illustrate a layout and imply no endorsement. Sample recipient and availability data throughout.