I'm currently playing around with the "silenceTimeoutSeconds" parameter to see if it's able to solve the problem, but we have voice agents deployed in the field at the moment, it keeps leaving unwanted VM's though. I'm trying to understand exactly what prompts the agent to initiate the first message that we've designated. I'm not a developer so to me it seems to be a blackbox after a call request is sent to VAPI via Make. We use GHL for reference. Would love to understand this at a deeper level to make sure, hopefully every single call that lands in VM's, our agent just stays silent and hangs up. Any insights?

@george.l Absolutely, I'd be happy to provide some insights into how the "silenceTimeoutSeconds" parameter works and how it might be affecting your voice agents. The "silenceTimeoutSeconds" parameter is designed to control how long the voice agent waits in silence before ending the call. If this is set too high, the agent might wait on the line during a voicemail prompt, which could result in unwanted voicemail messages. If it's set too low, the agent might hang up too quickly before the user has a chance to speak. When a call is initiated, the voice agent typically waits for a trigger to start its designated message. This trigger could be a specific sound, silence after a greeting, or a cue from the call control logic. If your agents are leaving messages on voicemail, it might be because they are not correctly detecting the end of the voicemail greeting. To prevent your agents from leaving messages on voicemails, you could: 1. Adjust the "silenceTimeoutSeconds" to a lower value so that the agent hangs up quicker if it detects silence, which is often what happens after a voicemail greeting. 2. Implement logic to detect voicemail tones or greetings and hang up immediately. Since you're using GHL (I'm assuming you mean GoHighLevel), you might need to coordinate with your developers to adjust these settings or implement the necessary logic. It's important to find a balance that avoids hanging up on actual users while also not leaving unwanted messages. If you need to adjust the "silenceTimeoutSeconds" parameter, you would typically do this through the API or the platform's settings where you configure your voice agent. If you're not sure how to do this, or if you need more specific guidance, please ask support for more info on this. Would you like to proceed with adjusting the "silenceTimeoutSeconds" parameter or explore other solutions to prevent voicemail messages?

I'm a bit confused, for this context of how we're using the agents, which is to call actual leads that have opted into ads, in what scenario could the silenceTimeoutSeconds be so little that it can hang up on leads? Like if it's like 3 seconds for example, and in mid conversation, then 3 seconds after the lead stops speaking, the agent with that configuration would then hang up? If that's the case, while I'm playing around with the silenceTimeoutSeconds, I'm planning on playing it between 20 - 30 second range. I just don't currently understand exactly how things work as far as it seems that the agent would treat "silence" before lead pick up or after lead pick up as all the same it seems. So then theoretically, if there's a number of seconds whereby from there, all VM's begin to play, let's call it 32 sec in this example, if we set the timeout to be 30 seconds, we should never have our agents reach VM's correct? I guess then in that case, what we're solving for is when users obviously are at the phone, and if they press "decline" after let's say two rings or something, which for the agent, would still be encountering voice after like 5 seconds (it would still lead to a VM obviously), so thereby the silenceTimeoutSeconds can't be a solution in these edge cases. So essentially what we're getting at is we can use silenceTimeoutSeconds to rule out the "passive" declines of phone calls by the users that leads to VM's but it won't be able to account for "active" declines aka user just deciding to hang up after X many rings. Is that it? I've seen responses in other threads where things like fine-tuning a model or diving into code can seem to help tighten up a solution for this. Am I on the right track here?

Hey @george.l can you enable twilio voice mail for your assistant and they try? FYI: if you don't se the voicemail messages then voicemail calls we end as customer-ended-call.

@Shubham Bajaj can you add this to the docs somewhere? It worked for me.

Super helpful dude, gonna have a developer on our team to see if we can do this but I think this'll do it. I appreciate it. Side note @Vapi I highly recommend having this added as a toggle/feature for the GUI for non-developers. Anyone who uses Vapi for outbound calls will need this. E.g. anyone that has GHL.

@george.l I'm glad to hear that the solution seems promising for your needs! It's great that you're considering involving a developer to implement the voicemail detection settings. This should indeed help in differentiating between actual leads and voicemail systems, thus preventing unwanted voicemail messages. Regarding your suggestion to add this as a toggle or feature in the GUI for non-developers, I completely understand how beneficial that would be. User-friendly features like this can significantly enhance the experience for those who aren't as comfortable with code. While I can't make changes to the GUI or the documentation myself, your feedback is valuable, and I would recommend passing this suggestion on to the VAPI development team or the customer support team. They are always looking for ways to improve the product and make it more accessible to all users. If you need any further assistance or have more questions as you work on this with your developer, feel free to reach out. Good luck with your implementation!

can you create new a support ticket for adding docs "detecting voice mail using twilio".

umm sure - I can try

Also @Shubham Bajaj is there best practices for configuring this as well? We use make.com, but can it be done natively on vapi? Curious

It's done natively on Vapi using API even through make. As of now we don't have best practies around make automation workflows but we will add it soon.