Sometimes there are some SfB reported issues, involve understanding the human factor behind the logs. This case went throw several weekly episodes.
Episode One – The ‘issue’
Our customers SfB has a Contact Center integrated and one day he received a complain from an external associated partner that sometimes they received calls from the Agents and when the pickup the cal….l they were talking with a person from the national emergency services (Switzerland has several emergency numbers an in this case it was the Police).
The first step to be able to know where to search on the logs is to ask for reported situations: when (dates and times), who started (numbers), what happened next?. It was not easy since day one, because it involved at least 2 different calls (one inbound and another outbound), But I managed to identify the flow:
A client calls the SfB/CC number (1), an Agent picks the call (2), he calls the Partner support number (3) and he transfers the call of the client to that partner (4). Except that sometimes, the Agent of that partner instead of hearing the client get surprise by ‘Police ! what is your emergency?’
Episode 2 – Analyzing the facts and recreating the exact steps
The outermost challenge was to track the client call, which Agent picked the call and what did he do next to reach the Partner and transfer. Looking at the logs of several calls made to the partner number, I noticed that some Agents were using DTMF tones.
The Partner number is a Contact Center with an IVR! So now we have a more detailed call flow:
A client calls the SfB/CC number (1), an Agent picks the call (2), he calls the Partner number, goes throw the IVR (3) an Call Center Agent picks the call (4) and the customer Agent transfer the call (5) . Except that sometimes, the Agent of that partner instead of hearing the client get surprise by ‘Police ! what is your emergency?’
Time to include the Partner telephony provider for some potential issue on their side. But after some tests calls there was nothing on the call history the involved calling the authorities and the only active call was coming from our SfB Agent number. The other clue was that the Police that picked the calls is not from the same region as the partner but from our Customer. So the call is definitely triggered from SfB or our operator.
Episode 3 – The clue and the primary suspect
Looking now at the log history of all calls made to that IVR number, one call (that did not triggered the issue) caught my attention on the DTMF pattern. It was typing: 1,1,2. And 112 on a dialpad is…. the well-know emergency number!
Went back to the customer and the Partner and they confirmed that the affected Agents belong to a service that are behind the IVR menu: by dialing the IVR, listen the options and choose 1, then the sub-option 1 and finally the final option 2. There were no reported issues on other queues reached by other IVR menus.
Now we got a primary suspect: What if this DTMF ‘112’ sequence is triggering a call to the emergency services? but how does this is ‘accidentally’ transferred to them?
Episode 4 – Eliminating the suspects
There was still a loose end to clear out. The ‘DTMF 112’ theory issue could have two sources:
– The Customers Agent that we see on the previous logs.
– We noticed that some Agents will transfer the call to the Client before the IVR, and then you will only see the Client call trying to use DTMF.
Time to define a precise script of call testings to identify the one that is causing this mess. Using the minimum amount of variables (same client number to call, same customer agents queues, same partner IVR number:
1. Just to prove the theory: Calls to other IVR options 1,0 or 2,0 all working
2. If the agent transfer the Client that the IVR, we noticed that DTMF over this SfB call transfer doesn’t work (the IVR didn’t recognized the options): this one is excluded
3. Several call transfers using IVR menus 112 were also working until one particular agent call ended on the emergency services.
Time to look deeper to these last call logs and compare them. Nothing looked different, DTMF was ok, except… for the ones that worked, I could find the Client call transfer to the Partner, but the not for the mistery one.
So what happened? The answer involved looking back at all the calls on that time frame (this is a large company with a lot of calls….). And then one peculiar outbound call appear on the SBC log:
– from:<Partner IVR number>
– to :+41112 (+41 is the country prefix of Switzerland)
– referred-by: <Agent number>
Gotcha! the SfB client caused the call. But why and how?
Final episode 5 – The ‘crime scene’ and the perpetrator
We are still waiting for the ‘confession’ but, just by using a SfB Client we can present our delegations using any SfB Client:
- The customer Agent receives a call from the client and click on ‘Consult’
- The Client call is put on hold. A transfer window will appear were the Agent can search for internal contacts or type the Partner IVR number and click ‘Consult
- A new call window will appear. The Agent has now 2 calls on his SfB: the customer on hold (on the left) and and active call the the Partner IVR. The Agent might not notice this because SfB will open the second call window in exactly in front of the one that is on hold
- The agent is now navigating throw the DTMF voice system and picks (type): the options 1,1 and 2 that start appearing on the dialpad text (A)
- To transfer the IVR call to the CLient he needs to click on the transfer call on the top right side of the call window (B) >> if you press this one, SfB will transfer the call of the Client to IVR active call and both windows will close
- If he clicks on the ‘Transfer’ button above the dial pad, it will initiate a transfer of the IVR call to another new number (C)
But it will still show the Search window with the numbers that were typed during the DTMF.
You can clearly see the 112 as the default selected number. If he presses ‘Transfer’ now it will transfer the IVR call to the … Emergency service (112).
- The IVR call window will close but the Client call window will still there on hold (because there was not transfer to him). But the Agent unaware of his mistake, hangs up the customer call
End of episode:
Disclaimer: no servers or software were harmed or fixed during this investigation