DEV Community: VoiceFleet

AI phone answering for restaurants — handling noise, accents, and chaos

VoiceFleet — Fri, 24 Apr 2026 09:04:09 +0000

Building AI phone answering for restaurants taught us things dental/office use cases didn't:

Background noise is extreme — kitchen during Friday service vs quiet dental reception
Menu knowledge — the AI needs to know your specials, allergens, and what's 86'd tonight
Reservation logic — table sizes, seatings, private rooms, group minimums
Accent diversity — Dublin restaurants get calls in many accents + languages

The speech recognition challenge alone was interesting. We had to fine-tune noise cancellation for restaurant-specific frequencies (clanging, sizzling, music).

Full article

Virtual Receptionist vs AI Receptionist: What's the Actual Difference?

VoiceFleet — Thu, 23 Apr 2026 09:26:18 +0000

Originally published on VoiceFleet.

If you're building customer-facing AI systems, this is the practical version.

The terms get used interchangeably, but they're fundamentally different products solving the same problem in very different ways.

Virtual Receptionist = Human, Remote

A virtual receptionist is a real person working from a call centre. They answer your phone using a script you provide. Companies like Moneypenny, Ruby, and Smith.ai offer this.

Pros: Natural conversation, handles edge cases well
Cons: £200–£500+/month, limited hours, can't scale instantly, staff turnover means retraining

AI Receptionist = Software, Always On

An AI receptionist uses speech recognition + LLMs to handle calls autonomously. It books appointments, answers FAQs, routes emergencies, takes messages.

Pros: 24/7, scales to infinite concurrent calls, learns your business, €50–€150/month
Cons: Complex edge cases may need fallback to human, accents/noise can trip up speech recognition

The Hybrid Future

The best setup in 2026 is probably AI-first with human fallback. Let the AI handle 80% of calls (booking, FAQs, hours, directions) and route the 20% that need human judgment.

VoiceFleet takes this approach — AI handles the routine, escalates the complex. Works for dental practices, restaurants, trades, legal.

The "virtual vs AI" debate is already resolving itself. AI handles volume; humans handle nuance.

Deep dive: voicefleet.ai/blog/virtual-receptionist-vs-ai-receptionist-difference

Why this matters for builders

The implementation details matter more than the headline. The useful question is how to turn the idea into a reliable workflow, measurable outcome, and better operator experience.

How AI Receptionists Work: A Technical Deep Dive into Dental Practice Phone Automation

VoiceFleet — Wed, 22 Apr 2026 09:09:07 +0000

I keep seeing "AI receptionist" thrown around without anyone explaining what's actually happening under the hood. Here's a technical breakdown of how the call flow works for dental practices.

The 6-Step Pipeline

1. Call Routing (0-2s)

Standard SIP forwarding. Three modes: primary (AI first), overflow (human first, AI fallback after 3-4 rings), after-hours only. No hardware needed at the practice.

2. ASR — Speech Recognition (Real-Time)

Converting speech to text at 95-97% accuracy. The tricky parts:

Regional accents (Irish English has significant variation between Dublin, Cork, rural)
Domain-specific vocabulary ("periapical abscess", "composite veneer", "occlusal splint")
Noisy environments (caller in car, on street)
Interruptions and corrections

3. Intent + Entity Extraction (50-200ms)

LLM processes the transcript and determines:

Intent: book, cancel, reschedule, ask question, report emergency
Entities: dates, dentist preferences, treatment type, patient name
Sentiment: calm, anxious, in pain

Example input: "I was in last week for a filling and it's still quite sore"
→ Intent: post-treatment concern (triage trigger)
→ Entities: patient context (recent filling), symptom (pain)
→ Action: run emergency triage protocol

4. PMS Query (200-500ms)

This is where it gets interesting. The AI connects to practice management systems (Dentally, SOE, Exact, Carestream) via API and:

Queries real-time appointment availability
Respects booking rules (appointment types, durations, provider assignments)
Checks patient records (returning patient? usual provider?)
Applies business logic (new patients get 45-min slots, emergencies get same-day)

The appointment is booked and in the diary before the call ends. No "someone will call you back."

5. Response Generation (100-300ms)

LLM generates contextual response → TTS with natural prosody. Modern TTS includes pauses, intonation, even filler words ("let me check that for you").

6. Conversational Loop

Steps 2-5 repeat. Full context maintained throughout. Handles topic switches, corrections, multi-part requests.

Total per-exchange latency: 400ms-1s.

What's Automatable vs. What Needs Humans

~75% of dental practice calls follow predictable patterns: booking, confirming, rescheduling, directions, insurance queries, treatment FAQs. All automatable.

The remaining 25% (emergencies, complex treatment discussions, complaints, billing disputes) get warm-transferred with a conversation summary. Patient never repeats themselves.

The Security Stack

For health data:

AES-256 at rest, TLS 1.3 in transit
EU data centres only (GDPR)
Configurable retention (default 90 days, auto-delete)
No model training on patient data
DPA and DPIA support

Interesting Stat

92% of callers don't realise they're talking to AI. Average AI call: 2:15 vs human: 3:40 — AI is faster because it has instant PMS access.

Full guide with setup details →

Handling after-hours calls with AI: architecture lessons

VoiceFleet — Tue, 21 Apr 2026 09:02:54 +0000

30–40% of business calls arrive after hours. We built an AI system to handle them and learned some things:

Latency matters more at night — callers are often stressed/urgent
Context switching — the AI needs to know it's after-hours and adjust (no "let me transfer you")
Emergency routing — some calls genuinely need a human at 3AM
Timezone handling — harder than it sounds when serving Ireland + Argentina

The voicemail-to-AI upgrade was the biggest win. 80% voicemail abandonment → 90%+ AI completion rate.

Full writeup

What Actually Matters When Choosing an AI Receptionist (From a Dev Who Integrated 5 of Them)

VoiceFleet — Mon, 20 Apr 2026 09:12:52 +0000

What Actually Matters When Choosing an AI Receptionist

I've integrated five different AI receptionist services into client projects over the past year. Here's what I wish someone had told me before I started.

1. Latency Is Your UX

In web development, we obsess over time-to-first-byte. In voice AI, the equivalent is time-to-first-word — how long after the caller says something does the AI start responding?

Most services quote pickup speed (how fast it answers the phone). But the more important metric is conversational latency — the gap between the caller finishing a sentence and the AI responding.

In my testing:

VoiceFleet: ~400ms conversational latency, <1s pickup
Bland AI: ~500ms, ~1s pickup
Synthflow: ~700ms, ~2s pickup
Goodcall: ~900ms, ~2s pickup
Rosie: ~1.2s, ~3s pickup

Anything over 1 second feels unnatural. Under 500ms feels like talking to a person.

2. Webhook Reliability Matters More Than Features

I don't care how many features a service advertises if their webhooks are flaky. When a call ends and your CRM doesn't get the payload, your client's workflow breaks silently.

In 6 months of production use:

VoiceFleet: 99.9% webhook delivery (retry logic built in)
Bland AI: 99.5% (occasional delays under high load)
Goodcall: ~98% (no retry mechanism, had to build our own)

Always implement idempotent webhook handlers and a dead-letter queue regardless of the service.

3. The Knowledge Base Architecture

How does the AI know what to say? This varies significantly:

Document-based (VoiceFleet, Synthflow): You upload documents, FAQs, policies. The system uses RAG (Retrieval-Augmented Generation) to find relevant context per query. Works well for businesses with lots of specific information.

Script-based (Goodcall, Rosie): You define conversation flows like a decision tree. Simpler but brittle — any off-script question gets a generic fallback.

Hybrid (Bland AI): You define tools and prompts; the LLM decides when to use them. Most flexible but requires prompt engineering expertise.

For most client projects, document-based RAG is the sweet spot. Upload the client's FAQ page and pricing, and it handles 90% of calls correctly out of the box.

4. Flat Rate vs Per-Minute: The Infrastructure Analogy

Think of it like servers:

Per-minute (Ruby, Bland AI) = EC2 on-demand pricing. Fine for dev/test, expensive in production.
Flat rate (VoiceFleet at €99/mo unlimited) = Reserved instances. Predictable, cheaper at any real volume.

If your client gets more than ~20 calls/day, flat rate wins every time.

5. Multi-Language Isn't Just Translation

Some services claim multi-language support but really just translate their English prompts. Real multilingual support means:

Language detection from caller speech (not menu selection)
Culturally appropriate responses (formal vs informal)
Accent handling in STT
Native-sounding TTS voices per language

VoiceFleet handles 30+ languages with dedicated voice models per language. Most US services offer English + maybe Spanish.

6. GDPR: Not Just a Checkbox

If your client is in the EU, you need:

Data Processing Agreement (DPA) from the service
Confirmation of EU data residency
Clear data retention policies
Right-to-deletion implementation

VoiceFleet is EU-native so this is built in. For US services, you'll need to negotiate custom DPAs and potentially accept data transfer risks.

My Stack Recommendation

For most projects: VoiceFleet for the AI phone agent + your existing CRM/calendar + custom webhooks for business logic. Total setup time: 2-3 hours including testing.

For complex custom builds: Bland AI for the telephony layer + your own LLM orchestration.

Stop evaluating feature lists. Deploy a pilot, measure latency, test webhooks, and check the bill after 30 days. That tells you everything.

Designing an AI answering workflow for Australian SMBs

VoiceFleet — Sun, 19 Apr 2026 09:03:33 +0000

When people hear "AI answering service", they often picture the model first. In practice, the hard part is workflow design.

If the use case is AI Answering Service Australia in 2026: How Australian Businesses Capture More Calls, Bookings and After-Hours Leads, the stack has to solve an unglamorous but important set of problems:

business-hours detection
lead capture into CRM or inbox
urgent-call escalation rules
clean morning summary for staff

Minimal flow that actually works

Detect whether the call arrives in-hours or after-hours.
Identify caller intent in plain language.
Capture the minimum viable details for the team to act.
Trigger the right handoff, escalation, or callback path.
Produce a summary that operations staff can trust.

Why this matters more than a clever voice demo

Most revenue is lost in the gaps between answering, qualifying, and following up. If the workflow is weak, the model quality barely matters. If the workflow is strong, even a simple conversational layer can outperform voicemail and patchy manual follow-up.

A useful evaluation checklist

Does the system respect location-specific business hours and service areas?
Can it separate leads from support, emergencies, and low-intent calls?
Can the team see what happened without reading a full transcript?
Does the fallback path make sense when confidence is low?

That is the real engineering challenge here. The article version for business buyers is here if you want the commercial framing: https://voicefleet.ai/blog/ai-answering-service-australia-2026/

Integrating AI Voice Agents with Restaurant Booking Systems (ResDiary, OpenTable)

VoiceFleet — Sat, 18 Apr 2026 09:03:53 +0000

Integrating AI Voice Agents with Restaurant Booking Systems

We built AI phone answering for restaurants that integrates with ResDiary, OpenTable, and POS systems. Here's a technical deep-dive on the integration challenges and how we solved them.

Why Restaurants?

Restaurants miss 20–30% of calls during peak hours. The phone rings hardest during service — exactly when nobody can answer. Classic scheduling conflict with a clear technical solution.

System Architecture

Caller → Telephony → ASR → NLU → Dialog Manager → TTS → Caller
                                        ↕
                              Booking System Adapter
                              ├── ResDiary API
                              ├── OpenTable API
                              ├── Custom POS
                              └── Calendar fallback

The Adapter Pattern

Every restaurant uses different tech. We abstracted booking operations behind a unified interface:

interface BookingProvider {
  checkAvailability(date: Date, partySize: number): Promise<Slot[]>;
  createReservation(slot: Slot, guest: GuestInfo): Promise<Reservation>;
  cancelReservation(id: string): Promise<void>;
  getMenuInfo(): Promise<MenuItem[]>;
  getAllergenInfo(itemId: string): Promise<Allergen[]>;
}

ResDiary has a solid REST API — straightforward integration. Real-time availability checks, reservation creation, and confirmation in one flow.

OpenTable requires OAuth and has rate limits that matter during peak hours (Friday 6-8pm = lots of simultaneous calls = lots of availability checks).

Custom/legacy systems — many restaurants use paper diaries or spreadsheets. For these we fall back to Google Calendar integration with a shared calendar.

Handling Concurrent Reservations

Peak hours mean multiple callers requesting the same time slots simultaneously. We use optimistic locking with the booking provider:

Check availability → show caller available slots
Caller picks a slot → attempt reservation
If slot taken between check and book → offer next best alternative
Retry up to 2 alternatives before escalating

For ResDiary, their API handles this natively. For calendar-based fallbacks, we maintain a short-lived lock (90s TTL in Redis).

Takeaway Order Flow

Takeaway is more complex than reservations — it's essentially building an order through voice:

Intent: order_takeaway
→ Menu navigation (categories → items → modifiers)
→ Cart management (add, remove, modify)
→ Order confirmation + total
→ Collection time estimation
→ Payment (redirect to payment link via SMS)

The upsell logic ("Would you like to add a dessert?") uses simple rules based on order composition and restaurant-configured suggestions. Not ML — just business rules that work.

Allergen Handling

Irish food allergen regulations require accurate information. We store allergen data per menu item and cross-reference during the conversation:

Caller: "Do you have anything gluten-free?"
→ Query: menu items WHERE allergens NOT CONTAINS 'gluten'
→ Response: "Yes, we have [items]. Would you like to order one of these?"

Zero tolerance for guessing. If allergen data is missing for an item, the AI says so and offers to connect to staff.

Multilingual Support

Tourist areas (Dublin, Galway, Cork) need multilingual handling. We detect language from the caller's first utterance and switch the entire dialog flow:

ASR model selection based on detected language
Dialog templates in target language
TTS voice selection matching language/accent

Currently supporting: English, Irish, French, German, Spanish, Italian, Mandarin.

Performance Under Load

Friday 7-8pm stress test results:

12 simultaneous calls handled
Average response latency: 380ms
Booking confirmation rate: 94%
Escalation to human: 6% (complex dietary requests, large group negotiations)

Key Learnings

Adapter pattern is essential — restaurant tech is fragmented
Optimistic locking > pessimistic for booking — better UX, rare conflicts
Allergen accuracy is non-negotiable — liability issue
Upselling works surprisingly well via voice — 15% add-on rate

Built by VoiceFleet. Questions about the integration architecture? Drop a comment.

Building AI Receptionist Integrations with Dentally and Flipdish APIs

VoiceFleet — Thu, 16 Apr 2026 14:06:54 +0000

Most AI receptionist products stop at "answer the call and email you a transcript." That's not automation — that's delegation to a slower process.

We've been building integrations between our voice AI and the actual business tools Irish companies use daily: Dentally (dental practice management) and Flipdish (restaurant ordering platform).

The Technical Challenge

The interesting engineering problem isn't the voice AI itself — it's the real-time decision loop during a live call:

Caller says "I need to book an appointment for Thursday"
AI queries Dentally API for Thursday availability (< 500ms budget)
AI presents options conversationally
Caller confirms
AI creates booking via API + sends SMS confirmation

All of this needs to happen within natural conversation flow. You can't have a 3-second pause while your API call resolves.

Flipdish Integration Pattern

Restaurant ordering has a different challenge: menu complexity. A restaurant might have 200+ items with modifiers, sizes, and combos. The AI needs to:

Map spoken items to exact menu entries ("large pepperoni with extra cheese")
Handle modifications ("no onions, add mushrooms")
Calculate pricing in real-time
Push the complete order to the kitchen display

We sync the full Flipdish menu on a schedule and keep a local cache for sub-100ms lookups during calls.

Key Takeaway

If you're building voice AI for business use cases, the voice model is maybe 30% of the work. The other 70% is integrations, edge cases, and making API calls fast enough that the conversation feels natural.

Would love to hear from others building real-time API integrations into conversational AI — what latency budgets are you working with?

I Set Up an AI Phone Agent for My Business in 5 Minutes — Here's How

VoiceFleet — Mon, 13 Apr 2026 09:24:53 +0000

As developers, we love automation. But when it comes to our own businesses (or our clients'), phone calls remain stubbornly manual.

I recently tested VoiceFleet, an AI receptionist that handles inbound calls — booking appointments, answering FAQs, taking messages — without any code.

The Setup (Actually 5 Minutes)

Create account → get a local phone number
Configure your business context (natural language, not config files)
Set call routing rules
Forward your overflow calls
Done

No webhooks to configure. No Twilio spaghetti. No prompt engineering.

Under the Hood

The interesting bit for devs: it uses real-time voice AI with conversation state management. It handles interruptions, multi-turn dialogues, and context switching (e.g., patient asks about hours mid-booking).

Why This Matters

Small businesses miss 30-40% of calls. Each missed call = lost revenue. The AI answers in <1 second, 24/7, starting at €9/month.

If you're building for SMBs, this is the kind of infrastructure your clients need.

Originally published at voicefleet.ai

AI Receptionist Pricing Breakdown: Smith.ai vs Ruby vs Goodcall vs VoiceFleet (2026)

VoiceFleet — Sun, 12 Apr 2026 09:42:32 +0000

AI Receptionist Pricing Breakdown: Smith.ai vs Ruby vs Goodcall vs VoiceFleet (2026)

If you're evaluating AI receptionist APIs or services for a project, here's a no-BS pricing comparison.

Quick Matrix

Service	Base Price	Model	API Available	Local Numbers (EU)
VoiceFleet	€9/mo	Flat	Coming soon	✅
Smith.ai	$240/mo	Per-call	✅	❌
Ruby	$235/mo	Per-minute	❌	❌
Goodcall	$59/mo	Tiered	Limited	❌
Rosie	$49/mo	Per-minute	❌	❌

Key Takeaway

US-centric services dominate but lack EU phone number support and GDPR compliance. VoiceFleet is the only option I found with native Irish/EU numbers and flat-rate pricing.

For builders: if you're integrating phone AI into a product, watch this space — the API landscape is about to get competitive.

Originally published at voicefleet.ai

How AI Phone Answering Actually Works Under the Hood

VoiceFleet — Sat, 11 Apr 2026 09:24:06 +0000

How AI Phone Answering Actually Works Under the Hood

I've been deep in the AI voice space for a while now, and the amount of misconception about what "AI phone answering" actually means is wild. Let me break down the tech stack.

The Architecture

A modern AI phone answering system has roughly 4 layers:

Caller → Telephony (SIP/PSTN) → STT Engine → LLM → TTS Engine → Caller

Layer 1: Telephony
You need a phone number that routes to your system. Most use SIP trunking providers (Twilio, Telnyx, Vonage). The audio comes in as RTP streams.

Layer 2: Speech-to-Text (STT)
Real-time transcription. Deepgram and AssemblyAI dominate here. Latency is critical — you need sub-300ms or the conversation feels laggy. Whisper is great for batch but too slow for real-time without heavy optimization.

Layer 3: The Brain (LLM)
This is where the magic happens. The LLM gets:

The transcribed speech
Business context (hours, services, pricing, FAQs)
Conversation history
Available actions (book appointment, transfer call, take message)

The trick is keeping responses concise. Nobody wants an AI that rambles for 30 seconds. You need to tune for conversational brevity.

Layer 4: Text-to-Speech (TTS)
ElevenLabs, PlayHT, or Azure Neural TTS. Voice cloning has gotten scary good — you can match the "vibe" of a business pretty well. The uncanny valley has basically closed for phone-quality audio.

The Hard Problems

Latency budget: You have ~800ms total round-trip before it feels unnatural. That's STT + LLM inference + TTS combined. This is why you can't just throw GPT-4 at it — you need faster models or streaming inference.

Interruption handling: People interrupt. A lot. Your system needs to detect when someone starts talking over the AI and gracefully stop, listen, and respond. This is way harder than it sounds.

Edge cases: Background noise, accents, multiple speakers, children screaming, bad cell connections. Production voice AI has to handle all of this.

Integration: Booking an appointment isn't just "call an API." You need to handle availability checking, conflict resolution, timezone conversion, and confirmation — all in real-time during a phone call.

What the Market Looks Like in 2026

Broadly three tiers:

Tier	Price	What You Get
DIY (Vapi, Bland)	$0.10-0.15/min	Build it yourself, bring your own LLM
Vertical SaaS	$99-300/mo	Pre-built for dental/restaurant/etc, flat pricing
Enterprise	$500+/mo	White-glove, custom voices, deep integrations

The DIY route is tempting for devs but the operational overhead is real. Per-minute pricing also gets expensive fast — a busy dental practice doing 200 calls/day at 2 min average = $40-60/day = $1,200/month.

Flat-pricing vertical solutions (like VoiceFleet for dental/restaurant, or competitors like Smith.ai for legal) tend to be better economics for businesses.

If You're Building in This Space

A few things I've learned:

Start with ONE vertical. Dental and restaurants are hot because they have high call volume + high missed-call cost
Latency is your #1 metric. Not accuracy. A fast, decent response beats a slow, perfect one
Record everything (with consent). Your training data IS your moat
Don't try to handle 100% of calls. Handle 80% perfectly and transfer the rest to a human

Would love to hear from others building in voice AI — what's your stack looking like?

Originally published at voicefleet.ai/blog/ai-phone-answering-service

Building an AI Voice Agent POS Integration: Lessons from Connecting to Flipdish

VoiceFleet — Thu, 09 Apr 2026 09:49:31 +0000

One of the interesting technical challenges in voice AI is connecting natural language phone conversations to structured ordering systems. We recently built an integration between our AI phone agent and Flipdish (a restaurant POS/ordering platform popular in Ireland).

The Architecture

Inbound call → STT → LLM (conversation management)
→ Structured order extraction → Flipdish API
→ Order confirmation → TTS → Caller

The tricky parts:

1. Menu item disambiguation. "I'll have the chicken" — which chicken? The AI needs to handle clarification naturally: "We have Chicken Tikka Masala and Chicken Korma — which would you prefer?"

2. Real-time pricing. Order totals need to be accurate as items are added. The AI maintains a running cart synced with Flipdish's pricing.

3. Delivery zone validation. Before completing an order, verify the address is within the restaurant's delivery zone via the Flipdish API.

4. Concurrent modifications. Menu availability can change mid-call (item sells out). The system needs to handle this gracefully.

Key Technical Decisions

Cart state management: Maintained in-memory during the call, committed to Flipdish only on confirmation
Allergen handling: Pre-loaded from Flipdish menu data, queried by the LLM when relevant dietary questions arise
Payment: PCI-compliant tokenized card capture, or cash-on-delivery flag

Results

For restaurants handling 120+ calls/week, the integration captures 20+ orders that would have been missed during peak hours. Average order value €38, so roughly €760/week in recovered revenue.

The Flipdish API is well-documented and Irish-focused (Eircode support, local address formats), which made the integration smoother than US-centric alternatives.

We're building this at VoiceFleet. Happy to answer technical questions about voice AI → POS integrations.