As with any business that receives incoming calls, your are then open to the fact you may received call fails.
A key benefit of having call tracking in place is that it highlights any call fails that may of been happening for a while, however as they have never reached your phone system you would be unaware of these altogether. Here at Infinity we are equipped to identify any issues and respond where appropriate.
Common reasons for call fails within the Infinity Portal are:
- Internal phone system issues with the number we are connecting the call through to. This can be due to the phone system rejecting our calls.
- Unanswered calls due to busy periods within the working day, therefore there are not enough call handlers to answer all incoming calls, this can be a good indication of staff shortages.
- Simply the caller hanging up before the call is connected.
To rule out your phone system entirely from the equation, we recommend pulling a call state report from our API. Here is an article which explains Call State Reports in more detail.
If you are experiencing Call Fails within your Portal or unusual call behaviour, the call state report is a good report to start with to attempt to determine the cause of this.
Here are two useful report for you to pull:
Please update XXX with your installation ID (IGRP ID)
You can also add other parameters to suit your needs. Please take a look at our API documentation article if you would like this to be customized to your own style of report.
Once the report has run you will be presented with call states. Here are the most common call states:
||This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time.
||This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.
||This cause indicates that the called party cannot be reached because, although the called party number is in a valid format, it is not currently allocated (assigned) - we get this from our carrier, who in turn get it from BT/upstream telcos
||This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.
||When the caller hangs up before being connected, this is probably because they have been waiting too long. Occasionally this may be due to Post Dial Delay (PDD)
||This cause is used to report a protocol error event only when no other cause in the protocol error class applies. This too may be indicative of an upstream carrier issue or a problem routing calls to the customer, although they do not happen often.
||This is caused when the caller hangs up and is a normal call state
||This is caused when the operator hangs up and it is a normal call state (e.g. The operator rejecting the call before it is being answered on the handset.)
||This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user may wish to try another call attempt almost immediately. The "B" means it is the Bleg of the call that is causing the problem, i.e the leg that is going to the customer's call center, and not the caller.
If there is a call state within your report that has not been listed above, please contact our Support Team