> ## Documentation Index
> Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Follow-up pages
> The page a captured lead lands on from your autoreply email — it greets them by name, schedules an introductory meeting on your calendar, and opens the phone number and links a landing page deliberately keeps closed.
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](/pages) like any other — same builder, same
publishing, same [custom domain](/custom-domains), same
[analytics](/page-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
| Section | What it does |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Greeting** | One line addressing the lead by their first name, taken from the link in your email. |
| **The booking card** | Your real calendar availability, in the visitor's timezone, with a details form already filled in — plus the meeting's what, where, and how long. See [Booking a visit](#booking-a-visit). |
| **Call the desk** | A tap-to-call line under the card, so a lead who'd rather talk to a person can — the one link a landing page could never carry. |
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](/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](/voice-widget#book-meetings-on-your-calendar) 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:
Connect Google Calendar, Calendly, or Cal.com in **Settings → Connectors**,
once for the organization.
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](/voice-widget#book-meetings-on-your-calendar) for
what each provider offers.
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](/dataset-row-actions) 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](/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`:
| Event | Fires when |
| ---------------- | -------------------------------------------- |
| `book_open` | A visitor opens the booking form on the page |
| `book_confirmed` | The meeting is booked on your calendar |
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
| You see | What to do |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The page greets everyone generically, or the booking form is empty | The link in your email isn't carrying the lead's details — check the autoreply's link, or ask Erdo to fix it. A link someone forwarded or retyped by hand behaves this way by design. |
| Contact details show instead of a booker | Scheduling isn't configured: connect a calendar and enable *Meeting scheduling* on the widget (see [What it needs](#what-it-needs)). |
| No open slots on any day | The page shows only what your calendar actually offers. Check the calendar or event type the widget's scheduling points at. |
| Bookings don't appear against leads | Bookings match leads by email. A lead who books with a different address becomes their own row — expected, and visible as a row with `booked` true and no landing-page attribution. |
| The concierge panel is empty | The page needs a widget that exists and is enabled — check the deployment in **Agents → Deployments**. |