dia$par includes
Integrated means that all the contact centre operations are performed directly in dia$par not in an external piece of software.
An operator plunged into the single info space and able to work directly with information needed for the conversation needs no extra time to open and/or toggle among spreadsheets, various databases and other software, etc.; all the required information is displayed on one screen.
Changes are made and data are updated right in the operator’s contact window.
Full-featured means that the CRM functionality of dia$par covers positively every need of the target audience.
Imagine that your business runs a number of business lines that differ widely, e.g. expensive on-site computer repairs, cheap repairs of home appliances and night-time delivery of restaurant food. A number of websites, a phone pool, and travelling personnel. How can we organize the efficient operation of a call centre in this situation?
The overheads of this "kitchen-table" scheme of operating the call centre are easy to imagine. Different telephones, tons of "tabs’/’bookmarks’/’sheets" etc., and a loose array of information that requires vigilance and concentration on the operator’s part.
What do we have in dia$par?
When a call comes in, the call centre operator reads on his/her computer screen which business line the caller belongs to, how to greet them, and which tone and mood ("want some relaxation, gentlemen?") to keep.
Visibly displayed are the business line’s sets of services, prices, and the obligations to be announced to the client. The operator needs neither to keep anything in his head nor even to identify the business line on his own; dia$par does it all automatically after a short setup procedure.
However sophisticated the logic may be, the operator who has been idle longer than others is selected. If a client calls again, then dia$par will route the call to the operator whom the caller contacted last, because client satisfaction is of paramount importance to a service company. The reader will probably remember more than one case where, due to a lost connection or other stochastic events, he or she had to explain their case again to a fresh person on the other end — incidentally, often to get a different result.
An i-Zet example: imagine a typical call to a computer assistance company (a non-typical one, as we’ll see later). As soon as the operator picks up and the caller’s number is checked against the database, the screen will display a form with all the information available on the client: name, where he lives, call history, status of his active orders, balance (if any, and if the operator is authorized to check it). It also shows the price list and the set of services for this client depending on the business line and, say, the client category.
All is handy, and NOTHING should be opened in addition.
And if the caller’s number is not found in the database, then a pre-filled form opens that the operator will replenish with info as he talks.
Incidentally, the caller may be using his other number (e.g. the office one); no problem, the client’s two cards will be merged into one, and next time... so you understand.
Depending on the type of the client’s call (or business line), the operator will ask the client questions from a pre-determined template. The templates can be freely configured to reflect the specifics; from classical questions like "Did you try to turn it off and on again?", "How do you know about us?", to more specific ones, like: "Will you plaster the jambs by yourself?"
These data can eventually support a useful analysis.
As he configures the request (fills in the answers), the operator keeps an eye on the schedule of available resources that displays the free time of travelling engineers of the required specialty (in the case of i-Zet).
So it is easy to project date and time of their arrival.
There is no need to wait for anything, check with the operator/engineers for the resources available and/or call the client again; the free time schedule is always on screen. After arranging the desired date and time of the visit with the client, the operator saves the order, and that is all.
That is, really "all"; nothing else is required of the operator.
The further order distribution operations are performed automatically by dia$par.
And, ideally, no operator is needed. You can receive orders via the website or IVR and teach your customers to self-serve. This approach is great for discounters and other businesses working in the "cheap and cheerful"
format.
The single call centre serves both the incoming and outgoing call traffic. Applications from the website and e-mail from clients that require callback are easily integrated into this task flow.
Nothing will be lost.
And if your business is built on outgoing (call and sell) contacts, then the procedure is quite similar to that described for incoming calls. Rather than incoming calls, distributed are the outgoing call assignments → whom to call next. The analysis and motivation make it possible to prepare and track employees" individual call plans.
The API (application programme interface) can connect to an unlimited diversity of external event generators, e.g. external developers’/suppliers" call centres — retaining all their functionality.
Now let us discuss the results.
Previously, i-Zet operators could NOT cope with the incoming call flow very well, with all the entailments. Growth was out of question.
And six month after dia$par was adopted:
the number of operators decreased by 35%, while
the number of orders grew nine-fold (300+ orders a day)
This case deals with the results directly related to the work of just one unit, namely the call centre.
Let us rack our brains and imagine the combination of circumstances that would let us achieve similar results using Excel.
?Have any idea?
