Looking for an experienced Retell builder to partner on a project with real upside. This isn’t a small-fix gig — it’s a chance to help shape a multi-restaurant voice AI platform that I’m building under my agency, ARCO.
The project:
Bilingual (English + Levantine Arabic) voice ordering agent for a restaurant in New York. Going live as the showcase build for ARCO’s restaurant tech platform. After this launches, the plan is to onboard 5-10 more restaurants over the next 6 months and the right person on this project gets first crack at those builds too.
The stack is already built:
Retell AI agent (Claude Haiku, ElevenLabs Sara voice)
Supabase Postgres with custom RPC business logic (46 automated regression tests, all passing)
I’ve done the hard architecture work. The backend is solid.
What I need help with:
The agent works ~80% of the time on real calls. I need a Retell expert to get it to 95%, document what they’re doing, and help me build a playbook so I can replicate this for new restaurants on different POS systems (Toast, Square, Clover, etc.).
This is a strong fit on the reliability/orchestration side. I would not start by rewriting the whole agent. I would first turn the current 80% behavior into a labeled failure set, then tune against that so improvements are measurable.
The first paid slice I would propose:
review 10-20 real call recordings/transcripts;
classify failures as STT/menu alias, Retell config, prompt ambiguity, function/backend schema, POS/API state, or escalation;
tune the highest-impact Retell settings and prompt/function boundary;
add or tighten the stuck-order fallback: capture number, summarize attempted order, SMS/task to restaurant;
leave a POS onboarding playbook skeleton for Toast/Square/Clover so restaurant #2 is not another custom rebuild.
I am not a native Levantine Arabic speaker, so I would handle the system/reliability work and pair the language judgement with your native review or recordings. The useful part I can own is making the agent testable, reducing drift, and turning the POS path into repeatable interfaces.
I put together a compact proof/playbook for this exact shape:
Related Retell/GHL workflow proof:
If useful, send 3-5 failure recordings/transcripts and the current Retell/n8n/POS boundary map. I can reply with a fixed first milestone and timeline.
Jon — the gap between 46 passing backend regression tests and ~80% reliability on real calls really stood out. I’m building independent Voice AI QA at MARUPA focused on verifying whether the downstream business outcome actually happened correctly across the full workflow. I’d be happy to independently test 5 critical failure paths and share a one-page QA snapshot at no cost. Not replacing the Retell expert — just independently validating the result.
@team2 If this is still open, I match the Retell, Supabase, Postgres, Twilio, booking, handoff and evaluation portions. I do not speak Arabic, so your side would need to validate Arabic aliases and phrasing.
My production voice path reaches about 1.5 seconds warm time to first audio. The platform behind it has 76 edge functions and about 140 Postgres tables. Its release gates currently pass 4 of 4 unqualified lead cases, 3 of 3 abuse stops and 12 of 12 AI CRO eval suite.
I would begin by labeling the failed calls you already have, separate speech recognition, function schema, POS state, agent logic and escalation failures, then turn those failures into repeatable cases.
I will not quote a schedule or price until I can see the current workflow and evidence. Message me read-only access if the project remains open.
@team2 — Damian Schaeffer, Natyv AI (natyv.ai). US / ET. Founder-led Retell production tuning (not a rebuild).
Your gap (solid Supabase/n8n backend + ~80% live calls) is exactly where I’d start: label failed calls into STT/alias vs Retell config vs prompt/function boundary vs POS state vs escalation, then tune the highest-impact slice and leave a repeatable playbook. I’m not a Levantine Arabic native speaker — you’d own dialect judgment; I’d own reliability, endpointing/interrupts, escalation SMS, and POS onboarding patterns.
Fixed Phase-1 tune is typically 7–10 days on the existing agent once I see recordings + read-only access. Email Damian@get-myagent.com or DM here if still open.
Jon, the measurable gap is the useful part here: 46 passing backend tests versus roughly 80% reliability on real calls. I would not begin by changing production. I propose a fixed $450 diagnostic: run five representative call paths, classify each failure across STT, Retell configuration, prompt/function boundary, POS state and escalation, then return a reproducible scorecard plus the three highest-impact fixes within one business day. No production changes or Levantine-Arabic judgement in this milestone. I can begin once the milestone is funded and I have read-only access plus five recordings. Is the project still open? Email kalin.smolichki@gmail.com or DM here.
hey jon - i built MedVoq, a production voice AI used in Indian government hospitals, so the jump from an 80% demo to a reliable live call flow is familiar territory. i can audit Retell config, move brittle prompt logic into functions/backend where it belongs, test drift and fallback paths, and turn the fixes into a repeatable POS playbook.
your Supabase RPC + n8n + Twilio stack is close to work i’ve shipped. what rate or project budget are you working with for the first restaurant?
Saw your post about improving the reliability of your bilingual restaurant ordering agent from around 80% toward 95%, while building a repeatable POS integration playbook. We can help with Retell tuning, failure analysis, escalation handling, and documenting a repeatable approach for future restaurant deployments.
I run Pinnakle Media. We build AI voice agents on Retell and Vapi and connect them to the tools you already use, like GoHighLevel, n8n and your calendar.
Here’s how I’d approach yours:
Review real call recordings and identify where the agent fails
Tune the Retell configuration and prompt/function boundaries based on those failures
Test the fixes and document reusable patterns for future POS integrations
If it helps, we can start with a small paid test, so you see the work before you commit to the full build.
Is the project still open? If so, we can discuss the first milestone and scope.