Loading
LeadPulz is a FlowFoundry product rather than a client engagement. It exists because the same requirement kept appearing in client conversations: answer the calls nobody is free to take, qualify the caller properly, and make sure the outcome reaches the CRM. Assembling that from disconnected tools each time was slower and more fragile than building the platform once. LeadPulz is currently in active development and is not generally available.
A phone enquiry signals more intent than almost any web form, and yet it is the channel with the least data attached. Calls go unanswered outside business hours, qualification questions are asked inconsistently, and what the caller actually wanted survives only in someone's memory. Existing voice tools tended to solve the conversation and stop there - leaving the part that matters commercially, the write-back into calendars and CRM systems, as an exercise for the buyer.
The brief, before any technology was chosen.
Described in layers, because that is how the design decisions actually separate.
Telephony via Twilio handles call setup and media. Speech-to-text, the language model and text-to-speech run as a streaming pipeline, because perceived latency is what determines whether a caller stays on the line.
A configurable flow engine holds the qualification script, branching rules, escalation conditions and the boundaries of what the agent may assert. Business rules live here rather than inside prompts, so they are testable.
A per-tenant knowledge base supplies retrieval context for answering questions, scoped so an agent can only read its own tenant's data.
Postgres via Supabase stores tenants, agents, flows, call records, captured fields and transcripts, with row-level security enforcing tenant isolation at the database rather than in application code.
An integration layer performs the outward writes - calendar events, CRM records, follow-up triggers, notifications - behind a retry and idempotency wrapper so a network failure cannot double-book a slot.
A Next.js dashboard for configuring agents, reviewing conversations and inspecting captured data and outcomes.
Answers on configurable rules - after hours, ring count, or overflow when the team is engaged.
Works a lead list with configurable pacing, retry rules and outcome recording.
Captures named, typed fields the CRM can filter and report on.
Offers only genuinely free slots and writes the confirmed event back.
Creates or updates the contact and attaches the call summary and captured fields.
Triggers sequences on call outcome and qualification status.
Answers questions from a tenant-scoped knowledge base.
Transcript, recording, captured fields and outcome in one view.
The problems worth writing down, and how each one was handled.
A caller notices a pause long before they notice a wrong word. We stream every stage rather than waiting for complete results, and start speech synthesis on the first usable clause instead of the full response.
Real callers talk over the agent. Barge-in detection stops playback and re-listens, which matters more to how natural a call feels than response quality does.
Allowed actions are a whitelist in the flow engine, not an instruction in a prompt. The agent cannot quote a price or make a commitment that is not in its configuration, because the capability is absent rather than discouraged.
Booking is idempotent and keyed per conversation. A retry after a timeout resolves to the same event rather than creating a second one.
Row-level security in Postgres rather than filtering in application queries, so a missed WHERE clause cannot leak another tenant's calls.
Sequence matters. Each step was chosen because it de-risked the next one.
Median agent response latency
Pending measurement
Measured end to end from caller speech-end to agent speech-start
Calls handled without escalation
Pending measurement
Share of calls reaching an outcome with no human transfer
Booking accuracy
Pending measurement
Confirmed bookings that match a genuinely free calendar slot
Qualification completeness
Pending measurement
Share of calls with all required fields captured
Not as a self-serve product - it is in active development. We do deploy the underlying capability as part of client engagements, which is how it gets tested against real call volume. If voice automation is what you need, that is the route to start on.
The pipeline is language-configurable and we are testing Indian-language handling, including mid-conversation switching, which is normal on real calls. Quality varies by language and we would rather show you a live test on yours than quote a claim.
An IVR routes against a fixed menu. This holds a conversation, answers from your knowledge base, captures structured data, and completes an action like a booking. The practical difference is that the caller does not have to know which option they need before they call.
Describe the system you have in mind. We will tell you what it takes, what we would do differently, and whether we are the right team for it.
