I am trying to set up this assistant to recognize the time when a call comes in [Time-Based Behavior]. I don’t want it to continue chatting during certain hours or on weekends (in my use case, transferring the call to the office before/after hours). Is this possible?

So, took some time to patch some stuff to get you more insight, check it out here to get more visibility into your deployment and further insights- Voice mins insights - Added call time in ms, seconds and minutes (2 decimal places) - call end resons, and recording all in the same interface to check call timeframes and what happened Mins - To save voice mins, turn off voicemail - sometimes, from call reviews, we notice the time to listen to and leave a voicemail can be 18 - 60 seconds. May not sound like a lot but if you are making 1000s of calls that adds up End reason - Earlier I had noted that error doesn't always mean error, this patch should give you more insights like and error meaning a call was made but there was no answer / voicemail (couldve been full), you can see those reasons there Outbound not working triage guide - If you aren't able to outbound calls, check voice mins - check the wf action to see if it has an assistant id, check your assistant has a phone number, check call logs - could be: - the contact you called doesn't have a number / bad number (will show in call logs) - significantly negative mins - system rejects call, can be seen in the returned_an_error from the WF action, will not show in call logs because no call was made, tag will also be added to the contact ^^ couple triage steps but ill add a guide and more visibility into that stuff in patches and in new update

How would this be set up, anyone? Thanks

at least it is not showing that the outbound call was successful. Gonna see if the reconnecting to MP will work this time.

Most are aware of multiple provider outages coinciding with the Phase 2.1 update push. The timing is frustrating, but Assistable is working closely with affected providers to monitor the situation and assist wherever possible. What’s is/was Affected: • Inbound/Outbound Calls • Messaging Services • Any system interactions requiring GET requests from GHL (e.g., retrieving contact IDs/info). Advice: I strongly recommend avoiding troubleshooting or resetting systems on your end to prevent complicating the ongoing migrations. These interruptions stem from upstream provider issues and are not directly caused by the update. One of the outages from GHL is directly tied to marketplace app connections. If you're antsy and don't already have this in place... I recommend agency owners set up client communication workflows for service outages. Brand em up (or don't). --- Now... Tough love/perspective from Breyden. I understand how disruptive this is, but I feel inclined to remind you: AI itself is disruptive. You are selling disruption. Welcome to the frontier. The frontier is unpredictable at times, even with the best trailblazers and wagons (pardon my Oregon Trail reference). For example, today, a primary TTS service went down. Fallback systems across the board kicked in but were overwhelmed. GHL’s load balancers—yes, they also rely on voice AI—adjusted to handle their retry load. But compute resources are finite, and drastic adjustments can ripple across services, causing further degradation. Volatility is a guarantee when AI systems play with other AI systems. It's a cost we all pay for the benefits. It will decrease over time, but is going to be present. At the end of the day, "dynamic" and "controlled" are still oxymoronic - they're inherently inversely connected (at least until scalable AGI is available). P.S.) hopefully the perfect storm of all these at once never coincides with an update rollout again. Fantastic timing, right?