Projects

2021.01.01  /  Internal build, later adapted for client environments

Voicemail Transcription to Ticket

A 3CX Call Flow Designer script that sent voicemail audio to Google Speech-to-Text and opened a ticket with the transcript.

Problem

Voicemails sat in a mailbox until someone listened to them and typed up a ticket by hand.

Stack

3CX

3CX Call Flow Designer

Google Cloud Speech-to-Text

ConnectWise

Outcome

Ran in production for about three years. Voicemails reached the ticket queue as searchable text without anyone listening to them first.

Background

Voicemail is a queue nobody owns. A caller leaves a message, and it stays in a mailbox until a person listens to it, works out what the caller wanted, and opens a ticket. The information is captured the moment the call ends, but it is not usable until someone transcribes it by hand.

The delay is not the listening. It is that nothing exists in the ticketing system until a human has done that work, so the request is invisible to anyone looking at the queue.

What I built

A Call Flow Designer script in 3CX that runs when a voicemail is left:

  1. Call Flow Designer picks up the recorded audio file
  2. The audio is sent to Google Cloud Speech-to-Text
  3. The transcript comes back as text
  4. A ticket is created in ConnectWise with the transcript as its body

The result is that a voicemail becomes a queue item without anyone touching it. The caller’s own words are in the ticket, so whoever picks it up reads what was actually said rather than someone’s summary of it.

02

Voicemail to ticket

Voicemail transcription pipeline, and the step it lacked A caller leaves a voicemail on 3CX. A Call Flow Designer script picks up the recording and sends the audio to Google Cloud Speech-to-Text, which returns a transcript. A ticket is created with that transcript in its body. The chain stops there: the ticket arrived with no category, priority or routing board, and nothing read what the caller had said. That missing step was built three years later as a separate project. 01 Voicemail left 3CX 02 Call Flow Designer picks up the recording 03 Speech-to-Text Google Cloud · audio in, text out 04 Ticket created transcript in the body not built Classification category · priority · routing built later, a separate project
The ticket reached the queue, which was the point. It reached it unclassified, which is the part worth saying: nothing read the caller's words, so a voicemail about a jammed printer looked like every other item until a person opened it.

Why Google

Cloud Speech-to-Text was the mature option: reliable, good with accents and phone-quality audio, and reachable with one API call and one set of credentials. It handled the thing that actually makes voicemail hard, which is that phone audio is narrowband and callers do not enunciate.

The current generation of speech models arrived later and would change this decision today. At the time, picking the established service over something newer was the straightforward call.

What it did not do

The ticket it created was generic. The transcript went into the body, but nothing read it: no category, no priority, no routing, no sense of whether the caller was calm or furious. It reached the queue, which was the point, but it reached the queue as an unclassified item like any other.

I looked at sentiment detection, which Google offered through a separate API. It did not end up in what shipped.

Where it leads

Three years later I built the ticket classification pipeline, which reads a ticket’s description and assigns a category, priority, and board. That is exactly the step this system was missing.

They are not just compatible in principle. Both wrote to ConnectWise, so the transcripts this produced are the same tickets, in the same system, that the classifier later read. A voicemail could have arrived as text, been read, categorised and routed without anyone touching it.

I never connected them, but one of these systems ends exactly where the other starts.

All projects