A website inquiry needs a clear handoff: enough context for a person to respond, a saved lead record, and a notification to the right owner. This demo documents two intake paths, with screenshots of the n8n workflow, Notion record, private alert, and workflow map email.
Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.
The demonstrated setup uses a contact form for structured requests and an AI chat for people who start with an open-ended question. The screenshots document that demo setup; the current FloxoLab contact form uses a separate email backend.
The useful workflow is not the chatbot by itself. It is the handoff: what gets saved, who gets notified, and what the human can do next.
Reproduce the intake decisions locally
Tested reference result: 12 synthetic fixtures pass, producing three in-memory lead records and six local sink events. Replays and repeated contacts create no additional record or alert; changed event payloads and conflicting identities go to review. This result comes from a separate local reference implementation checked on October 8, 2026, not a new run of the integrations shown in the screenshots.
Download the intake replay lab v1.0.0 (ZIP). It includes the executable logic, synthetic inputs, recorded output, instructions, and an inactive credential-free n8n reference export.
node run.mjs
12 fixtures → 3 records → 6 local sink events
repeat event → replayed → 0 writes
same contact, new event → duplicate → 0 writes
conflicting identity → identity_conflict → 0 writes| Input or failure | Decision | Effect |
|---|---|---|
| Whitespace and uppercase email | Normalize fields and lowercase email | Create one local record and alert |
| Repeated event or existing contact | Replay or duplicate | No extra sink events; preserve the original brief |
| Same identity, different email; changed replay payload | Human review | No automatic overwrite or merge |
| Two different addresses | Separate records unless identity conflicts | No provider-specific dot or plus-address merging |
| Missing fields; invalid input; declined collection | Ask for required fields; reject; stop | No record or alert; no further prompts after refusal |
Test boundary: Node.js local logic and a plain-JavaScript simulation of the export’s Code node pass. The export has not been imported or run in n8n. The ledger lasts one batch and loses its state on restart; it does not establish durable, concurrent CRM deduplication. No model, Notion, Telegram, or email adapter is called. For a live version, replace the in-memory keys with an atomic persistent store and test adapters, retry behavior, retention, and exception ownership separately.
Real tools, test data, and why that matters
This workflow shows the working intake pattern: validation, AI response, lead record, private alert, and follow-up email.
Production versions usually need more testing, cleaner edge-case handling, more careful copy, and fields that match the team's real sales or support process. A demo proves the path. Production makes it boring enough to trust.
1. Start with the boring form path
The contact form is the clean path. It already has the fields a human needs: name, email, current tools, budget range, and a short message. The workflow checks whether the email already exists, creates a Notion lead if it is new, sends a private alert, and returns a simple OK response.
2. Let the chat handle messy first messages
The AI chat is for the person who does not know what to put in a form yet. It validates the message, keeps a short safe history, sends a compact instruction set to Groq, and expects a JSON response with reply text, email-offer state, and optional plan data.
The AI prompt is not magic. It is a set of instructions that can be rewritten when the first version does not work.
3. Decide when the workflow should act
The decision point is deliberately plain. If the model says the email is ready and the user has provided enough context, the workflow checks for duplicates, creates a lead, builds an email, and sends it. If not, it simply returns the chat reply.
In production, that duplicate check should use normalized identity keys and an explicit conflict path. The n8n lead deduplication guide shows how to separate repeated events, safe CRM matches, and records that need human review.
4. Give the human something useful
The useful handoff is not "a lead arrived." It is a lead record with enough context, a private alert that tells the builder what happened, and a first-pass workflow map the user can reply to.
Demo vs production
The screenshots show the demo path and its outputs. Before using this pattern in production, test fallback paths, duplicate handling, error alerts, logs, and privacy-safe fields against the actual intake process.
Review the delivered email as an output: confirm its sender, subject, footer, reply path, and the fields the recipient needs. Test failure delivery separately from generating the message body.
Fields are flexible. The Notion database can have five fields or twenty-five: source, budget, tool stack, urgency, owner, status, next action, or whatever the handoff needs.
Alerts are flexible. The notification can go to Slack, email, Telegram privately, a CRM task, or the channel the team actually checks.
The AI behavior is flexible. It can ask one question, collect missing fields, draft the first reply, or stop and ask a human to review. The prompt is editable.
What can be customized
Start with the fields and next action the receiving team needs. Use representative test messages to check the handoff, then refine the prompt, routing rules, and output format before connecting live intake.
The CRM can be Notion, Airtable, HubSpot, Google Sheets, or something else. The email can be plain text or formatted. The AI model can be Groq, OpenAI, Claude, or no AI at all if the form fields are enough.
Adapt the intake pattern
Use the screenshots to inspect the earlier form/chat handoff, and the replay lab to reproduce validation and identity decisions. Define the required fields, exception owner, and next action before connecting your own tools.
The next integration gate is a controlled test of your persistent store, CRM record, notification, and reply path. Keep those results separate from the local fixture outcomes.