Skip to main content
A landing page has one job: turn a visitor into a lead. Everything on it pushes toward the form, which is why Erdo builds landing pages as a closed surface — no outbound links, no phone number, nothing that lets a visitor leave before converting. Once someone has converted, that job is done and the constraint stops making sense. They gave you their name and email; asking for them again is a step backwards. A follow-up page is the page for that moment — the one your autoreply email links to — and it is deliberately simple, like a scheduling link’s booking page wearing your brand: it greets the lead by name and offers exactly two things, your real calendar availability so they book a visit in a few taps, or your sales desk’s number if they’d rather talk. Nothing else competes with those two actions.
A follow-up page is a page like any other — same builder, same publishing, same custom domain, same analytics. What’s different is what it’s for, and the components it’s built from.

​
Getting one

You ask, the same way you ask for anything else Erdo builds:
“Build a follow-up page for the Riverside development — the one leads land on from our autoreply email. Let them schedule an introductory meeting on our calendar.”
Erdo builds it from your brand’s own imagery and typography, so a lead who converted on your landing page recognises the same brand when they arrive. You usually need one per development or product line, not one per campaign: every landing page and every variant feeding the same leads can point at the same follow-up page. A follow-up page only works public — a private draft would 404 for the exact lead your autoreply just linked — so when the agent builds one it publishes it in the same breath (you approve the publish, like any page going live). It gets a public URL on your own domain if you’ve connected one.

​
What’s on it

That’s the whole page — your logo on top, a small footer at the bottom. No galleries, no marketing sections, no widget: the lead saw your landing page already, and everything added here would only compete with the calendar.

​
How it knows who’s reading it

The link in your autoreply email carries the details of the lead you sent it to — their name, email address and phone number. The page uses them for two things, and nothing else:
  • it opens with “Welcome back, Maria” rather than a generic headline, and
  • the booking form arrives already filled in, so a lead who wants a time picks one and confirms instead of typing details you already have.
Anything they change is theirs: the page never overwrites a field they’ve edited or cleared. And if the details aren’t in the link — someone forwarded it, or shared the plain URL — the page falls back to a neutral greeting and an empty form. Everything else works exactly the same, so a shared link is never broken, just less personal.
The lead’s details never reach your analytics. Page URLs are recorded verbatim by your page analytics — the Page events dataset, session replay, and your Google Analytics property all store one. The details therefore ride the link in the part of a URL that browsers never send to a server, and Erdo removes it from the address bar before anything records the page. So a name, an email or a phone number cannot end up in an analytics report, a replay, or a shared screenshot of the address bar.
The page shows only what its own link carried. It holds no lookup of your leads, so a forwarded link can never expose one lead’s details to another person — it just carries the original lead’s greeting, which is why a forward reads as slightly odd rather than as a leak.

​
Knowing who visited

Every lead’s link carries their own pseudonymous reference (?lid=…), and the page’s ordinary analytics record it on each pageview. So “did this lead open the page I sent them” is a question about your page-events data — ask it in chat, exactly as you’d ask any other analytics question:
“Which Riverside leads opened the follow-up page more than three days ago and still haven’t booked?”
Erdo joins the page-events rows to your leads dataset on the reference and answers with the leads themselves. Because every visit is an event, you also get the full history — first open, latest open, how many times — not just a single timestamp. Two things are worth knowing about how this behaves:
  • A visit never creates a lead. If a link was forwarded and someone Erdo has no lead row for opens it, the pageview matches nobody. Your leads dataset only ever holds people who gave you their details.
  • It works for leads you only have a phone number for. The lead is identified by email when they gave one and by their phone number when they didn’t, so a phone-only lead is not invisible to this.
The lead is matched by a pseudonym, not by their details. The link carries a short reference — ?lid=… — that Erdo generated for that lead when it was captured, using a key only Erdo holds. It identifies a row; it says nothing about who the person is, and it cannot be turned back into an email address or a phone number by anyone who sees it. That is what lets it travel in the visible part of the URL, and therefore into your analytics, where it becomes the join between a lead and the pages they read.So the two halves of the link do opposite things, deliberately: the pseudonym goes to the server; the details never do. The name, email and phone that greet the lead and fill in the booking form stay in their browser for the life of the page and are never sent anywhere.
Leads captured before this shipped have no reference, so their visits can’t be attributed. New leads carry one from the moment they’re captured.

​
Booking a visit

The whole reason for the page is usually this one: a lead who’s interested should be able to pick a time without an email thread. The page shows a strip of upcoming days, the real open slots on each one read live from your organization’s connected calendar, and a short form for the details — filled in already, from the link that brought them there. It is the same booking flow the website widget offers, laid out inline on the page instead of inside a chat panel. Everything is shown in the visitor’s own timezone, and days your schedule has no openings for are left out entirely, so what’s offered always follows your real calendar settings.

​
What it needs

Booking on the page runs on your website widget’s scheduling configuration, so the prerequisites are exactly the widget’s:
1

Connect a calendar

Connect Google Calendar, Calendly, or Cal.com in Settings → Connectors, once for the organization.
2

Enable scheduling on your widget

In Agents → Deployments, turn on Meeting scheduling for the widget and pick the calendar (Google) or event type (Calendly / Cal.com). See Book meetings on your calendar for what each provider offers.
3

Point the page at that widget

Tell Erdo which widget’s scheduling the page should book through when you ask for the page. The widget itself doesn’t appear on the page — its scheduling setup is just where the calendar lives.
If scheduling isn’t configured — no calendar connected, or scheduling switched off — the page doesn’t show a broken booker. It falls back to your contact details: the phone number and a way to get in touch. So a follow-up page is always shippable, and turning scheduling on later upgrades it with nothing to rebuild.

​
What a booking does to the lead

A booking made on the page lands on your connected calendar exactly like one made through the widget, and the visitor gets the calendar invite by email from your calendar provider. It also updates the lead. The row is matched by email, so the person who filled in your landing-page form and then booked from the follow-up page stays one row rather than becoming two — and that row’s booked column flips to true with the meeting’s start time. That makes the follow-up queries plain questions about a dataset:
“Which leads from the Riverside page booked a meeting this week, and which opened the booker without finishing?”

​
Pairing it with your autoreply email

The follow-up page and the autoreply are two halves of one flow. When a lead lands in your leads dataset, a row action sends them the autoreply, and the link in that email is the follow-up page with their first name attached. Because the row action hangs off the dataset rather than a particular form, every landing page and every variant writing that dataset gets the same autoreply and the same follow-up page — including pages you launch next month.
Ask Erdo to set both up together — “autoreply every new Riverside lead and send them to the follow-up page” — and the link, the lead’s details on it, and the row action are wired for you.

​
Measuring it

A follow-up page is a published page, so everything in page analytics applies with nothing to switch on: session replay and heatmaps, your organization’s Google Analytics property, and the first-party Page events dataset in your own workspace. Two events are specific to the booker, alongside the standard pageview, scroll_*, cta_click and watch_video: Together with pageview they give you the funnel the page exists to move — arrived, started booking, booked — per page and per campaign, as a query over your own dataset:
“From the Page events dataset, show pageview → book_open → book_confirmed for the follow-up page over the last month.”
These are page events, recorded by the page itself. They’re separate from the website widget’s own voice_widget_book_open / voice_widget_book_confirmed events, which cover bookings made inside the widget’s chat panel. A page whose visitor books through the concierge instead of the inline booker shows up in the widget’s stream.

​
Troubleshooting