Automation is easy to demo. Making it trustworthy is the real job.

I built an automation that handles missed calls for a bike touring company, using n8n, AI and Twilio. Building it was the easy part. The hard part was the edge cases, the messy human situations that never show up in a demo.

Here's what I learned.

What "no answer" actually means

Twilio marks a call as "no answer" the instant it happens. While testing, I had to redefine what that means for this business.

In that moment, someone has called, it's about to ring out, and they hang up. Maybe they're calling back on another number. Maybe they remembered to text instead. If the workflow fires off "Sorry we missed your call!" right away, it may text someone who is already talking to the shop through a different channel.

That is the kind of thing that quietly makes an automated business feel less human.

The tradeoff

I don't think there's one right answer here.

• Respond instantly. Faster for the customer, but no protection against the immediate-callback scenario.
• Wait and re-verify. Safer and more accurate, but a real person waits a couple of extra minutes for their text.

I went with the second option. The workflow saves a unique CallSid, then re-checks the call's status before sending anything.

The bug I didn't see coming

Twilio expects a response almost immediately. My "wait 2 minutes" step meant it never got one in time.

The fix wasn't shortening the wait. It was answering Twilio right away and doing the wait-and-verify separately, in the background.

Four more things I learned the hard way

Read the whole sheet vs. a filtered lookup

At first, I pulled every row from the sheet on every check, which made the workflow slow. Querying by phone number made it faster and actually correct.

Accidental double-texting

The workflow didn't check whether someone had been texted recently, so the same person could get two "sorry we missed your call" texts four minutes apart. Adding a 30-minute check fixed it.

The webhook secret

At first, anyone who found the URL could hit it. Now every request has to prove it knows the password, so a stranger who found the link gets nothing.

Logging what didn't happen

I only had records for calls the workflow acted on. If a number was blocked or had been texted recently, there was no trace of it. Now every skip is logged too, so "nothing happened" is something I can check instead of assume.

Where the AI stops and a human starts

When someone shows real booking intent, like asking about availability or saying they're ready, the owner is pinged directly with the details already summarised. I set a clear rule for where the AI's job ends and a human's begins.

The demo isn't the test

None of this showed up in the demo. It showed up when I tested against real, messy human behaviour: someone hanging up mid-ring, someone texting twice, someone poking at the webhook URL out of curiosity.

Automation is easy to build and easy to demo. Making it trustworthy is a different job entirely.