When we use idle messages like the examples in the documentation, we have a final assistant hook that looks like this: { "hooks": [ { "on": "customer.speech.timeout", "options": { "timeoutSeconds": 30, "triggerMaxCount": 3, "triggerResetMode": "onUserSpeech" }, "do": [ { "type": "say", "exact": "I'll be ending the call now, please feel free to call back at any time." }, { "type": "tool", "tool": { "type": "endCall" } } ] } ] } The issue is that the endedReason on the end of call report says that it was just

assistant-ended-call

rather than

silence-timed-out

or something else that indicates why the assistant ended the call. Trying to figure out a way around this.

Hi Noah Johnson, To configure the idle messages feature for handling customer speech timeouts effectively, you can follow these steps outlined in the [Idle Messages documentation](https://docs.vapi.ai/assistants/idle-messages): 1. **Configuration**: Use Assistant Hooks and the

customer.speech.timeout

hook to handle periods of silence:

typescript
   import { VapiClient } from "@vapi-ai/server-sdk";
   
   const client = new VapiClient({ token: process.env.VAPI_API_KEY });
   
   await client.assistants.create({
     name: "Support Assistant",
     hooks: [
       {
         on: "customer.speech.timeout",
         options: {
           timeoutSeconds: 10,
           triggerMaxCount: 3,
           triggerResetMode: "onUserSpeech"
         },
         do: [
           {
             type: "say",
             exact: [
               "Are you still there?",
               "Can I help you with anything else?",
               "I'm here whenever you're ready to continue."
             ]
           }
         ],
         name: "idle_message_check"
       }
     ]
   });

2. **Timeout and Triggering**: - `timeoutSeconds`: Set this to how long you want to wait before triggering an idle message. Can be between 1-1000 seconds. - `triggerMaxCount`: Maximum times the hook triggers per call. - `triggerResetMode`: Choose whether the trigger count resets when the user speaks (

onUserSpeech

) or never. 3. **Best Practices**: - Use concise and encouraging messages. - For support calls, a timeout of 10-20 seconds is recommended. These settings help re-engage users who might be distracted or experiencing audio delays, effectively reducing call abandonment during silent periods. Adjusting the timeout and trigger settings based on your scenario can further optimize user engagement.

We do that, but then the end of conversation endedReason is that the assistant ended the call, not that it was a customer timeout which messes with our alerting

Helo, the common assistant-related ended reasons that you could potentially use: Some appropriate ended reasons for assistant-initiated call ends include: - `assistant-ended-call`: For general call ending - `assistant-ended-call-after-message-spoken`: When ending after a specific message - `assistant-ended-call-with-hangup-task`: When using a hangup task - `assistant-forwarded-call`: For transfers These reasons will appear in the end-of-call report under the

endedReason

field However, note that most call ending should be handled through the assistant's actions or configurations rather than directly setting the end reason, as these are typically result codes rather than input parameters.

We are seeing the

asssitant-ended-call

even when using the

{ "type": "tool", "tool": { "type": "endCall" } }

tool. Shouldn't that show

assistant-ended-call-with-hangup-task

?

We will look into this and get back to you shortly

Thank you!

We apologize for the delay in responses lately. We are in process of making some changes to our workflow in how we handle support requests. The good news is that we are starting to get back on track of having a 48 hour response time and we would like to start cleaning up anything old. With that being said, just wanted to check in with you to see if you have made any progress or changes to your project since support has last reached out.

We are still running into this.