Skip to content
Notifications
Clear all

Walkthrough: Using the API to auto-generate voicemails from Salesforce leads.

6 Posts
6 Users
0 Reactions
2 Views
(@kevinp)
Active Member
Joined: 1 week ago
Posts: 9
Topic starter   [#9668]

I’ve been testing WellSaid for a small project. We wanted to automatically create short voicemail-style intros for new Salesforce leads.

My flow is: when a lead hits a certain status, a Zapier webhook triggers a Python script. This script pulls the lead's name and company from Salesforce, formats a short script, and calls the WellSaid API to generate the voice file. The file gets saved back to the lead’s record.

The main challenge was getting the voice parameters right via the API. The docs are good, but I had to experiment to keep the tone natural for a quick voicemail. I ended using a specific voice ID and adjusting the speed slightly.

Has anyone else built something similar? I’m curious about handling longer scripts or batching jobs. Also, any tips on cost tracking for a setup like this would be helpful.



   
Quote
(@diego_h)
Reputable Member
Joined: 4 months ago
Posts: 122
 

That's a smart use case. I'm looking at a similar integration for follow-up calls.

> I had to experiment to keep the tone natural

This is my big worry too. Did you find one voice ID that worked well across different lead names/companies, or do you think you'd need to switch it up based on the industry or something?

On cost tracking, I'm planning to tag each API request in our logging with the Salesforce lead ID. That way we can sum costs per lead or campaign later. Not sure if WellSaid's billing API gives that granularity, but tagging on our side seems straightforward.


Still learning.


   
ReplyQuote
(@devops_dad_joke)
Estimable Member
Joined: 4 months ago
Posts: 104
 

Love the Zapier-to-Python flow, that's a solid glue for prototypes. On batching, if volume picks up, you'll want to flip that script around: collect leads for a period, then send a batch job to WellSaid's API. Their async endpoints are your friend here, otherwise you're just waiting on HTTP calls.

For cost tracking, tag everything with the lead ID like user45 said, but also log character counts per request. It's easy to miss a script length bug that blows your bill. I've seen a stray newline double the characters 😬

Which voice ID worked for you? I found the 'friendly professional' ones get robotic if the company name has weird pronunciation. Sometimes I add a pronunciation dictionary snippet via API for tricky terms.



   
ReplyQuote
(@jamesk)
Estimable Member
Joined: 1 week ago
Posts: 80
 

Great point about logging character counts - that's saved my budget more than once. I've set up a simple script to strip extra whitespace and count before sending, and it catches a lot of those newline gremlins.

On the voice ID, I settled on 'NOVA' for a consistent friendly-but-neutral tone. You're right about weird pronunciation though. For tricky company names, I've started maintaining a small lookup table that appends a phonetic spelling to the script via the API's `pronunciation_dictionary` field. It's a bit manual but works for our repeat offenders.

Batching with async endpoints is the way to go once you scale. I'd add a queue (like Redis) to decouple the lead collection from the API calls - keeps things snappy for the user.



   
ReplyQuote
(@emilya)
Estimable Member
Joined: 1 week ago
Posts: 75
 

NOVA's a solid pick, it's my default for sales outreach too. The pronunciation dictionary is a lifesaver but becomes a scaling issue.

We hit that lookup table problem around 500 leads a month. Automated it by running new company names through a local TTS engine first and flagging any with low confidence scores for manual review. Cuts manual entries by about 70%.

Queues are non-negotiable. We use RabbitMQ, but same principle as Redis. Make sure your queue monitors depth. If it starts backing up, your batch jobs are failing silently.


Prove it with a benchmark.


   
ReplyQuote
(@annaw)
Estimable Member
Joined: 1 week ago
Posts: 96
 

That's a genius workaround with the local TTS engine for confidence scoring. We were heading down a similar rabbit hole with manual entries and it was becoming unsustainable.

A caveat on queue monitoring - we learned the hard way that you also need to watch for a *shrinking* queue depth when your worker count scales automatically. It can hide the fact that your jobs are being processed too fast and hitting API rate limits, which just fails the calls and depletes your retries.

What local engine did you use for the pronunciation check? I'm wondering about accuracy trade-offs.



   
ReplyQuote