Build an AI Voicemail Smart Router with Telnyx

Voicemail is easy to ignore.

That is a problem, because the messages that land there are not all the same.

One caller might be asking about an invoice. Another might be reporting that production is down. Another might be a new sales lead. Another might be spam. If all of those messages end up in the same inbox, the important ones wait behind everything else.

This example shows a better pattern: transcribe a voicemail, classify the intent, and route it to the right place automatically.

Code: github.com/team-telnyx/telnyx-code-examples/tree/main/voicemail-smart-router-python

What the app does

The app is a small Flask service with two main ways to process voicemail.

If you already have a transcript, call:

POST /voicemails/transcript

If you have a voicemail audio file, call:

POST /voicemails/process

For audio, the app sends the file to Telnyx Speech-to-Text first. Then it sends the transcript to Telnyx AI Inference and asks for a structured classification.

The model returns:

• category
• confidence
• priority
• reason
• suggested action

The app then maps that classification to a route.

urgent  -> Slack alert
billing -> email
support -> ticket queue
sales   -> CRM lead
spam    -> blocklist + archive
routine -> daily digest

That is the part I like. The AI output is not the end of the workflow. It becomes an operational decision your app can act on.

The architecture

Conceptually, the flow looks like this:

Voicemail audio or transcript
        |
        v
Flask app
        |
        |-- audio -> Telnyx Speech-to-Text
        |
        |-- transcript -> Telnyx AI Inference
        v
Classification + route
        |
        v
Slack, email, ticket queue, CRM, archive, or digest

The audio step calls:

POST /v2/ai/audio/transcriptions

using:

distil-whisper/distil-large-v2

The classification step calls:

POST /v2/ai/chat/completions

The primary model is:

zai-org/GLM-5.2

The fallback model is:

meta-llama/Llama-3.3-70B-Instruct

You configure the app with:

TELNYX_API_KEY=your_telnyx_api_key
AI_MODEL=zai-org/GLM-5.2
FALLBACK_MODEL=meta-llama/Llama-3.3-70B-Instruct
HOST=127.0.0.1

If you want urgent voicemails to send a Slack alert, add:

SLACK_WEBHOOK=https://hooks.slack.com/...

Trying it with a transcript

The fastest demo path is the transcript endpoint:

curl -X POST http://localhost:5000/voicemails/transcript \
  -H "Content-Type: application/json" \
  -d '{
    "transcript": "This is an emergency. Our production system is down and we need help immediately.",
    "caller_number": "+17177247292"
  }'

The response includes the classification and route:

{
  "category": "urgent",
  "confidence": 1.0,
  "priority": "high",
  "reason": "The caller reports a production system outage requiring immediate attention.",
  "suggested_action": "Escalate immediately to the on-call engineering team.",
  "route": "slack",
  "routed_to": "#oncall-alerts",
  "routing_status": "delivered"
}

If no Slack webhook is configured, the app still classifies the voicemail and returns the routing decision. The delivery integration is intentionally simple so the example stays easy to adapt.

Trying it with audio

For voicemail audio, send a file:

curl -X POST http://localhost:5000/voicemails/process \
  -F "file=@voicemail.wav" \
  -F "caller_number=+17177247292"

The app transcribes the voicemail, classifies the transcript, stores the result in memory, and returns the route.

You can also list processed voicemails:

GET /voicemails

Filter by category:

GET /voicemails?category=billing

Or inspect routing decisions:

GET /routes

Why this pattern is useful

Most teams do not need a more beautiful voicemail inbox. They need the right message to reach the right workflow.

Urgent outage reports should not wait for someone to check email.

Billing questions should not go to sales.

Sales leads should not disappear into a generic support queue.

Spam should not take human time at all.

This example uses AI to classify the message, but the useful product pattern is the routing layer around it. The model gives you intent. Your application decides what happens next.

Production considerations

The sample keeps processed voicemails in memory and uses a static routing map.

For production, I would add:

• authentication
• durable storage
• voicemail webhook ingestion
• retry logic for failed deliveries
• real email, ticket, and CRM integrations
• audit logs for classification and routing decisions
• configurable routing rules
• human review for low-confidence messages
• analytics by category, priority, and response time
• PII handling for transcripts before storing or sharing

I would also treat confidence carefully. A high-confidence urgent message can page someone. A low-confidence message might be better routed to a review queue.

Where this fits

This pattern works for:

• after-hours support lines
• sales inquiry routing
• billing voicemail triage
• healthcare intake queues
• legal intake calls
• property management hotlines
• field service dispatch
• internal IT support

The broader idea is simple: voicemail should not be a dead end. With transcription, classification, and routing, it can become structured work.