Appearance
The lead lifecycle
What the Leads and Eloqua screens manage — and why a selection tool ends in a warm hand-off rather than a form dump.
What it is
When a visitor completes the guided flow and converts, their session becomes a lead: the needs-profile (key answers), the recommendation, and the systems they viewed. Two admin surfaces sit on this pipeline:
- Leads (
/admin/leads) — the read-only sales view of every converted session, filterable by date, track, and hot-lead flag. - Eloqua (
/admin/eloqua) — the configuration of the marketing hand-off: which session fields flow to which Eloqua contact fields, the target form binding, tracking and hot-lead scoring settings, and a connectivity check.
Why it exists
A recommendation the buyer walks away with is value delivered once; a recommendation that reaches sales with its reasoning attached is value that compounds. The lead view exists so a rep following up doesn't start cold — they see what the buyer actually needs, what was recommended and why, and whether behavior marks the lead hot. That context is the difference between a follow-up call and a qualified conversation.
Eloqua is where NanaWall marketing already lives, so NanaSelect integrates rather than inventing a parallel CRM. The integration is deliberately split in two: credentials live in Worker secrets owned by ops and never pass through the admin or D1; behavior (mappings, form binding, toggles) is admin-editable data. Failed submissions queue and retry, so an Eloqua outage never loses a lead.
Everything here is consent-gated at capture time — see privacy & data governance.
In the admin
| Screen | How-to |
|---|---|
| Leads | Reviewing leads |
| Eloqua | Configuring the Eloqua integration |
Learn more
- Eloqua integration reference — client architecture, secrets, downstream consumers.
- Behavioral metrics dictionary — what "converted" means, exactly.
- Session store — the anonymous record a lead is built from.