लक्ज़री कार वर्कशॉप्स के लिए AI रिसेप्शनिस्ट बनाने की कहानी - Part 1

• प्रीमियम वर्कशॉप्स में फोन कॉल मिस होने से होने वाले revenue loss को हल करने के लिए, वास्तविक कॉल रिसीव करने वाला AI रिसेप्शनिस्ट ‘Axle’ विकसित किया गया
• AI को Retrieval-Augmented Generation(RAG) के आधार पर बनाया गया, ताकि वेबसाइट से जुटाई गई वास्तविक services और pricing जानकारी के आधार पर सटीक जवाब दिए जा सकें
• Vapi, Deepgram, ElevenLabs, FastAPI, MongoDB Atlas आदि को जोड़कर कॉल कनेक्शन, speech recognition·synthesis, और conversation logs storage जैसी सुविधाएँ लागू की गईं
• voice quality को natural tone और short sentence structure के हिसाब से ट्यून किया गया, ताकि ग्राहकों को दोस्ताना लेकिन प्रोफेशनल जवाब मिलें
• आगे इसे booking system·SMS alerts·callback dashboard तक बढ़ाने की योजना है, और business-specific voice agents में knowledge base और escalation design को मुख्य माना गया है

---

AI रिसेप्शनिस्ट बनाने की प्रक्रिया

• लग्ज़री कार वर्कशॉप चलाने वाले अपने भाई को फोन कॉल्स का जवाब न दे पाने की वजह से हर महीने हजारों डॉलर का नुकसान हो रहा था; इस समस्या को हल करने के लिए कस्टम AI रिसेप्शनिस्ट ‘Axle’ बनाया गया
• इसे साधारण chatbot नहीं, बल्कि वास्तविक कॉल उठा सकने वाले voice-based agent के रूप में डिज़ाइन किया गया, जो pricing, business hours, policies जैसी वास्तविक जानकारी के आधार पर ग्राहकों के सवालों का जवाब देता है
• प्रोजेक्ट को तीन चरणों में बाँटा गया: knowledge base बनाना(RAG pipeline) → फोन कनेक्शन और server integration → voice quality और conversation tone tuning

Step 1: दिमाग बनाना (RAG पाइपलाइन)

• AI को वास्तविक डेटा के आधार पर जवाब देने के लिए Retrieval-Augmented Generation (RAG) तरीका इस्तेमाल किया गया
  • सिर्फ LLM इस्तेमाल करने पर गलत pricing बताने जैसी hallucination का जोखिम था, इसलिए जवाबों को केवल वास्तविक जानकारी तक सीमित रखा गया
• website data scraping के जरिए 21 से अधिक documents इकट्ठे किए गए, जिनमें service types, pricing, estimated time, business hours, payment methods, warranty, और loaner policy जैसी जानकारी शामिल थी
• MongoDB Atlas में knowledge base स्टोर किया गया, और Voyage AI (voyage-3-large) मॉडल से 1024-dimensional vector embeddings बनाए गए
  • Atlas Vector Search index के जरिए semantic search किया गया
• जब ग्राहक का सवाल आता है, तो उसी embedding model से query को बदलकर semantic रूप से मिलते-जुलते top 3 documents खोजे जाते हैं
• Anthropic Claude (claude-sonnet-4-6) मॉडल का उपयोग करके खोजे गए documents को context बनाकर जवाब तैयार किया गया
  • system prompt में “knowledge base के बाहर की जानकारी नहीं, जवाब संक्षिप्त और conversational हों, और न पता होने पर callback offer करें” जैसे नियम शामिल थे
• नतीजतन, terminal में “oil change की कीमत क्या है?” जैसे सवालों पर वास्तविक pricing और service details के साथ सटीक जवाब दिए जा सके

Step 2: वास्तविक फोन नंबर से कनेक्ट करना

• AI के दिमाग को वास्तविक फोन सिस्टम से जोड़ने के लिए Vapi प्लेटफ़ॉर्म का उपयोग किया गया
  • यह फोन नंबर खरीदना, Deepgram आधारित speech recognition, ElevenLabs आधारित speech synthesis, और real-time function calling जैसी सुविधाएँ देता है
• FastAPI webhook server बनाया गया
  • Vapi ग्राहक के सवाल को tool-calls request के रूप में /webhook endpoint पर भेजता है
  • server इसे RAG pipeline को भेजता है, Claude का जवाब लेकर फिर Vapi को वापस भेज देता है
  • बातचीत की स्वाभाविक गति बनाए रखने के लिए latency को न्यूनतम रखना जरूरी था
• Ngrok का उपयोग करके local server को बाहरी HTTPS URL के रूप में expose किया गया, ताकि development के दौरान भी real-time testing हो सके

• Vapi assistant configuration

  • greeting और दो tools(answerQuestion, saveCallback) को webhook से जोड़ा गया
  • सवालों का जवाब देने या जवाब न होने पर नाम और फोन नंबर लेकर callback सेव करने का flow बनाया गया
  • conversation memory feature से पिछली बातचीत का context बनाए रखा गया
  • “आपके business hours क्या हैं?” → “तो tire replacement कितना पड़ेगा?” जैसी लगातार queries संभाली जा सकती हैं

• MongoDB में call logs स्टोर करना

  • caller number, सवाल, जवाब, human agent को transfer हुआ या नहीं, और timestamp रिकॉर्ड किए गए
  • callback requests को अलग callbacks collection में स्टोर किया गया, ताकि बाद में follow-up संपर्क किया जा सके
  • इससे customer inquiry patterns और call volume analysis करना संभव हुआ

Step 3: voice quality ट्यून करना

• text responses और voice responses के फर्क को ध्यान में रखते हुए voice delivery optimization की जरूरत थी
  • जो वाक्य लिखित रूप में स्वाभाविक लगते हैं, वे आवाज़ में सुनने पर अटपटे लग सकते हैं

• ElevenLabs voice selection

  • लगभग 20 voices टेस्ट करने के बाद, ‘Christopher’ voice सबसे स्वाभाविक और वर्कशॉप के माहौल के लिए सबसे उपयुक्त लगी
  • बहुत ज़्यादा robotic या ज़रूरत से ज़्यादा cheerful voices उपयुक्त नहीं थीं

• system prompt में बदलाव

  • छोटे वाक्य, Markdown हटाना, “बहुत अच्छा सवाल है!” जैसे अनावश्यक वाक्य हटाना
  • कीमतों को natural language में बोलना (“forty-five dollars”)
  • जवाबों को 2~4 वाक्यों तक सीमित रखना
  • लक्ष्य था दोस्ताना और प्रोफेशनल human-like voice हासिल करना

• escalation(callback) flow की testing

  • knowledge base में मौजूद न होने वाले सवाल पर AI यह कहे कि उसे पता नहीं, फिर नाम और नंबर माँगकर MongoDB में सेव करे
  • इसके बाद वर्कशॉप मालिक खुद follow-up कर सके

• integration tests लिखना

  • RAG pipeline, webhook handling, और पूरे flow की जाँच की गई
  • गलत requests, search results न मिलना, callback number missing होना जैसे edge cases भी शामिल किए गए

tech stack

• Vapi (Deepgram & ElevenLabs integration) — फोन नंबर, speech recognition, speech synthesis, function calling
• Ngrok — local development के लिए HTTPS tunnel
• FastAPI + Uvicorn — webhook server
• MongoDB Atlas — knowledge base, vector search, call logs, callback queue
• Voyage AI (voyage-3-large) — semantic text embeddings
• Anthropic Claude (claude-sonnet-4-6) — knowledge-based response generation
• Python — pymongo, voyageai, anthropic, fastapi के साथ
• Copilot CLI — build automation tool

अगले कदम

• फिलहाल AI में सवाल-जवाब और callback collection तक की functionality पूरी हो चुकी है
• अगला लक्ष्य calendar integration के जरिए real-time booking, SMS alerts, callback management dashboard, security hardening, और Railway deployment है
• पूरा होने पर यह 24x7 काम कर सकेगा और फोन कॉल मिस होने से होने वाले revenue loss को रोकेगा
• सबसे मुश्किल हिस्सा code नहीं, बल्कि वर्कशॉप के अनुकूल voice tone तैयार करना था
• मुख्य सीख: business-specific voice agents में raw LLM को सीधे इस्तेमाल नहीं करना चाहिए
  • उन्हें वास्तविक knowledge base पर आधारित होना चाहिए, और न पता होने पर क्या करना है(escalation) इसका flow ज़रूर डिज़ाइन होना चाहिए
  • यह कोई exception नहीं, बल्कि core feature है

[GN⁺]

Hacker News की राय

• मैं पहले service advisor (रिसेप्शन/इंटेक प्रभारी) के तौर पर काम कर चुका हूँ। लेख में बताया गया सिस्टम व्यवहारिक रूप से काम नहीं करेगा, ऐसा लगता है

  1. अगर वही मरम्मत इतिहास मौजूद न हो, तो estimate गलत होने की संभावना बहुत अधिक है। कुछ राज्यों में गलत estimate कानूनी समस्या बन सकता है
  2. parts inventory और कीमतें हर समय बदलती रहती हैं। अगर सिस्टम इसे reflect न करे, तो सिर्फ भ्रम पैदा होगा
  3. नया काम हो तो parts selection से ही जटिलता शुरू हो जाती है। luxury vehicles में यह और भी मुश्किल होता है
  4. उपयोगी हिस्सा बस vehicle pickup notification जैसा कुछ हो सकता है। यानी काम पूरा होने का समय या progress update अपने-आप बताने के लिए
     इस तरह का development सिर्फ अहंकार से आगे बढ़कर खतरनाक है। validation के बिना सिर्फ assumptions पर बनाना, दूसरों की आजीविका को जोखिम में डालता है
  • मैं भी expert नहीं हूँ, लेकिन इस तरह की दिखावटी टेक-बाज़ी वाली बात समझ में आती है। अगर receptionist चाहिए, तो किसी इंसान को hire करना स्वाभाविक है। unproven AI solution पर business छोड़ देना समझना मुश्किल है। पता नहीं सिर्फ manage नहीं करना चाहते या trend के पीछे भाग रहे हैं
  • दरअसल एक और सरल समाधान है। गाड़ी के नीचे काम कर रहा व्यक्ति hands-free speakerphone से कॉल उठा सके, इतना काफी है। local speech recognition model इस्तेमाल करें तो neural network technology का ज़िक्र भी कर सकते हैं, और mic समेत लागत 200~300 डॉलर में पूरी हो जाएगी
  • लेकिन मूल लेख देखें तो यह workshop पहले से fixed services and pricing पर काम करती है। इसलिए जब तक custom estimate की ज़रूरत न हो, ऊपर की समस्याएँ लागू नहीं होतीं
  • “खतरनाक” कहना कुछ ज़्यादा लगता है। developer अपने भाई के business की मदद कर रहा है, और भले सिस्टम perfect न हो, अगर customer conversion 10% भी बढ़ जाए तो यह काफ़ी मूल्यवान है
  • vehicle completion alerts या progress updates तो TTS system से कई साल पहले से संभव थे। इसके लिए LLM की ज़रूरत नहीं है

• हमारे इलाके की Subaru dealership में फोन booking के समय AI assistant चुनने का विकल्प है। इस्तेमाल करके देखा, तो यह इंसान से ज़्यादा सटीक और तेज़ लगा। Taco Bell की AI ordering भी इसी तरह शानदार थी। ऐसे मामलों में इंसान से बात न करने से कोई नुकसान नहीं, और ज़रूरत हो तो कभी भी human agent से जोड़ा जा सकता है

• इस तरह के blog post आधी कहानी ही बताते हैं। असली सवाल यह है कि revenue बढ़ा या नहीं, customers को bot होने से फ़र्क पड़ा या नहीं, और failure cases थे या नहीं

  • सच कहें तो AI से पहले भी यह समस्या virtual assistant service से हल की जा सकती थी। महीने के 200~1000 डॉलर काफी हैं, और इससे वही revenue वापस मिलता है जो पहले छूट रहा था। AI बस एक और जटिल mousetrap है, और premium service में human response कहीं ज़्यादा भरोसेमंद लगता है
  • शायद अभी तक इसका real-world testing पर्याप्त नहीं हुआ होगा। email address जैसी चीज़ें LLM के लिए ठीक-ठीक लिख लेना मुश्किल है। real-time voice response में Anthropic धीमा था, जबकि Groq 200ms से कम पर बहुत तेज़ था
  • मुझे एक बार तुरंत auto glass replacement कराना था, लेकिन automated voice system बार-बार बेकार की जानकारी मांगता रहा, तो मैंने कॉल काट दी। साधारण booking के लिए ठीक हो सकता है, लेकिन special cases में आखिरकार इंसान से ही बात करनी पड़ती है
  • ऐसी कोशिश तर्कसंगत है। बस असली performance अभी अज्ञात है। यह मानो AI optimists और pessimists को अलग करने वाली litmus test जैसी चीज़ है

• आजकल मैं LLM-आधारित phone assistant को काफ़ी सकारात्मक नज़र से देखता हूँ। जब मैंने Mint Mobile customer support पर कॉल किया, तो LLM ने बात को स्वाभाविक रूप से समझा और 1 मिनट में समस्या हल कर दी। पहले यही काम 20 मिनट से ज़्यादा इंतज़ार करवाता

  • LLM का उच्चारण साफ़ होता है, headset noise नहीं होता, और समझना आसान होता है। हाँ, eBay के LLM chatbot जैसी बुरी मिसालें भी हैं, लेकिन अच्छी तरह implement किया गया system बहुत बढ़िया काम करता है
  • Amazon का chat support भी ऐसा ही है। LLM पहले से order information व्यवस्थित कर देता है, और इंसान सिर्फ अंतिम approval देता है। काफ़ी efficient है
  • लेकिन सवाल यह है कि ऐप में हल हो सकने वाली चीज़ के लिए LLM की ज़रूरत क्यों पड़े। आखिर में यह development process की विफलता जैसा लगता है
  • मेरा भी ऐसा ही अनुभव रहा है। मैंने technical सवाल पूछा, LLM ने ठीक जवाब दिया, और बाद में human agent ने संभाला, लेकिन वह उल्टा कम professional लगा। फिर भी समय बच गया
  • यह पुराने robots से बहुत बेहतर है, और RAG-आधारित chatbot documentation search की जगह लेने लायक उपयोगी हो सकता है। उदाहरण के लिए manager.io का chatbot documents ढूंढने के बजाय सीधे जवाब दे देता था, जो सुविधाजनक था

• लेख के अनुसार, workshop फोन नहीं उठा पाने की वजह से हर महीने हज़ारों डॉलर का नुकसान झेल रही है। अगर ऐसा है, तो लगभग 500 डॉलर महीने का outsourced receptionist कहीं बेहतर ROI देगा

  • सच तो यह है कि voicemail से भी कुछ समस्याएँ हल हो सकती हैं। AI हो या voicemail, कुछ customers तो वैसे भी कॉल काट देंगे
  • और अगर काम इतना ज़्यादा है कि फोन उठाने का समय नहीं, तो अतिरिक्त customers लेने की क्षमता भी शायद नहीं होगी
  • मेरा एक दोस्त outsourced reception service इस्तेमाल करता है, जो 150 पाउंड महीने में 9 से 5 तक कवर करती है। वह खुद शाम को schedule adjust कर लेता है। अगर लेख में कही बात सही है, तो workshop शायद पहले ही 100% capacity पर चल रही है
  • अच्छा service writer महँगा होता है, लेकिन उतना ही क़ीमती भी। वह customer trust बढ़ाता है, और बाद में business takeover की संभावना भी हो सकती है
  • आखिरकार ROI शायद उस AI training course के प्रचार प्रभाव का ही हिस्सा है, जिसे ब्लॉग बेचना चाहता है

• आजकल अगर लगे कि सामने robot जवाब दे रहा है, तो मैं तुरंत कॉल काट देता हूँ। लेकिन जल्द ही AI voice शायद इंसान से अलग पहचान में न आए। तब फोन पर trust ही टूट सकता है। email और LinkedIn तो पहले ही AI spam से भरे पड़े हैं, इसलिए लोग फोन की तरफ गए थे, लेकिन वह भी शायद जल्द खत्म हो जाएगा

  • फिर भी अगर voicemail पर ही जाना है, तो लोग वैसे भी काट देंगे, इसलिए नुकसान नहीं है
  • अगर AI मेरी बात गलत समझे और आखिर में इंसान से जोड़ दे, तो वही बात दो बार समझानी पड़ती है, जो थका देती है
  • हाल में मैं कार देख रहा था और कई dealers से संपर्क किया। बाद में समझ आया कि वे सब LLM-आधारित नकली नाम वाले agents थे। जवाब देने की speed इतनी तेज़ थी कि अजीब लग रहा था

• कहा गया कि “यह general-purpose chatbot नहीं है”, लेकिन वास्तव में यह बस 2026 मॉडल का general-purpose chatbot ही है

• ब्लॉग के “About” page में देखा कि लेखक को उस influencer से प्रेरणा मिली, जो कहता है कि उसने coding सीखकर अमीर बन गया। लेकिन यह रवैया उस engineering culture से काफ़ी दूर है, जिसकी मैं उम्मीद करता हूँ

• लोगों का AI से personal blog लिखवाना थोड़ा उदास करने वाला लगता है

  • फिर भी यह अच्छी बात है कि उसने ईमानदारी से बताया। ज़्यादातर लोग writing में अनुभवी नहीं होते और LLM के जरिए “अच्छा लिखा हुआ लेख” पाने की उम्मीद करते हैं। हो सकता है उन्हें AI से लिखा गया लेख बुरा न लगे

• क्या यहाँ RAG सच में ज़रूरी है? अगर बात सिर्फ price list और business hours की है, तो सब कुछ context window में आ जाएगा

  • शायद यह learning purpose वाला project रहा होगा। मैं भी कभी-कभी personal projects में over-engineered architecture आज़माकर सीखता हूँ
  • voice conversation में latency बड़ा मुद्दा है। अगर साइट पर कई pages हों, तो RAG से जल्दी कुछ हिस्सा लाकर LLM को detail answer बनवाना efficient हो सकता है
  • सीधे पूरी website और price list को context में डालना ज़्यादा सरल है
  • मैं भी सहमत हूँ। इस स्तर की जानकारी एक बार में पर्याप्त रूप से संभाली जा सकती है
  • कुल मिलाकर यह architecture हद से ज़्यादा जटिल है