Just finished improving Ɔboafoɔ, my AI voice sales assistant built with n8n

The first version worked, but I wanted to push it closer to a production-ready system.

This week I focused on reliability:

  • Added an error workflow using n8n Error Trigger
  • Logged failed executions into Supabase
  • Added Telegram alerts for workflow failures
  • Configured retry handling for external services
  • Cleaned up the workflow structure and documentation

One thing I’m learning while building AI automations:

A workflow that works once is only the beginning.

Real-world automations need to handle:

  • failed APIs
  • missing data
  • unexpected errors
  • recovery paths

The goal is not just connecting nodes. It’s building systems businesses can trust.

Built with:

  • n8n
  • ElevenLabs Conversational AI
  • Supabase
  • Google Sheets
  • Google Calendar
  • Telegram

Looking forward to learning from the n8n community — what reliability patterns do you always include in your production workflows?

1st photo is the first version.

1 Like

I’d add to the reliability list: idempotency checks before writes (to avoid duplicate Calendar/Sheets entries on retry). How are you handling partial failures mid-call with ElevenLabs? Is there a fallback path if the voice API drops mid-conversation?

1 Like

Great points. I agree idempotency checks are important for production, especially before write operations like Calendar and CRM updates.

Currently, I’ve implemented error handling, Supabase logging, Telegram alerts, and retry handling. I haven’t added a full idempotency layer yet, but the next step is storing unique lead/event IDs so retries don’t create duplicate records.

For ElevenLabs failures, the current prototype assumes a successful handoff to n8n. A production version would need conversation state tracking, partial data storage, and a fallback path for failed voice sessions.

Thanks for highlighting this.