Can someone please add the purpose of this project ? --Khalid HASSANI 18:13, 22 November 2006 (EST)
- Added a brief purpose, but I believe the project Cli-CE's description should be more of a way to have ADempiere comunicate with external applications (SMS/Phone/email/IM..etc) Sempre 22:05, 22 November 2006 (EST)
- Thanks --Khalid HASSANI 11:08, 23 November 2006 (EST)
The references to a Predictive Dialer are not actually a predictive dialer - this is more a power dialer facility. A predictive dialer pulls phone numbers from a list, calls them automatically, and then connects callers to an operator one a phone is answered by a human. Predictive dialers have poor reputations because usually they are setup too aggressively (i.e. call people when agents are not available - they call you and then put you in a queue!!). It's a pity this enhancement is being done as a commercial project rather than a GPL one, because there is a lot of stuff missing from the requirements of a call centre and it will need to be extended. Allan Howard 21:51, 5 March 2007 (AEST)
Yes, Allan is correct. He defined the predictive dialling function rightly and that is what we understand and like to do but not yet. We only proven the basic call-back from app to phone. As Allan described, such a checklist pulls out from the DB, and that can be done easily in ADempiere as its a matter of event process via SQL query to pull out phone numbers. But they dont have to be aggresive. We can for instance call back those we have not attended to, or requests that have elapsed, or those that their rules specified for call-backs. - Red1 01:50, 4 March 2007 (EST)
SOME THOUGHTS ON CALL CENTRE FUNCTIONALITY Allan Howard 17:25, 7 March 2007 (AEST) If we want to examine a little more of the functionality of a call centre, I can elaborate here (It might be already known for all/some, so I apologise if this is the case but thought at least I should define what I mean to ensure clarity). Red1 is correct in the need for a callback facility .. this is one of a number of facilities that a call centre looks to have.
Essentially we can consider 2 types of call centre campaigns - inbound and outbound. When we are talking more complex issues of load balancing, we run what is called a blended call centre, which mixes both inbound and outbound calls either from a single, or multiple customers/campaigns.
For inbound calls we look to balance the calls between agents via Automatic Call Distribution (ACD) balancing functionality which in it's simplest form is ensuring that there is an even workload between agents. A more complex version of this is called skills based routing, and that recognises that different agents are more or less skilled so places calls based on skillset and experience (this makes it possible to blend together multiple customers to a shared call centre consultant list). An even more complex version of this based on customer preferred queuing, and it actually tries to link a specific caller as a matter of priority to the last agent who spoke to this person (and may even bump others from the queue if a particular customer is deemed to have high priority) to allow more personalised service.
Of course to ensure personalised service we need to ensure that the IT systems are linked to the phone systems in a 2 way link, not just popping the customer records. What we have to watch for is that the same customer may call from different phone number (home, mobile, work, and that sometimes, caller line ID (CLID) may not be available at all in which case we may ask via an IVR for some identification (more advanced facilities will probably exist in the future for voice recognition). Also at some point we may not know a customer's number until such point as they call, and we need to be able to link a unknown caller to an existing customer, or maybe a new customer record if they are legitimately a new caller (extra special attention needs to take place here so that we exclude all possibilities of creating unnecessary duplicate records, after all, we want to capture all details about a customer in a single place) - it's also likely that mistakes will be made, so merging of customer information would help here. Don't forget that sometimes we have multiple customers call from a single number - we need to be able to quickly show a list of possibilities. (It get's complex quickly doesn't it ;-)
If we need to call a customer back at some future point in time, we schedule a future call (to which appropriate number - or a different one!!) at the agreed time.
For outbound calls we look to balance the workload again between campaigns and the number of agents available. Eligible customer details must be loaded into our database (ideally checked and merged so we don't duplicate records) - identified under a specific campaign, and then calls allocated to agents to place
In a number of countries, we also have rules about who we can call and when - e.g. if calling a non-customer, then we have to "wash" the phone number against the public "Do Not Call Register", and also checked against our own internal private "Please do not phone me" register. Want it even more complicated ;-) well because we do outsourced work for multiple customers, we can legitimately call on behalf of one customer, but must wash a phone number for another customer! We even could have a customer declaration (probably a specific voice recording which we must be able to prove) that allows us to call them for a set period of time even though they are on the "Do Not Call list".
For both inbound and outbound calls we may want to call the customer back at a specified agreed time (preferably by the same agent if available, otherwise by other staff). For outbound calls we may just want to reschedule because the person is unavailable (both answered and non-answered calls - let's ignore the fact we might want to leave a message). We also want to be able to play the customer specific information about them via text to speech functionality (e.g. IVR account balance whilst on hold, or recorded reminder from accounts receivable followups). We also want to understand which IVR options customers chose to get to their destination.
So what do we want to do to ensure the consistency of our calls with customers - we want to have agents see a scripting tool - a decision tree, with questions and answers that may link to details about the actual order placed. We want to record all the paths and information collected for statistical analysis (e.g. for surveys or information collection tasks) or for marketing analysis of the paths customers took to place a particular style of order.
We want to be able to divide specific customer interactions into particular marketing campaigns - i.e. which number did a customer call, or which IVR options did they select to choose to response to a particular campaign.
We need to be able to link script outcomes to automated emails, faxes, or order placed (including online payment) to either customer and/or 3rd party on behalf of customer.
We need to be able to record phone call statistics against a customer and need to be able to link to a specific call recording.
We want to be able to do specific call centre reporting - call statistics, labour usage, labour forecasting, customer IVR behaviour as well as link this to actual order or delivery information.
Why is this important if a PABX is handling it all - well because the concepts are the basis by which call centre managers measure their call centre operations. Traditionally call centres have measured their PABX and other activities (e.g. ERP) seperately .. this is a mistake as we need measures that cross the boundaries to understand customer behaviour.
To my knowledge there is no current solution that provides this type of complete customer behaviour type linkage. At this stage, call centres are only just starting to think (not much action yet) about BI type reporting on just the PABX side of things - they aren't yet thinking of linking into the end-customer deliverables.
This is part of my vision of how our IT systems should support our business.