DEV Community: Alfaz Mahmud Rizve

Building a Low-Latency Voice AI Sales Agent with ElevenLabs and n8n (End-to-End Blueprint)

Alfaz Mahmud Rizve — Tue, 09 Jun 2026 09:27:38 +0000

In the hyper-competitive landscape of modern B2B outbound sales, speed-to-lead and outreach capacity are the ultimate drivers of pipeline volume. Yet, traditional Sales Development Representative (SDR) teams face a exhausting bottleneck: reaches and qualifications are limited by human bandwidth.

A typical outbound SDR spends up to 80% of their day dialing numbers, navigating IVR phone trees, hitting voicemail, and dealing with incorrect contact records. When an inbound lead submits a form requesting a product demo, the average company takes 42 minutes to respond. By that time, prospect engagement has cooled by over 400%.

To shatter this operational limit, modern revenue operations (RevOps) teams are transitioning from rigid auto-dialers and static voice bots to autonomous voice AI sales agents. By pairing the hyper-realistic conversational engine of ElevenLabs with the visual orchestration power of n8n, you can deploy a scalable, context-aware calling agent that handles inbound qualification and outbound follow-up calls in real-time.

This technical blueprint provides an end-to-end guide to designing, securing, and deploying a production-grade Voice AI Sales Agent using ElevenLabs Conversational AI and n8n. We will cover how to manage conversation state, execute live database tool calls, secure webhook communication, route calls dynamically, and configure infrastructure to achieve sub-second response latency.

The Architecture of an Enterprise Voice Agent

Building a conversational voice agent requires a multi-layered system that operates in near real-time. When a human speaks over a telephony network, their voice must be digitized, transcribed, processed by a large language model (LLM), synthesized back into audio, and sent back down the line—all within a fraction of a second.

To ensure stability, scalability, and absolute separation of concerns, our architecture decouples the telephony and voice generation layer from the logic and database integration layer.

[Prospect] 
   ▲
   │ (PSTN / SIP Voice)
   ▼
[Twilio Phone Number]
   ▲
   │ (Twilio Media Streams / Audio Packets)
   ▼
[ElevenLabs Conversational Engine]
   ▲
   │ (Secure JSON Webhooks over HTTPS)
   ▼
[n8n Automation Runner] <--> [HubSpot CRM & Google Calendar]

The system utilizes four core technical modules:

Telephony Connector (Twilio): Twilio provisions the phone number, handles inbound SIP/PSTN calling routes, and establishes a secure audio connection. It leverages Twilio Media Streams or native SIP trunks to stream raw telephone audio.
Conversational Voice Core (ElevenLabs): ElevenLabs acts as the conversational shell. It ingests the raw telephone audio, performs Speech-to-Text (STT) transcription, executes the LLM agent prompt loop, and synthesizes the final Text-to-Speech (TTS) audio.
Orchestration Layer (n8n): When the ElevenLabs agent decides it needs to retrieve CRM records, check calendar slots, or book an appointment, it fires a webhook payload to n8n. n8n acts as the "brain," querying databases and executing integrations.
CRM and Database Tier (HubSpot & Google Calendar): HubSpot holds prospect histories, lead statuses, and call logs. Google Calendar manages meeting slots and verifies calendar availability.

By utilizing n8n as the middleware API runner, you prevent the voice agent from needing direct database credentials. Instead, ElevenLabs only knows how to trigger specific JSON tool endpoints exposed by n8n.

Step 1: Configuring the ElevenLabs Conversational Agent

To initiate the build, navigate to the ElevenLabs dashboard and create a new Conversational AI Agent. The configuration requires three components: Agent Identity (system prompt), Voice profile, and Client Tools.

1. Agent System Instructions

Define the agent’s personality, conversational boundaries, and objective. Since this is a B2B SDR agent, the primary goal is to qualify lead interest and schedule a call with a human Account Executive (AE).

Copy and adapt this system instruction prompt:

Identity: You are Alex, an autonomous Sales Development Representative (SDR) at RevOpsCorp. Your voice is natural, friendly, and professional.

Objective: Engage in natural conversation to qualify inbound leads who requested a demo of our RevOps Automation Stack. Your goal is to secure a 15-minute consultation slot on our calendar.

Conversational Guardrails:
- Keep responses short and punchy. In speech, long paragraphs feel unnatural. Limit responses to 1-2 sentences.
- Never state that you are an AI unless explicitly asked. If asked, politely confirm you are an AI assistant helping schedule the meeting.
- Do not make up product pricing or features. If asked about custom pricing, explain that you will book them with an AE who can provide a tailored quote.
- Speak dynamically. When you call an external tool (e.g., booking a slot), fill the silence with natural speech fillers like "Let me check that slot for you..." or "One moment while I search our calendar..."

2. Defining client-side JSON Webhook Tools

To allow the ElevenLabs agent to check Google Calendar availability and book meetings, you must define Client Tools inside the ElevenLabs interface. Each tool is defined as a JSON schema specifying the inputs needed.

Below is the JSON tool schema for checking calendar slot availability:

{
  "name": "check_calendar_availability",
  "description": "Checks if a specific date and time slot is available in Google Calendar for a demo call.",
  "parameters": {
    "type": "object",
    "properties": {
      "requested_datetime": {
        "type": "string",
        "description": "The ISO 8601 formatted date-time string requested by the prospect (e.g. 2026-06-12T14:00:00Z)."
      },
      "timezone": {
        "type": "string",
        "description": "The prospect's timezone identifier (e.g. America/New_York)."
      }
    },
    "required": [
      "requested_datetime"
    ]
  }
}

Once defined, set the webhook endpoint URL for this tool to point directly to your secure n8n Webhook Node (configured in Step 2).

Step 2: Building the Secure n8n Webhook Endpoint

When ElevenLabs invokes a tool, it dispatches an HTTP POST request to n8n. If you leave this endpoint open, anyone can trigger your integrations or query your calendar. We must build a secure, validated webhook route.

1. Setting up the Webhook Trigger

In n8n, drag a Webhook Node onto your canvas. Configure the node with the following parameters:

HTTP Method: POST
Path: elevenlabs-sdr-tool-v1
Response Mode: onReceived
Response Body: {{ $json.body }}

2. Validating Secure Custom Headers

ElevenLabs supports sending custom HTTP headers when executing tool webhooks. Use this feature to enforce an authentication secret.

In your ElevenLabs agent tool settings, add a custom header:
X-ElevenLabs-Signature: your-long-cryptographic-token-here

Inside n8n, insert an IF Node immediately after the Webhook node to validate the header:

// Condition in n8n IF node
{{ $headers['x-elevenlabs-signature'] === 'your-long-cryptographic-token-here' }}

If the condition evaluates to false, route the execution to a Respond to Webhook Node returning an HTTP 401 Unauthorized status. This prevents unauthorized web bots from scanning or manipulating your automated pipeline.

Step 3: Designing the Dynamic Logic Nodes in n8n

Once the webhook is validated, the execution branches based on the tool requested by ElevenLabs. The request payload contains the tool name in the body (e.g., body.tool_name).

We insert an n8n Switch Node that reads {{ $json.body.tool_name }} and routes the flow to the appropriate downstream integration sub-path.

Sub-Path A: Checking Calendar Availability

When the agent requests calendar availability, the flow routes to a Google Calendar Node.

Resource: Free/Busy
Time Min: {{ $json.body.parameters.requested_datetime }}
Time Max: Calculate using a JavaScript node or expression to add 15 minutes to requested_datetime.
Calendar ID: primary

If the slot is busy, we return a structured JSON response back to ElevenLabs. The voice agent reads this JSON and tells the prospect that the slot is taken, asking for another time.

Sub-Path B: Logging Leads to HubSpot CRM

When a prospect agrees to a slot or provides their contact details during the call, the n8n flow branches to HubSpot.

Search Contact: Query HubSpot using {{ $json.body.parameters.email }}.
Router Decision:
- If Contact Exists: Update the record, log the call engagement details, and link the upcoming meeting record.
- If Contact Does Not Exist: Create a new contact with the status Lead - Voice Qualified, append their name, email, company, and phone number, and log the call details.

Optimizing for Sub-Second Latency (The Critical Factor)

When a person talks on the phone, they expect instant feedback. A pause longer than 1 second (1,000ms) feels unnatural, leading to conversational collisions where both parties speak at once.

Most n8n setups suffer from latency issues because they run default settings. Below are the three battle-tested infrastructure adjustments to achieve a sub-second response loop.

1. Disable Execution Data Saving (Crucial)

By default, n8n writes the input, output, and execution state of every single node to its database (PostgreSQL/SQLite) so you can review executions later. While useful for debugging, database writes add 150ms - 500ms of overhead per execution.

For production voice webhooks, disable execution logging in n8n by setting the following environment variables in your n8n Docker configuration:

# Disable successful execution logging
N8N_EXECUTIONS_PROCESS=main
N8N_EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
N8N_EXECUTIONS_DATA_SAVE_ON_ERROR=all
N8N_EXECUTIONS_DATA_PRUNE=true
N8N_EXECUTIONS_DATA_MAX_AGE=24

This ensures that n8n runs entirely in memory for successful webhook calls, writing to disk only when an execution fails, which cuts response latency by up to 60%.

2. Geographical Co-Location

If your n8n instance is self-hosted in a Frankfurt data center, but ElevenLabs' conversational AI servers are running in AWS us-east-1 (N. Virginia), every webhook call must traverse the Atlantic Ocean, adding a baseline network latency of 150ms - 250ms.

Always host your n8n instance in the same cloud region as your voice provider's API servers. ElevenLabs primarily uses AWS US-East (N. Virginia), so deploying your n8n Docker cluster on AWS EC2 or DigitalOcean Droplets in New York/Virginia drops cross-server round-trip latency to under 15ms.

3. Asynchronous Execution Pipeline

Instead of letting n8n block the response while it waits for HubSpot API calls to resolve, structure your n8n workflow to return the validation response back to ElevenLabs immediately, and then continue the CRM logging logic in an asynchronous sub-workflow or a detached background branch.

Failsafe & Error Handling: Building a Resilient Pipeline

API requests timeout. Google Calendar limits can be reached. HubSpot can experience server latency. If your n8n workflow returns an unformatted HTTP 500 Server Error or hangs, the ElevenLabs agent will stall, leading to uncomfortable silence on the call.

We must structure n8n to handle errors gracefully by building a Failsafe Router.

Inside n8n, wrap your database calls (HubSpot, Google Calendar) inside a Try/Catch JavaScript Node or configure the node settings:

On Error: Continue Workflow
Write Error Details: True

If an API call fails, the workflow routes to an Error Handler JavaScript Node that outputs a standardized fallback JSON block:

/**
 * Advanced SDR Failsafe Node
 * 
 * Intercepts upstream database failures and formats a polite, conversational
 * response to prevent the voice agent from stalling.
 */

const items = $input.all();
const errorOccurred = items[0].json.error ? true : false;

if (errorOccurred) {
  return [{
    json: {
      status: "fallback",
      message: "I am having a slight technical delay accessing my scheduler, but let's go ahead and secure a time anyway. What is your preferred weekday and time, and I'll make sure our team blocks it out manually?",
      success: false
    }
  }];
}

// Return normal payload if no error
return items;

This guarantees that the AI voice agent maintains control of the call. Instead of stuttering, the voice assistant politely switches to a manual slot request, logging the error in the background for your operations team to resolve.

Outbound Calling Integration & The Compliance Shield

While inbound qualification is passive, outbound calling requires proactive orchestration. Triggering outbound sales calls via n8n is straightforward using the ElevenLabs API Node or HTTP Request Node.

To trigger a call to a newly submitted lead:

curl -X POST "https://api.elevenlabs.io/v1/convai/agents/your-agent-id/initiate-call" \
  -H "xi-api-key: your-elevenlabs-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+1234567890",
    "dynamic_variables": {
      "prospect_name": "Alfaz",
      "company_name": "Urban Cafe",
      "pain_point": "Lead conversion speed"
    }
  }'

Outbound Calling Regulations (TCPA Compliance)

Outbound calling using automated voice agents is highly regulated under the TCPA (Telephone Consumer Protection Act) in the United States.

To run compliant outbound calling campaigns:

Prior Express Written Consent: Never auto-dial a consumer's mobile number unless they explicitly opted-in (e.g. checked a box on your web form requesting a phone call consultation).
Clear Disclosure: The agent must declare its automated nature within the first 30 seconds if asked.
Automated Call Suppression Registry: Integrate n8n with an opt-out registry database to check that a prospect's number hasn't opted-out of phone communication before triggering the API call.

Deploying the Telephony Redirection (Human Agent Handoff)

AI voice agents are incredible at qualifying prospects, but they cannot close complex Enterprise contracts. A complete sales calling system must support a Live Human Handoff.

When the prospect expresses high buying intent (e.g. "I want to buy right now, put me through to a representative"), ElevenLabs triggers the transfer_call tool. n8n catches this webhook, looks up the caller ID, and dispatches a redirect command to Twilio.

Using Twilio TwiML, n8n replies to the webhook with instructions to route the call audio away from the ElevenLabs SIP stream to your sales team's phone queue:

<Response>
  <Say>Connecting you to our sales desk. Please hold.</Say>
  <Dial>+18005550199</Dial>
</Response>

This ensures a seamless transition. The prospect is bridged immediately to a live representative, maintaining the momentum of the call.

System Verification & Production Metrics

To confirm that your newly deployed voice agent is running at peak efficiency, monitor your pipeline against these core RevOps metrics:

Conversational Latency: Track the time delta between the end of user speech and the start of agent audio. Target: < 900ms (highly human).
Tool Execution Speed: Time taken for n8n to respond to ElevenLabs tool webhook triggers. Target: < 500ms.
Meeting Containment Rate: The percentage of calls that result in a booked calendar meeting or qualification tag without dropping. Target: > 35%.
Failsafe Triggers: How often n8n encounters API errors and falls back to manual mode. Target: < 1% of total calls.

By deploying this secure, low-latency conversational voice architecture, you eliminate lead leakage, scale your SDR outreach, and create an automated revenue generator.

For the complete step-by-step instructions, including the full HubSpot lead logging schemas and n8n Switch Node routing configs, read the full guide here: Building a Voice AI Sales Agent with ElevenLabs and n8n: End-to-End Architecture.

Zero-Hardware Kitchen OS: How I Replaced a $2,000 POS System With a Next.js PWA

Alfaz Mahmud Rizve — Sun, 07 Jun 2026 07:06:34 +0000

Marcus stands behind the counter of Urban Harvest Cafe, the steam wand of his espresso machine hissing as a line of morning commuters begins to form. His hands are covered in sourdough flour. In a traditional cafe setup, Marcus would have to constantly wash his hands, wipe them dry, and tap on a grease-smeared, slow, commercial POS tablet to read incoming digital orders. If he missed a ticket, a customer walked out.

Looking for a solution, Marcus investigated off-the-shelf restaurant POS systems. The quotes were staggering: $2,000 upfront for proprietary hardware, plus a mandatory 3% commission cut on every single digital transaction. For a solo operator, this was an operational and financial wall.

As a RevOps and automation engineer, I sat at a corner table with a flat white, watching this friction. The solution became obvious: Marcus's hands were busy, but his ears were free.

I set out to engineer a custom, lightweight, autonomous kitchen ordering system that spoke to him, synchronized in real-time, ran on a zero-hardware budget, and let a single chef run a high-volume cafe alone.

The Vision: Solo Cafe Operations Running on Autopilot

To bypass the need for a 5-person front-of-house crew, we re-engineered the entire customer-to-kitchen lifecycle:

QR Table Scanning: Customers sit down, scan a table-specific QR code, browse a fast mobile-first menu, and checkout without installing an app or registering.
Eyes-Free Kitchen: The kitchen runs completely hands-free. A browser-native Text-to-Speech (TTS) engine reads out incoming orders to the chef (e.g., "New order for Rizve, Table 4. 1x Avocado Sourdough Toast").
Simple Completion Shouting: When the food is hot, Marcus taps "Completed" on a wall-mounted tablet and calls out the name. The system handles the digital receipt and alerts the customer in real-time.

To automate the indexing of these dynamic product and success pages instantly on every deployment, I integrated the same zero-touch SEO Indexing Pipeline used on this portfolio to ping search engine APIs in under 12 seconds.

Author Profile: Who is Alfaz?

Before jumping into the code, you might ask: who is alfaz?

I am Alfaz Mahmud Rizve (online known as whoisalfaz), a RevOps Engineer and Full-Stack Automation Architect. I specialize in designing autonomous revenue strategies and engineering the underlying software infrastructure to run them. Rather than building simple minimum viable products, I build high-performance web systems and automation pipelines that drive business efficiency and maximize revenue throughput. Learn more about my architecture philosophy on my About Page.

GitHub: AlfazMahmudRizve/Urban-Harvest-Cafe
Live Storefront Demo: https://urbancafe.whoisalfaz.me
Need an automated system? Let's connect on my Contact Page.

Project Specifications

Attribute	Specification
Framework	Next.js 14 (App Router) + TypeScript
Database & Realtime	Supabase (PostgreSQL)
State Management	Zustand (with local persistence)
Styling & Motion	Tailwind CSS + Framer Motion
Client Notifications	Browser-native Web Speech API (Text-to-Speech)
Push Notifications	Telegram Bot API integration
Deployment	Vercel (Edge network deployment)

1. The Core Architectural Challenge

Building a web app for a chaotic kitchen environment requires solving physical and digital constraints that traditional SaaS apps never face:

Autoplay Restrictions: Web browsers strictly block programmatic audio until a user clicks on the screen.
Network Drops: Unstable cafe WiFi causes silent WebSocket dropouts, leading to missed tickets.
Kitchen Flooding: A sudden spike in digital orders can easily overwhelm a solo operator, leading to long wait times and poor customer service.

This architecture builds on the robust full-stack capabilities I designed for the Veloryc E-Commerce Case Study to handle high-performance state sync under heavy user loads.

2. Key Engineering Breakthroughs & Logical Implementation

A. Autoplay Bypass & Failsafe Audio Queue (Web Speech API)

To prevent Marcus from having to touch a screen with flour-covered hands, the app needed to speak immediately upon order arrival. However, modern browsers block the Web Speech API until a physical interaction primes the audio context.

We solved this by implementing an Interstitial State Lock:

When Marcus logs into the dashboard at the start of a shift, they are presented with a high-contrast modal: "Start Shift & Enable Audio Feedback".
Clicking this button primes the browser's audio context and registers a persistent queue runner.
If the OS backgrounds the browser tab or suspends the audio engine, incoming order payloads are routed to a prioritized memory queue. When the tab re-enters the focus state or the engine recovers, the queue processes the stored items sequentially.

Here is the TypeScript implementation of the audio queue and bypass handler:

// Location: hooks/useDashboardData.ts / component context
interface OrderQueueItem {
  id: string;
  speechText: string;
}

const queue: OrderQueueItem[] = [];
let isSpeaking = false;

export function speakOrder(text: string, orderId: string) {
  if (typeof window === 'undefined' || !('speechSynthesis' in window)) return;

  // Enqueue new order
  queue.push({ id: orderId, speechText: text });
  processQueue();
}

function processQueue() {
  if (isSpeaking || queue.length === 0) return;

  const current = queue[0];
  isSpeaking = true;

  const utterance = new SpeechSynthesisUtterance(current.speechText);
  utterance.rate = 0.95; // Slightly slower for kitchen acoustics
  utterance.pitch = 1.0;

  utterance.onend = () => {
    queue.shift();
    isSpeaking = false;
    processQueue(); // Process next in line
  };

  utterance.onerror = (e) => {
    console.error("Speech Synthesis Error:", e);
    // Display high-contrast failsafe fallback alert in dashboard UI
    triggerVisualAlert(current.id, "Audio Blocked by OS. Please click dashboard to resume.");
    isSpeaking = false;
    // Don't shift yet; retry on user interaction
  };

  window.speechSynthesis.speak(utterance);
}

B. Resilient Hybrid Realtime Sync (WebSockets + Polling)

A missed order in a restaurant is a lost customer. To keep the kitchen dashboard in sync without manual page refreshes, we established a websocket connection using Supabase Realtime subscriptions pointing to the PostgreSQL orders table.

But because microwave ovens and kitchen equipment can disrupt local WiFi networks, we engineered a resilient hybrid synchronization layer:

Primary Layer (WebSocket): Listens to PostgreSQL INSERT events, instantly pushing new orders to the Zustand state.
Fallback Layer (Polling): A background interval runs a silent 5-second check (comparing the local order count with remote DB record metadata). If a websocket dropout is detected, the system executes a delta-fetch and triggers the audio engine for any missed orders.

For cases where custom catering requests or high-volume reservations require complex multi-source validation, the data is pushed to our AI Lead Enrichment Pipeline Guide to auto-qualify before reaching the kitchen.

This ensures zero lost tickets, even during network degradation.

C. Dynamic Overload Protection & Capacity Control

To protect a solo operator from being swamped with orders during a rush, the chef can define a maximum ticket capacity (e.g., 8 active cooking orders) in their dashboard settings.

When a customer lands on the storefront, the client checks the active ticket count in Supabase.
If active_orders >= max_capacity, the checkout button is disabled, and the storefront layout swaps to an elegant, animated "Overwhelmed" pause screen apologizing for the delay.
Additionally, a global Store Status Toggle allows the chef to manually pause orders at any time. This toggle updates a record in a settings table, which real-time clients instantly react to.

D. Frictionless Auto-Login Guest Session Flow

To make checkout frictionless, customers do not need to register an account before ordering. However, they must be able to track their order status afterwards. I solved this by implementing an Auto-Login Guest Flow:

When a user submits an order, the Next.js Server Action (app/actions/placeOrder.ts) inserts the order and automatically generates a guest account behind the scenes using a standard, secure JWT payload containing their order details.
The server sets a secure, HTTP-only cookie containing the JWT session token with a 30-day expiration.
Upon redirection to /success, the client-side middleware parses the cookie, authenticates the session, and automatically logs the user into their customer dashboard.
For security, guest checkouts are assigned a default credentials flow (password: 1234) but are marked with a database flag requiresPasswordChange = true. If the user wishes to save their loyalty details, they are prompted to update their credentials when they visit the /profile page.

3. The Harvest OS Dashboard Interface

To maximize operator efficiency, I designed a segmented dashboard split into three focused views rather than placing all data on a single cluttered page:

I. The Kitchen Command Center

Kanban Workflow: Drag-and-drop or click-action orders through three stages: Pending (Needs review) $\rightarrow$ Cooking (In preparation) $\rightarrow$ Ready (Ready for pickup).
Order Channels: Categorized lists showing order distribution: Dine-In (including Table Number), Takeout, and Home Delivery.

II. Restaurant Analytics

Revenue Charts: Daily and weekly revenue visuals showing shop performance in Taka (৳). Mizan’s analytics panel uses direct PostgreSQL aggregates, a reporting pattern I similarly optimized for the CashOps Financial Dashboard to show real-time profit and loss metrics.
Item Popularity Index: Tracks item velocity (e.g., comparing Espresso vs Sourdough Toast sales) to aid inventory decisions.

III. Customer Management & VIP Leaderboard

Loyalty Tracker: Displays customer order counts, total spend, and contact numbers.
VIP Leaderboard: Features top-spending customers, helping the owner identify and reward regular patrons.

4. Technical FAQs

How does the system handle real-time synchronization if the restaurant's internet fails?

The application employs a hybrid websocket-and-polling model. If the websocket client disconnects, the system switches to an automated 5-second HTTP polling loop. When connection is restored, the websocket automatically reconnects and synchronizes missing states.

What database security measures are implemented?

The database is built on Supabase (PostgreSQL) and utilizes Row Level Security (RLS) policies. Unauthenticated users are only granted permission to write to the orders table via anon keys. Admin dashboard reads/writes require a cryptographic session token verified at the API level.

Why was Zustand selected over Redux or React Context?

Zustand provides a lightweight, boiler-free state store that integrates easily with browser storage. It ensures cart data and local sessions persist across refreshes without introducing the performance bottlenecks of React Context or the overhead of Redux.