Email notification for Queue call lost (Finding a way to exclude/identify Overflow vs terminated)

Mark_ACA

Premier Customer
Joined
Feb 5, 2024
Messages
20
Reaction score
9
We use this email notification which goes to a parser to open up a "New Business Enquiry" on our CRM if we lose a call from a Queue, it works quite well.

However we have 2 call Queues for this line, a focused call queue which is the first one that rings for our new enquiries number, but that is limited to 15 seconds, then it fails to an Overflow call queue with more staff in it to take the call if the caller has been waiting over 15 seconds.
The problem is when a call moves to the overflow queue, the first queue considers it lost and sends the email which sets up the CRM case. we don't want a case unless we weren't able to answer the call (the caller gave up waiting or got disconnected).

I wondered is there a field I can put in this email template to tell us what happened to the call (Terminated by XXX, Transferred to XXX), so our parser knows if it should open a new case for us or not.
Or even just the amount of time the caller was waiting when it was lost, because if its exactly 15 seconds then it was likely transferred to overflow.

I experimented adding in variables found in other email templates but they all came through as blank.

Or a different way to trigger this email using a call flow based on if the call got answered by an agent or not? I cant seem to find a way because once the call is passed to the Queue the call flow has finished with it.

Short term I have had to add more users to the focused group and stop it overflowing so we only use 1 queue which is far from ideal.
 

Attachments

  • Capture.PNG
    Capture.PNG
    25.3 KB · Views: 5
I read this and suspected so.
So does anyone have a suggestion for my situation. Allow an overflow group but only trigger an email (or webhook or other event to setup a case) if we fully lose the call, and not if the system transfers the call to the overflow queue?
 
How about this...

1. Configure 3CX to create a separate Call Detail Record (CDR) file for each call
2. Create a service that includes a FileSystemWatcher to detect when a new CDR file is created
3. When 3CX creates a new CDR file, parse the file data to identify whether the call was never answered
4. If never answered, update the CRM

There are other more complicated ways of accomplishing the same thing, but the above may be the least complicated way. We can help if needed.
 
  • Like
Reactions: Mark_ACA
How about this...

1. Configure 3CX to create a separate Call Detail Record (CDR) file for each call
2. Create a service that includes a FileSystemWatcher to detect when a new CDR file is created
3. When 3CX creates a new CDR file, parse the file data to identify whether the call was never answered
4. If never answered, update the CRM

There are other more complicated ways of accomplishing the same thing, but the above may be the least complicated way. We can help if needed.
Thanks, I have never done anything with CDR's, so its time to start reading and learning :)
 

Forum statistics

Threads
111,961
Messages
589,945
Members
164,862
Latest member
ARTipsadmin