How EidenTech’s website lead chatbot works

The task: turn a question into an enquiry the team can use

A visitor may know they need a website, application, or automation but have an incomplete brief. The assistant explains EidenTech’s services, asks about the project, and collects a way to continue the conversation. It complements service pages and a contact form so visitors can choose how they enquire.

The required lead threshold is deliberately small: a name and valid email address or phone number. Interest and timing can be collected progressively. This example describes implemented behaviour; it does not claim a measured increase in conversions, revenue, or support resolution.

From website question to a follow-up record

1. 01Optional website widget
2. 02Server + approved company context
3. 03Validated contact fields
4. 04Google Sheets lead record

The React chat interface sends messages to a Next.js server endpoint. The endpoint supplies approved company information to the configured generation provider and asks for a conversational reply plus structured lead fields. The application normalises those fields and checks them before attempting storage. Model output supplies candidate information; the server decides whether the record meets the minimum save rule.

An illustrative conversation

This example explains the intended journey. It is not a real visitor transcript or a saved lead.

VISITOR

I need a website with a chatbot for my business.

ASSISTANT

We can help plan the website, company answers, and enquiry handoff together. What’s your name?

VISITOR

Ava.

ASSISTANT

What email address or phone number can the team use to follow up?

NEXT APPLICATION STEP

After a valid contact is supplied, the application attempts the save. A successful storage response allows the saved acknowledgement; the conversation can then collect project interest and timing.

Lead validation belongs in the application

The server trims and bounds text fields, normalises the email, and validates the minimum name and contact requirements. The Google Sheets storage function checks the lead again before writing. The lead row follows a defined column order for ID, source, industry, name, phone, email, interest, urgency, status, and creation time.

A browser-session identifier links continued messages to the same enquiry. The storage function looks up that session’s record and updates it when further project details arrive. This is session-level update behaviour; it is not a universal deduplication system for the same person across browsers or devices.

Google Sheets access uses server-side service-account authentication. Model and spreadsheet credentials stay outside the chat interface. The widget receives the reply, lead fields, and save result rather than provider secrets.

Generation and lead storage have separate failure paths

These paths help keep the experience understandable. The current implementation does not provide a durable background save queue, so a larger rollout may need additional persistence and an agreed recovery process.

Reproducible checks before connecting live enquiries

Use a test environment and a separate spreadsheet for scenarios that create records. Our application tests cover server behaviour; a customer release should also check the configured integrations, devices, and agreed conversations.

• ✓Ask a company question without contact details: the assistant should explain the relevant service and continue qualification.
• ✓Provide a name without email or phone: no lead save is confirmed; the assistant asks for a contact method.
• ✓Supply a malformed email without a valid phone: server validation prevents the lead from being saved.
• ✓Complete a name and valid contact method: the configured storage path must succeed before a saved confirmation appears.
• ✓Add project interest in the same session: the intended lead row is updated rather than appending a row for each message.
• ✓Simulate provider and storage failures in a test environment: fallback answers and failed-save feedback remain distinguishable.

What is implemented, and what needs a separate scope

This assistant uses approved company context, Groq and Gemini generation, server-side lead checks, and a configured Google Sheets destination. It is not presented as a document retrieval product, an authenticated customer portal, or an assistant that can take arbitrary business actions. Those features need their own data permissions, integration, and evaluation scope.

Current provider cooldowns and request limiting use process memory. Shared traffic controls, durable processing, broader identity matching, and a retention policy should be agreed for the intended deployment. A new customer implementation also needs approved company knowledge, provider and storage account ownership, usage expectations, and responsibility for lead follow-up.

Keep personal lead fields and conversation text outside ordinary analytics. EidenTech’s analytics integration records page views and performance metrics without sending contact details or chat messages.