Logical architecture for dynamically handling call-back requests

I'm assuming here that you already know the basics of how "leads" or "contacts" are automatically processed for outbound calls or to assign contact tasks to an agent. If not, you can get a high-level overview of recycling rules and status processing first.

The following diagram illustrates the most important paths that "lead" or "contact" entries take through the processing flows:

Let’s step through it - follow the numbers on the image:

1	In this visualization, your app/code looks up campaign and any other status information from babelforce in order to present whatever options to end-users in web widget in your UI: Can use both queries to babelforce and can receive pushed notifications for real-time updates. All sources of data can be used to make decisions: availability of agents, status of outbound campaigns, list of contacts ready to dial next, stats from queues.
2	You can add or update items on a list from anywhere. In this image, your website presents "request call-back" in any design you wish. Present availability or lack of availability. Present data to capture from user or anything you like.
3	Your website element sends call-back request item to a list of contacts to be called.
4	The call-back requests with expected timing of return and any other attributes will be automatically processed and delivered to the right agent. You can have as many different lists associated with any kind of campaign, dialer behavior, queuing process.
5	Depending on the settings for the particular campaign behavior in use, there are lots of different processes you can create: completely automated call-backs and connection to agent or presentation to agent to make call and any combination of these with any conceivable queuing strategy. Depicted here is the completely automated connection of calls. In the illustrated setup, there are two possible types of occurrence at the point where we try to place the call to the contact who requested it: 5a - Call answered by the end-user and so connected to an agent OR 5b - Call not answered by end-user: busy, no answer, unreachable …
5a	Call answered by the end-user and connected to an agent: The real-time presentation is handled completely in the embeddable app - no need for you to deal with lots of complex real-time handling and call state cases. But you can automatically push the data on each call event to any other system: Zendesk, Salesforce, etc. You can easily create your own endpoint to receive the data also.
5b	Call not answered by end-user: busy, no answer, unreachable … In this case, no agent is involved. The finish reason, e.g. line busy, is updated automatically to the contact in the list. It is precisely this part that saves so much time and effort. Sometimes you can have 50 to 90% of attempted calls not connecting to a contact. It is very inefficient to have agents deal with each of these “dead” attempts.
6	In either case, the processing rules set up for your campaign will decide what to do next with the contact in the list. This will completely automate all the follow ups needed where the contact was not reached and also where the agent submitted a call outcome that the contact would like to be called again.