Independent project · Working MVP
LeadOS
From a first conversation to a useful handoff.
AI that answers questions through voice and chat, classifies leads by interest and readiness, and prepares summaries to help the sales team follow up.
At a glance
The conversation ends. The context carries forward.
- What I built
- A public website, two staff portals and the backend, including authentication, AI integrations and live updates.
- What it delivers
- Voice and chat grounded in approved business knowledge. After the conversation, AI assesses interest and prepares a summary and next steps for sales.
- Engineering focus
- Store transcripts before analysis, handle repeated call events and enforce access boundaries so a conversation becomes a reliable handoff.
Working MVP. Public chat is available to try; voice demos use protected staff workflows. Sales conversion impact has not yet been measured.
A conversation should leave something useful behind.
For financial services partner acquisition, the first conversation is rarely just a yes or no. A prospective partner asks about the product, describes their network and raises concerns. The sales team needs that context when it follows up.
I built LeadOS to connect those steps. AI answers questions through voice and chat, identifies a lead's interest and prepares useful context for the next conversation. The goal is a clearer handoff, with a human still responsible for the relationship.
One product, three places to use it.
I built the public website, admin portal, relationship manager portal and the backend connecting them. The public experience captures a lead and starts a chat. Admins manage approved knowledge and review conversations. Relationship managers see assigned leads, objections, summaries and suggested next actions.
That meant working across product flows, interfaces, authentication, stored conversations, AI integrations and live updates. The important part was making the information travel cleanly from one person and system to the next.
Useful answers start with controlled knowledge.
Chat retrieves relevant information from business content approved by an admin. The content is distilled and synced into Mem0, then retrieved for the conversation. Gemini generates replies using that context. Analysis uses the transcript to assess interest, readiness and network fit, producing a hot, warm or cold classification.
Voice has its own knowledge path through Vapi managed documents. I kept these integrations separate while bringing their transcripts into the same analysis and handoff workflow. Voice document uploads remain manual in this MVP.
Mem0 holds shared approved business knowledge, rather than long term memory for each lead. Continuity for a lead comes from the conversation transcript and generated summaries. Keeping that distinction explicit makes it easier to understand where an answer or recommendation came from.
From a question to a useful next step.
A visitor can start the public chat demo directly. Voice calls begin through protected staff workflows. Chat and voice follow different paths, then converge on persisted transcripts, analysis and a relationship manager handoff.
The handoff includes a summary, objections, a suggested opening line and a next action. It gives the sales team a starting point instead of asking them to reconstruct the entire conversation.
Two conversation paths. One handoff.
The backend joins the experience together.
The public site uses Next.js. The admin and relationship manager portals use React. Supabase provides authentication, Postgres storage, Realtime updates and Edge Functions. Gemini through the AI SDK handles language generation and analysis, Mem0 supplies chat knowledge retrieval, and Vapi runs the voice calls.
An API function handles public and protected requests. A separate dispatcher claims queued calls and starts them with Vapi. A webhook receives call events and stores the final result. Keeping these responsibilities separate makes the conversation lifecycle easier to reason about.
System at a glance
The call ends. The workflow doesn't.
I made transcript persistence happen before analysis. If analysis fails, the transcript remains stored and the error is recorded. Calls that end without a transcript are still marked complete, with analysis skipped rather than inventing an outcome.
Only terminal call events trigger final analysis. Repeated completed events are checked to avoid duplicate scoring, and the dispatcher reconciles stale calls when an event is missed. These are the details that keep a successful conversation from becoming a missing handoff.
Public chat uses anonymous authentication with lead and thread ownership checks. Staff routes enforce role based access, and live calls require a protected workflow. Public visitors can request a voice demo, but cannot trigger outbound calls freely.
A completed call is not the end of the pipeline
- Receive final eventCheck terminal state and repeated completion.
- Save transcript firstKeep the conversation even if analysis fails.
- Analyse or record why notNo transcript means no invented score. Failures retain an error.
- Prepare follow upUpdate classification, summary and next action.
A working MVP, with clear boundaries.
The MVP connects lead capture, AI conversations, classification, admin review and relationship manager follow up. Public chat can be tried directly. Live voice demos remain controlled by the team.
WhatsApp follow up opens a prepared link rather than delivering a message through an API. Voice knowledge uploads are manual, and long term per lead memory is deferred. Conversion improvement has not been measured, so this case study describes the implementation rather than claiming a sales uplift.
Measure the handoff, not just the conversation.
My next priorities would be to evaluate classification and summary quality against reviewed conversations, collect feedback from relationship managers and measure whether the handoff helps them follow up. I would also improve the voice knowledge sync and explore follow up delivery beyond a link.
The lesson from building LeadOS: the AI reply is only one part of the product. Stored context, clear access boundaries and reliable recovery are what make the reply useful after the conversation ends.