Conversations + leads

Two views over the same data: every visitor exchange with your bot. Conversations is the full transcript view; Leads is the filtered "visitor left contact info" subset.

Conversations

Admin → Conversations lists every session, newest first. Each row shows:

  • The visitor's identifier (anonymous IDs unless you've wired up authenticated visitors).
  • The page URL the conversation started on.
  • The first user message (preview).
  • Number of turns.
  • Whether handoff was triggered.
  • Timestamps.

Click into a row to see the full transcript: every turn, every retrieved source the bot grounded on, every tool call (with arguments + response).

The top of the page has filters for date range, handoff status, and a free-text search. Search runs over the message content — quote a phrase you remember and you'll find the conversation.

If you're looking for patterns (questions Wilow struggled with), use Knowledge gaps instead — that page surfaces the top "the bot couldn't answer this" buckets, which is what you usually mean when you say "show me the bad ones".

Exporting

Export the visible filter set as CSV from ⋯ → Export. One row per conversation, columns include start time, page URL, message count, handoff flag, lead-captured flag. The full transcript isn't in the CSV — that'd be a JSON dump (use Settings → Data privacy → Email me my data if you want everything).

Retention

Default: conversations live forever. If you set a retention window under Account → Data privacy, conversations + their messages older than the window are deleted nightly. Captured leads are kept regardless of conversation retention — those count as a separate record.

Leads

A "lead" is a conversation in which the visitor gave you a way to follow up — an email, a phone number, or both. Admin → Leads shows just those.

How leads get captured

Two paths:

  1. Bot-initiated. Wilow is configured to ask for contact info when the visitor's question warrants follow-up ("can you have someone call me", "I need a quote", etc.). Configure how aggressive this is in Widget → Lead capture.
  2. Visitor-initiated. Visitor types their email/phone unprompted. Wilow extracts it, adds it to the lead.

The first contact captured per conversation creates the lead. Subsequent contacts in the same conversation update it (a visitor giving phone after email merges both onto one record).

What's in each lead

  • Email and/or phone (always at least one — that's what makes it a lead).
  • The conversation it came from, with full transcript.
  • Visitor metadata we picked up — IP-derived country (rough), browser, the page they were on.
  • Free-text "notes" the bot extracted (e.g. "asked about enterprise pricing for 50 seats"). Useful for routing to sales.

Acting on leads

Three options, pick one (or all):

  • Manual — open the Leads page, work the list, mark as contacted in your CRM.
  • Email digest — daily/weekly summary mailed to your handoff address. Configure in Notifications.
  • Webhook — POST every new lead to your CRM/Slack/whatever in real time. See Lead webhook.

The webhook is what most growing accounts land on — manual gets old fast.

PII redaction caveat

If you have PII redaction enabled (default: yes), visitor messages have emails/phones replaced with placeholders in the stored conversation. The lead record itself keeps the contact in clear — that's the whole point — but the underlying message body shows {{email}} instead of the actual address. This is intentional: minimize where contact details are persisted, store them once on the lead.

Pitfalls

  • CSV export ≠ data export. The CSV is a flat summary. For everything (full transcripts, sources, tool calls, audit log), use Settings → Data privacy → Email me my data.
  • Retention deletes hard. Once nightly retention sweeps a conversation, it's gone. Lead records survive (they're separate), but you lose the transcript context.
  • Anonymous = anonymous. Without authenticated visitor wiring, the visitor identifier is an opaque cookie value — meaningful only to that browser, not to your user database.