WEBVTT 00:00:00.000 --> 00:00:05.059 The idea of a perfect, always -on employee is 00:00:05.059 --> 00:00:07.960 it's no longer some concept for the distant future. 00:00:08.080 --> 00:00:10.859 It's really here. It is. I mean, imagine an assistant 00:00:10.859 --> 00:00:14.099 who never misses a detail, knows a client's history 00:00:14.099 --> 00:00:17.379 instantly, and handles your calendar flawlessly 00:00:17.379 --> 00:00:19.620 any hour of the day. Yeah. Today, we're diving 00:00:19.620 --> 00:00:21.640 deep into the architecture that makes this automated 00:00:21.640 --> 00:00:23.780 perfection actually possible. And what's amazing 00:00:23.780 --> 00:00:26.320 is how affordable it is. You can run this for 00:00:26.320 --> 00:00:29.859 less than $50 a month. Welcome back. So in our 00:00:29.859 --> 00:00:31.699 last discussion, we set up the voice, right? 00:00:31.780 --> 00:00:35.439 We use VAPI. And we built the external memory 00:00:35.439 --> 00:00:38.320 in Google Sheets. So the AI can talk. It sounds 00:00:38.320 --> 00:00:40.820 great. But it can't actually do anything yet. 00:00:40.960 --> 00:00:43.600 It has no hands. Exactly. Our mission today is 00:00:43.600 --> 00:00:45.700 to build the muscles. We're building the logical 00:00:45.700 --> 00:00:47.799 pathways that the AI uses to interact with the 00:00:47.799 --> 00:00:50.700 world. We need to turn VAPI from just a chat 00:00:50.700 --> 00:00:53.600 bot into a competent administrative assistant. 00:00:53.840 --> 00:00:55.880 So we're connecting the brain to the body. And 00:00:55.880 --> 00:00:57.520 the core tool for this logic, you're saying, 00:00:57.840 --> 00:01:00.320 is NAN, which kind of lets us draw out these 00:01:00.320 --> 00:01:02.939 complex flow charts. Exactly. It's the central 00:01:02.939 --> 00:01:06.299 switchboard. We have to securely connect VAPI 00:01:06.299 --> 00:01:08.439 to our Google Calendar and our Google Sheets. 00:01:08.569 --> 00:01:11.049 And in doing that, we're going to design seven 00:01:11.049 --> 00:01:13.769 very specific tools that the assistant can use 00:01:13.769 --> 00:01:15.670 reliably. Okay, so let's start with that central 00:01:15.670 --> 00:01:18.129 nervous system first. If VAPI is going to talk 00:01:18.129 --> 00:01:20.849 to NAN, we can't just, you know, open the floodgates 00:01:20.849 --> 00:01:23.829 to the entire internet. We need a secure single 00:01:23.829 --> 00:01:26.709 entry point. Absolutely. The security and the 00:01:26.709 --> 00:01:28.709 routing. You have to get that right from minute 00:01:28.709 --> 00:01:31.549 one. And in NAN, this starts with one specific 00:01:31.549 --> 00:01:33.510 piece, and it's non -negotiable for this use 00:01:33.510 --> 00:01:36.230 case. It's called the MCP server trigger node. 00:01:36.569 --> 00:01:39.849 The MCP server trigger. OK, why that specific 00:01:39.849 --> 00:01:42.430 node? Why not just a standard webhook or something 00:01:42.430 --> 00:01:44.810 simpler? Because it's designed to be a router. 00:01:45.409 --> 00:01:48.049 Think of it this way. We want the AI to knock 00:01:48.049 --> 00:01:50.790 on this single main door whenever it needs help, 00:01:50.969 --> 00:01:52.989 whether that's looking up a client, checking 00:01:52.989 --> 00:01:55.769 a calendar, or deleting an appointment. This 00:01:55.769 --> 00:01:57.670 one node is going to direct all that traffic. 00:01:58.090 --> 00:02:00.170 It's the gateway to all seven tools we're about 00:02:00.170 --> 00:02:02.450 to build. And the authentication piece. This 00:02:02.450 --> 00:02:04.370 is where we put the bouncer at that main door. 00:02:04.909 --> 00:02:07.459 Precisely. You have to go into editing and settings 00:02:07.459 --> 00:02:10.539 and create an API key. That key is the secret 00:02:10.539 --> 00:02:13.740 password. When the AI makes a request, it has 00:02:13.740 --> 00:02:16.319 to show that key. And if it doesn't? If it doesn't, 00:02:16.379 --> 00:02:18.819 or if the key is wrong, the request just gets 00:02:18.819 --> 00:02:21.539 dropped. Yeah. It makes sure that only your VAPI 00:02:21.539 --> 00:02:23.319 assistant can get to your calendar and client 00:02:23.319 --> 00:02:26.259 data, not some random bot on the internet. So 00:02:26.259 --> 00:02:29.259 the MCP trigger and the API key, that's our secure 00:02:29.259 --> 00:02:31.280 front door. Without that, the whole thing is 00:02:31.280 --> 00:02:34.469 just... That's right. Your route's request securely. 00:02:34.789 --> 00:02:36.889 It's the main door and the security guard, all 00:02:36.889 --> 00:02:39.530 in one. Okay. So once the AI has permission to 00:02:39.530 --> 00:02:41.969 come inside, the very first thing any good assistant 00:02:41.969 --> 00:02:44.990 does is recognize who's calling. So that brings 00:02:44.990 --> 00:02:47.949 us to client identification, tools one and two. 00:02:48.009 --> 00:02:50.689 Yes. And the customer experience really hinges 00:02:50.689 --> 00:02:53.069 on this. I mean, if the AI asks for your name 00:02:53.069 --> 00:02:54.729 and email, but you've been a client for three 00:02:54.729 --> 00:02:57.430 years, it feels broken. Yeah, impersonal. So 00:02:57.430 --> 00:02:59.569 how fast can we really pull that data from a 00:02:59.569 --> 00:03:01.900 Google Sheet? I mean, we are relying on a pretty 00:03:01.900 --> 00:03:04.659 simple CRM here. Well, that simplicity is actually 00:03:04.659 --> 00:03:07.419 the benefit for rapid automation projects like 00:03:07.419 --> 00:03:09.740 this. You're not spitting up a whole complex 00:03:09.740 --> 00:03:13.780 database. We use tool one, client lookup. The 00:03:13.780 --> 00:03:16.259 AI gets the customer's email address, and this 00:03:16.259 --> 00:03:19.939 tool immediately just hits the client's tab in 00:03:19.939 --> 00:03:22.139 that Google sheet. And the logic is pretty straightforward. 00:03:22.340 --> 00:03:25.680 It's almost binary. If the email is found, the 00:03:25.680 --> 00:03:28.520 output is rich. It says customer found. Maybe 00:03:28.520 --> 00:03:30.960 it even pulls their last service date. If nothing's 00:03:30.960 --> 00:03:33.400 found, the output is just as clear. This is a 00:03:33.400 --> 00:03:36.199 new client. But relying on a Google Sheet, I 00:03:36.199 --> 00:03:38.659 mean, while it's free and accessible, does that 00:03:38.659 --> 00:03:40.960 ever become a bottleneck? What if a business 00:03:40.960 --> 00:03:44.759 scales to, say, 10 ,000 clients? Does that simplicity 00:03:44.759 --> 00:03:47.340 suddenly become a liability? That's an excellent 00:03:47.340 --> 00:03:49.639 question on scalability. And for the vast majority 00:03:49.639 --> 00:03:52.419 of small to medium businesses, the sheet is plenty 00:03:52.419 --> 00:03:55.979 fast. Really? Yeah. Simple sheets provide persistent, 00:03:56.460 --> 00:03:59.900 accessible, and free memory storage. You can't 00:03:59.900 --> 00:04:01.900 beat that for speed of deployment. If you hit 00:04:01.900 --> 00:04:04.000 50 ,000 clients, sure, you'd migrate to a proper 00:04:04.000 --> 00:04:06.500 database, but the logic inside data end would 00:04:06.500 --> 00:04:09.159 barely change. That makes sense. Start simple, 00:04:09.599 --> 00:04:11.360 scale when you need to. So if they are a new 00:04:11.360 --> 00:04:13.719 client, we have to grab that data. That's tool 00:04:13.719 --> 00:04:17.160 two. New Client CRM. Exactly. So if the lookup 00:04:17.160 --> 00:04:20.399 fails, VAPI just prompts the client for their 00:04:20.399 --> 00:04:23.279 details, sends that info to the new client tool, 00:04:23.540 --> 00:04:26.120 and we use the Google Sheets node, specifically 00:04:26.120 --> 00:04:29.319 the append action, to add a new row. It just 00:04:29.319 --> 00:04:32.139 adds the email, full name, phone number right 00:04:32.139 --> 00:04:33.939 to the client's tab. And that's how you build 00:04:33.939 --> 00:04:35.839 the memory. This is how persistent memory is 00:04:35.839 --> 00:04:38.079 built, yeah, in milliseconds. So the next time 00:04:38.079 --> 00:04:41.000 they call, the AI knows them. That seamless handoff 00:04:41.000 --> 00:04:43.360 between tool one and tool two. That's the core 00:04:43.360 --> 00:04:45.379 of it. Okay, now we get to the core function, 00:04:45.899 --> 00:04:48.079 checking availability and actually booking the 00:04:48.079 --> 00:04:50.060 appointment. This is where we touch the Google 00:04:50.060 --> 00:04:52.660 Calendar, which for a lot of companies is, you 00:04:52.660 --> 00:04:54.740 know, their most protected asset. This is the 00:04:54.740 --> 00:04:56.860 real execution. It's handled by tools three and 00:04:56.860 --> 00:05:00.079 four. So tool three is check availability. This 00:05:00.079 --> 00:05:02.959 tool requires the AI to send a really specific 00:05:02.959 --> 00:05:06.199 search window, say, from 8 a .m. tomorrow to 00:05:06.199 --> 00:05:09.300 5 p .m. tomorrow. A very tight window. We use 00:05:09.300 --> 00:05:11.480 the Google Calendar node called Get Many Events. 00:05:11.740 --> 00:05:14.000 It just returns a list of all the busy blocks 00:05:14.000 --> 00:05:17.639 of time. Now, here's the clever part. If that 00:05:17.639 --> 00:05:21.860 list comes back empty, The AI knows the entire 00:05:21.860 --> 00:05:24.120 search window is free. It can just offer those 00:05:24.120 --> 00:05:25.860 slots. It doesn't have to parse a bunch of little 00:05:25.860 --> 00:05:29.180 openings. Whoa. Imagine scaling that to a billion 00:05:29.180 --> 00:05:31.379 queries just handled instantly by a system using 00:05:31.379 --> 00:05:33.480 that simple logic. That's incredible efficiency. 00:05:33.660 --> 00:05:36.100 You avoid all that human back and forth. Right. 00:05:36.420 --> 00:05:39.620 So once the AI confirms a time with the client, 00:05:40.079 --> 00:05:43.230 we move to tool four. book event. This is the 00:05:43.230 --> 00:05:46.149 critical execution step. It needs a few inputs. 00:05:46.790 --> 00:05:49.790 The exact start and end times, the client's email, 00:05:50.110 --> 00:05:51.949 and a summary. You know, something like deluxe 00:05:51.949 --> 00:05:53.850 exterior wash. And it just creates the event. 00:05:54.050 --> 00:05:55.730 It creates the event on the Google Calendar, 00:05:55.850 --> 00:05:58.009 but then there's a crucial accountability step 00:05:58.009 --> 00:06:01.430 right after. We immediately log a new row in 00:06:01.430 --> 00:06:03.610 a separate appointment log sheet. Why a separate 00:06:03.610 --> 00:06:05.769 log? I mean, isn't the event already on the calendar? 00:06:05.990 --> 00:06:09.480 It is, but the sheet has to capture one specific 00:06:09.480 --> 00:06:12.199 piece of data that a human would never remember, 00:06:12.540 --> 00:06:15.819 and that's the unique calendar event ID. The 00:06:15.819 --> 00:06:18.860 Google Calendar API generates this unique identifier 00:06:18.860 --> 00:06:21.839 when the event is created. We have to log that 00:06:21.839 --> 00:06:24.810 ID in our sheet instantly. So that calendar event 00:06:24.810 --> 00:06:27.329 ID, it's not just a receipt. It's the required 00:06:27.329 --> 00:06:29.949 ticket that the AI needs to interact with Google's 00:06:29.949 --> 00:06:32.930 API later on. It feels like if that sheet ever 00:06:32.930 --> 00:06:35.250 loses that ID, the whole modification system 00:06:35.250 --> 00:06:38.569 just breaks. Exactly. That event ID acts like 00:06:38.569 --> 00:06:41.250 the required ticket number for any future modification 00:06:41.250 --> 00:06:43.699 or cancellation. We've automated the booking, 00:06:44.019 --> 00:06:46.279 sure, but we've also automated the ability to 00:06:46.279 --> 00:06:48.959 manage it. Which leads us right into the inevitability 00:06:48.959 --> 00:06:52.139 of change. Plans shift. A smart assistant has 00:06:52.139 --> 00:06:54.259 to handle that, which means it needs that ticket 00:06:54.259 --> 00:06:56.560 number. Right. And we use three separate tools 00:06:56.560 --> 00:06:58.560 for this, which creates three distinct safety 00:06:58.560 --> 00:07:01.680 nets. Tool five is lookup appointment. Before 00:07:01.680 --> 00:07:03.899 we change a thing, we use the customer's email 00:07:03.899 --> 00:07:06.779 to search our log and get that event ID. No ID, 00:07:07.100 --> 00:07:09.379 no changes allowed. And if we have the ID, we 00:07:09.379 --> 00:07:12.199 can reschedule with tool six. Update appointment. 00:07:12.540 --> 00:07:15.000 Yep. We feed the system the event ID, the new 00:07:15.000 --> 00:07:17.420 start time, the new end time, it updates the 00:07:17.420 --> 00:07:19.259 calendar event, and then right away it updates 00:07:19.259 --> 00:07:21.519 the log in our Google Sheet. Marks the old time 00:07:21.519 --> 00:07:24.160 is moved or something. So you have a clear paper 00:07:24.160 --> 00:07:26.959 trail. You have a perfect audit trail. You know, 00:07:26.959 --> 00:07:29.680 I still wrestle with prompt drift myself, where 00:07:29.680 --> 00:07:31.800 an AI starts kind of veering off course in a 00:07:31.800 --> 00:07:34.639 long conversation. Having these structured tools, 00:07:34.720 --> 00:07:37.199 it just removes so much uncertainty. The AI doesn't 00:07:37.199 --> 00:07:39.089 have to figure out how to change a meeting. It 00:07:39.089 --> 00:07:41.629 just runs Tool 6. And for cancellations, we have 00:07:41.629 --> 00:07:44.230 the cleanup crew, Tool 7. Delete appointment. 00:07:44.310 --> 00:07:46.810 Right. Takes the event ID, deletes the event 00:07:46.810 --> 00:07:49.350 from the calendar, and marks the log entry in 00:07:49.350 --> 00:07:53.029 Google Sheets as cancelled. This structured logic 00:07:53.029 --> 00:07:55.850 ensures accurate changes because nothing can 00:07:55.850 --> 00:07:58.600 be edited. without that event ID. OK, so we've 00:07:58.600 --> 00:08:00.759 built the muscle in NAN. We have the secure logic, 00:08:00.860 --> 00:08:03.560 the seven tools. Now we have to connect the brain, 00:08:03.819 --> 00:08:07.079 VAPI, to the muscle, NAN, to actually make it 00:08:07.079 --> 00:08:09.120 live. This is often where things get a little 00:08:09.120 --> 00:08:11.240 technically tricky. It's really just a two -part 00:08:11.240 --> 00:08:14.540 technical handshake. Find the right URL, and 00:08:14.540 --> 00:08:17.839 then secure the connection. First, you copy the 00:08:17.839 --> 00:08:20.459 production URL from that very first NAN node 00:08:20.459 --> 00:08:23.410 we set up, the MCP server trigger. That's the 00:08:23.410 --> 00:08:25.670 address for the front door. And then we tell 00:08:25.670 --> 00:08:28.509 VAPI where to find this automation. Right. You 00:08:28.509 --> 00:08:30.970 go into the API's tools tab, you paste that URL 00:08:30.970 --> 00:08:33.730 into the server URL box, and then we set up that 00:08:33.730 --> 00:08:35.870 security bridge with the API key. And I noticed 00:08:35.870 --> 00:08:38.679 this requires setting up a security header. Why 00:08:38.679 --> 00:08:40.700 is that so important? Why not just put the key 00:08:40.700 --> 00:08:43.519 in the URL or something? Using a header is just 00:08:43.519 --> 00:08:46.360 the standardized, secure way to pass these kinds 00:08:46.360 --> 00:08:48.460 of authentication tokens. So you create a new 00:08:48.460 --> 00:08:50.980 header, the key is authorization, the value is 00:08:50.980 --> 00:08:53.379 the word bearer, then a space, and then you paste 00:08:53.379 --> 00:08:57.080 in that long N8AN API key. That structure is 00:08:57.080 --> 00:09:00.529 how VAPI proves its identity to N8AN. And you 00:09:00.529 --> 00:09:02.049 mentioned one more technical detail that can 00:09:02.049 --> 00:09:03.870 dramatically affect the user experience, something 00:09:03.870 --> 00:09:07.129 about speed. Yes. In VPI, look for a setting 00:09:07.129 --> 00:09:09.330 called client -server communication. And you 00:09:09.330 --> 00:09:12.289 have to enable server -sent events or SSE. For 00:09:12.289 --> 00:09:14.629 everyone listening, why does SSE make such a 00:09:14.629 --> 00:09:16.210 huge difference to the customer on the other 00:09:16.210 --> 00:09:20.490 end of the phone? So without SSE, VAPI has to 00:09:20.490 --> 00:09:23.789 keep asking NAN, are you done yet? Are you done 00:09:23.789 --> 00:09:26.070 yet? It's called polling. Right. With SSE, as 00:09:26.070 --> 00:09:29.029 soon as NAN is done, It pushes the result back 00:09:29.029 --> 00:09:32.669 to VAPI. I'm done. It completely removes that 00:09:32.669 --> 00:09:36.610 frustrating delay. Yeah. SSE is a crucial technical 00:09:36.610 --> 00:09:39.809 detail that just makes the AI voice receptionist 00:09:39.809 --> 00:09:42.429 respond much faster. It feels instant. It makes 00:09:42.429 --> 00:09:44.570 the whole call feel instantaneous and professional. 00:09:44.730 --> 00:09:46.909 OK. Before we unleash this on the world, we have 00:09:46.909 --> 00:09:50.009 to test it rigorously. What's the testing roadmap 00:09:50.009 --> 00:09:51.870 here before we flip the switch? You had to be 00:09:51.870 --> 00:09:54.590 the first customer. And there are three primary 00:09:54.590 --> 00:09:57.090 tests to confirm the data is flowing right. OK. 00:09:57.230 --> 00:10:00.350 Test one, the new customer. Call the number, 00:10:00.509 --> 00:10:02.610 pretend you're John Doe, use a throwaway email, 00:10:03.070 --> 00:10:05.870 then check the sheet. Did a new row actually 00:10:05.870 --> 00:10:08.250 appear in the clients tab? That confirms tool 00:10:08.250 --> 00:10:09.889 two is working. Then you test the main function, 00:10:10.049 --> 00:10:13.230 the booking. Test two, the booking. Exactly. 00:10:13.529 --> 00:10:16.350 Call back, ask to book a service, then check 00:10:16.350 --> 00:10:18.769 two things. Did the event show up on your Google 00:10:18.769 --> 00:10:22.250 calendar? And more importantly, did it log in 00:10:22.250 --> 00:10:25.220 the appointment sheet with the event ID? If that 00:10:25.220 --> 00:10:28.240 ID is missing, the booking is fundamentally broken. 00:10:28.879 --> 00:10:31.059 And finally, we have to verify the modification 00:10:31.059 --> 00:10:34.659 tools, which all depend on that ID. Test 3. The 00:10:34.659 --> 00:10:37.820 change. You got it. Call back as that same client. 00:10:38.200 --> 00:10:40.100 Ask to move the appointment from 2 p .m. to 4 00:10:40.100 --> 00:10:43.580 p .m. Then verify. Did the calendar event move? 00:10:44.179 --> 00:10:46.500 And did the log sheet update its status? You 00:10:46.500 --> 00:10:48.840 have to confirm all three of those pieces. And 00:10:48.840 --> 00:10:52.210 one last thing. That latency. Even if it's just 00:10:52.210 --> 00:10:54.450 a second and a half while N8N is processing, 00:10:54.850 --> 00:10:57.009 that silence can feel really awkward to a customer. 00:10:57.169 --> 00:10:59.330 It feels broken. You have to anticipate that 00:10:59.330 --> 00:11:01.690 delay. And the fix isn't technical, it's conversational. 00:11:01.850 --> 00:11:03.769 You have to go back and adjust the system prompt 00:11:03.769 --> 00:11:06.649 in VAPI. Ah, so you teach the AI to fill the 00:11:06.649 --> 00:11:08.610 silence. Exactly. You teach it to say something 00:11:08.610 --> 00:11:10.330 like, let me just process that real quick or, 00:11:10.350 --> 00:11:12.129 OK, checking those times for you now. So it's 00:11:12.129 --> 00:11:15.029 not just technical verification. Teaching the 00:11:15.029 --> 00:11:17.769 AI to fill the silence during execution is really 00:11:17.769 --> 00:11:20.470 just about managing customer expectations. That's 00:11:20.470 --> 00:11:23.190 all it is. The prompts have to manage expectations 00:11:23.190 --> 00:11:25.490 during that brief delay. It keeps the customer 00:11:25.490 --> 00:11:27.629 engaged and confident that the system didn't 00:11:27.629 --> 00:11:30.860 just hang up on them. sponsor read placeholder. 00:11:31.019 --> 00:11:33.240 So if we just recap what we build here today 00:11:33.240 --> 00:11:37.120 it's a fully realized integrated system. We've 00:11:37.120 --> 00:11:39.000 connected the brain and the muscle to create 00:11:39.000 --> 00:11:42.139 an AI receptionist that can manage calls instantly, 00:11:42.860 --> 00:11:45.539 identify clients, and manage a real Google Calendar 00:11:45.539 --> 00:11:48.500 without those little human errors. And the cost 00:11:48.500 --> 00:11:50.779 equation is what really makes this a game changer 00:11:50.779 --> 00:11:53.419 for so many businesses. The operational cost 00:11:53.419 --> 00:11:56.340 is staggering for the value you get. EAPI charges 00:11:56.340 --> 00:11:58.940 pennies a minute, right? Maybe $15 to $30 a month 00:11:58.940 --> 00:12:02.259 for a decent call volume. NHA can be free, or 00:12:02.259 --> 00:12:05.240 maybe $20 for their cloud service. and Google 00:12:05.240 --> 00:12:07.340 Sheets and Calendar are already free. So you're 00:12:07.340 --> 00:12:09.899 all in for. We're talking about a total operational 00:12:09.899 --> 00:12:12.919 cost under $50 a month for a system that runs 00:12:12.919 --> 00:12:17.039 $247. This isn't just a tool, it's a genuine 00:12:17.039 --> 00:12:20.000 competitive business asset that delivers quality 00:12:20.000 --> 00:12:22.480 service instantly. That competitive advantage 00:12:22.480 --> 00:12:24.519 is profound. I mean, while your competitors are 00:12:24.519 --> 00:12:26.820 missing calls or putting clients on hold or just 00:12:26.820 --> 00:12:29.100 answering between nine and five, your business 00:12:29.100 --> 00:12:32.200 is always open, it's polite, and it's ready to 00:12:32.200 --> 00:12:34.679 serve. Yeah, ready to execute. You've created 00:12:34.679 --> 00:12:37.320 a zero -friction system. And the fundamental 00:12:37.320 --> 00:12:39.600 question that this level of automation raises 00:12:39.600 --> 00:12:42.559 for business survival is this. What level of 00:12:42.559 --> 00:12:45.559 2147 instantaneous service will consumers just 00:12:45.559 --> 00:12:48.259 come to expect? And how far behind will businesses 00:12:48.259 --> 00:12:50.600 be if they wait to automate this core function? 00:12:50.860 --> 00:12:52.519 That's a thought worth exploring on your own.