Track the calls entering into the call centre through a particular Inbound number

Hey All,

Just posting this query to find an easy way to deal this as well as share our approach on the problem.

Background: Customer owns 100+ inbound numbers and they are configured on different scenarios. We are using item.to functionality to capture the number users are calling and based on that, routing them to a particular place based on dialled number.

Problem statement: we want to count/track the number of calls coming through each dialled number and display on our custom wallboard solution. There is no item.to or a similar functionality in the stat APIs So we are looking for some cleaver advice around this. Note: We are not after historic record and only want to know how many calls came so far and should be able to reset/delete to start afresh next day etc. Also, assigning it to a service is not the solution either as services are overwritten as they progress the scenario plus will screw the stats if I apply some cleaver ways.

Status so far: We have been able to achieve it using own custom APIs with Fetch URL block to commit the data into an AWS database/table of ours; we can use Lambda too but its costs are unpredictable (and have not used it so far). This solutions works but the cost of management of API/DB is high. So any suggestions?

Cheers
Jugal

In the past we used Google Analytics for this. Just pull their pixel URL with additional parameters.
Not sure how it would work with the recent Analytics API, but I bet there is a way to coerce it - and let us know if it works, please!

H Jugal,
You should be able to do this using the native Dial-In, custom parameters and custom reporting fields.
For each inbound number you want to track you create a Scenario Entry > Dial-In object that points at your preferred scenario. In that scenario, you have a Set Variable action that creates a variable named “Indial” or something. That variable gets assigned a value of “$(app.custom.indial)”. Then in your flow you also write that variable to your custom reporting field. Back in your Dial-In objects, you should now see the app.custom.indial parameter to set. The indial should then be recorded in the Bright Pattern reporting db for you to pull out and use as you like.

@Jovi How many unique numbers are we talking about here? I have an idea, but it depends on the volume of phone numbers.

Hello,

I think you are on the right track. In your entry write it out to a DB with whatever information you want. At the end of the use a work flow to ‘close’ the record. Your custom realtime app could pull the data based on a startTime and no endtime. Calculate time in progress from now() - startTime. I would use the DB connect block though and a MYSQL DB on AWS or other accessible location.

Roger

Hello @Andy_Foskett , It is a really good solution and will work when you have one number per scenario and you get the stats using this but it is not possible to do that with number ranging from 5-20 per scenario with 7 main scenarios. This will tied up the ‘dialin’ number/s with a ‘single’ custom scenario parameter which will give you the stats per ‘scenario’ but not per number. Correct me if I am wrong.

I have the working solution now and will mark you in the response for your reference.
cheers
Jugal

Hello @Derek , I have 100+ numbers and I am sure they will increase as user base grow for this customer and they explore more and more BP functionalities.

Cheers
Jugal

Thanks for responding. That is too many numbers for the idea I had in mind. The display would have looked terrible at that volume of rows. Good luck in your search for a solution.

Hello @rogerm,
Yes, we have achieved it the same way as you have envisioned but with a tweak to capture the call directly at the item.to exit point in the scenario and create an entry in our database directly. This is to avoid extra overhead of us shooting the API and reading it from somewhere, committing it back and then processing it. We created location codes corresponding to every location/exit and are able to do the maths on top to extract the desired result and display on our custom wallboard solution. Also, we tailored the system to handover the calculation to the browser (client side) instead of us taking that load on the server.
Here is the snapshot of how it looks:

@Derek @Andy_Foskett @Neil.Austin
Cheers
Jugal

Hi Jugal,
I was thinking of this to support as many numbers per scenario as you like.
in the scenarios:
For each scenario where you want to track the number used to reach it, add a Set Variable action that sets “Indial” = $(app.custom.indial). Then a St Custom Reporting Field action that sets custom_X = $(Indial).
For the dial in entries:
Create a dial in entry for each inbound phone number. Associate the number with the desired scenario and set the value of app.custom.indial to the phone number.
E.g. Dial in A is set up as Scenario = Main_IVR, app.custom.indial = 61290000001. Dial in B is set up as Scenario = Main_IVR, app.custom.indail = 61290000002.
This way you can report on the total calls that his Main_IVR AND you can report individually on how many of them got their via 61290000001 vs 61290000002.
I have 170 numbers flowing into a single common scenario and use this method to report on each number as its own virtual line/scenario.

1 Like

Hi @Andy_Foskett , You are a legend mate! Good to know that it is working for you and does seems like a clean solution. Will give it a try but got two questions on this:

  1. We have a restriction of only 20-25 custom fields in the system? How u r doing it for every number then? Or Am I missing something?
  2. You are using BP reporting to extract this data and is historic? My requirement is to show it in near real time (we got 10 sec refresh period) and that too on big screen using our custom BP wallboard solution.

Cheers
Jugal

Yeah, so it’s just the one custom reporting field. In my case I’m using custom_1 and then in my reporting query I’m renaming it (E.g. call_detail.custom_1 as whatever_i_like).

Yeah, I’m doing more historical stuff. The reporting DB is up to date as of 10-15 mins ago, which is perfectly fine for “day so far” type reporting. If you’re looking for actual real-time stats for interactions that are in progress, then API calls are the only way.

Good luck with it.

1 Like

Thanks Andy, I have a working solution using our own APIs added into the flow but will surely give a go to your proposed solution. Thanks.

That looks pretty nice!