In the case study entitled "Call-out Service Without Morons" we have already described in brief the automatic process of allocating orders to executing personnel. As this process is vital to every business, let us delve a bit deeper.
It’s more than worthwhile, dear service colleagues. But here is a small remark to begin with.

Those interested in automating their service business usually formulate this task as the automation of the incoming and outgoing message flow. They seek a "CRM solution" which is no solution at all.
And, moreover, CANNOT be one.
CRM functionality is both needed and important. However, CRM is just the beginning; this is only about receiving and recording a client’s application. The business cycle ends as we receive the satisfied client’s money after his order is fulfilled (or, in a statistically significant percentage of cases, after a warranty claim is handled well).
?And what is in-between?
That is the question.

So the most interesting part begins after the operator accepts the request and hangs up. As for the organization of business processes, it doesn’t take an expert to accept a request. It takes an expert to fulfil it
well, cost-effectively and on time.

In mediocre companies, the efficiency of the order distribution process is at the height of the "yawning summits". The call operators have to look for executing personnel by themselves, i.e. contact each specialist and inquire about their workload. Their answers cannot be 100% reliable, for they are also given by humans. Then they must call back and tell the client when the "specialist" is going to visit them.
If the client is not satisfied with the date and time suggested, the process restarts, while new clients call and they all "need it" "here and now", at best "tomorrow". The resultant distribution system is a little more than fully predictable.

An early product of this "kitchen-table" scheme is the appearance of "favourite children", soon followed by full-scale in-house corruption.
The business process mutates constantly and spontaneously to reconcile the interests of all the participants in the business scheme. Of course,all but your clients and shareholders.

But so much for this.

And what happens in an ADVANCED company? That is, in the bowels of a happy entity operating dia$par.
For clarity we shall use the example of business processes in i-Zet, a subsidiary of Interzet — a major St.Petersburg Internet provider (with hundreds of thousands of clients) — that specializes in on-site PC maintenance and has been operating dia$par for a number of years.
After the operator fills in an application form and chooses the planned visit’s date and time from the vacant resources calendar, nothing more is wanted of him; there is no need to call, agree, and persuade the local stars.

The orders are distributed by dia$par without human participation. And here’s how. Proceeding from the visit date and time promised to the client, the system will obtain a list of the specialists whose skills match the client’s task and who will be free at that time. iZet distinguishes between such competences as hardware, software, iPhone, Macintosh, *nix-servers, win-servers, LAN and printer maintenance.

Then the following service engineers are excluded from their set selected:

• those who keep amounts of clients" money exceeding the established limit (see the details –here);
• those with uncleared warranty claims. This motivates them directly to:
  a) prevent warranty claims by working well from the outset, and
  b) handle them first, if any.
  As the service personnel receive no money for clearing warranty claims (as they appeared at their own fault), warranty claims would never be handled in the absence of this restriction.
• those with a backlog of orders exceeding a preset limit. This motivates them to work quicker and not (as in the case of the above-mentioned mediocre companies) to tamper the telephone operators so that
  they drop them more lucrative orders — and then pile them up them like hamsters, while clients get angrier and angrier with protracted repairs.

The service personnel thus short-listed are then sorted by rating (an integral index that usually includes the client satisfaction percentage and the percentage of warranty claims on their works done; this logic can be as complex as need be).

The order is first offered to the top-rating personnel; simultaneously, messages are sent (push messages to the Door-to-Door Android mobile client or good old SMS messages — depending on the personnel’s equipment and on the availability of mobile Internet in the region), informing them of the visit date and time and the address (excluding the flat number).

If the order is not taken up within ten minutes, it is mailed in successive iterations to lower and lower-rating groups of specialists. The service engineer who picks up the order will now be sent detailed information (in the same way, via the mobile client or SMS). What, where and, again, when.
At the same time, the client receives a life-affirming message of greetings, saying that his/her order is confirmed and they can wait for an engineer and have no slightest doubt.

Such a mini Order Exchange; you snooze, you lose.
Note that the above distribution logic is based on the specific example of an individual business, while the diversity of the selection and rating algorithm implementations is only limited by the business process architect’s fantasy.

And, more importantly, all those selections and ratings, however verbosely described, are computed by dia$par in real time, i.e. within a fraction of a second, so while the call centre operator fills in the order’s
parameters, they are all read into the time schedule / vacant resources calendar, and the operator cannot, by definition, promise the client something that the company can provide with the resources available.

An inquisitive reader might inquire: " — And why don’t you send the engineers all the order’s details at once? Why all this two-level red tape?".
A topical question, dear friends! Like the lines of the Field Service Manual are written with blood, these seeming complications are dictated by experience.
The availability of complete information on all the outstanding orders made it possible to pick out the lucrative ones first.

That is, terminologically, the "queuing" model required would turn into a "supermarket" model. The engineers would take the easiest and most lucrative orders first and delay the others. But such behaviour was absolutely rational and thus predictable. After the information on the unsorted orders was restricted, the queue distribution process became psychologically similar to blind betting at cards. According to their service engineers, it became far more interesting and thrilling. Preference players will understand. The actual model became closer to the target one, the "queue".

If no one picks up an order at all (quite an exceptional case), only then will the operator need to assign the order manually. Again, no phone calls are needed, for everything is done within the system. The service engineer charged with the task will receive a notification. So the operators (in the distribution process) only have to handle exceptions; in the normal course of events, their participation is not needed, while there are just 4% of exceptional cases occurring in this scheme. Incidentally, all those 4% could be entrusted to the computer by setting up the system to appoint service personnel using a set of criteria.

And now the order’s doomsday comes (of course, this is not applicable to urgent orders: that must be executed in a matter of hours).
Using his mobile client (or his personal space in the Web interface), the travelling specialist looks through the list of his today’s orders (and future ones if he wishes) and goes on home visits like a doctor.

Pay attention: no ape-like sponging figure is inserted between order reception and execution.
With a certain skill level, one can exclude humans on reception, too, and wholly entrust this function to dia$par using a website, SMS gateway, or IRV), but in reality this is only an option for some (not all) purely B2B companies.

After arriving at the client’s place, the engineer reports back to the "headquarters" (again via the mobile client or by a special SMS message), thus informing dia$par that he is there and working. If no signal comes on time, dia$par will notify the operator of the emergency and the need to contact the engineer ("Where are you (beep)?) and to comfort the client ("The previous client had serious problems that required an urgent solution, so our engineer is being late, but he will reach you in just twenty minutes. We are sorry for the delay.")

Work, work, work.
In the process, the engineer can use the Web interface (or, again, the mobile client) to check whether the required spare parts are in stock and reserve them.
Work, work, work.

The work is over, and the client is happy. (Happy? i-Zet clients say yes with their money. And why not, if all the processes are permeated with motivation logic that pushes inefficient personnel out and to the employment agency).
The service engineer makes out the payment documents for the client and enters them into dia$par.
The mobile client based on Door-to-Door offers the option of connecting a mobile cash register to the travelling salesman’s smartphone; pure gravy, with all documents printed automatically and no need to complete anything by hand. But not everyone will find it convenient to carry an additional device that also costs a square sum of money.

In the absence of a cash register, high-security forms are used. Those forms bearing serial numbers are registered with the tax inspectorate. None may be lost; spoiled ones are written off under a signed act, and each is accounted for in writing to the tax inspectorate. And it is hardly a pleasant experience to visit them too often.

At the office, each service engineer receives a batch of such forms for future use, and their number range is recorded in dia$par. As he makes out the client’s payment documents, the engineer indicates the number of the form used. The data on the order fulfilled that he enters will form the client’s debt in dia$par. After receiving the client’s money and, again, entering this information in the system, the service engineer will extinguish the client’s debt, and the cash received will then constitute his own debt for which the service engineer will account to the main cash desk.
And, incidentally, why only cash. If our customer company is ready to pay its bank an extra commission for mobile acquiring (all this technology has been tested on actual prototype of dia$par), its travelling salesmen will be additionally equipped with the required devices and will be able to accept bank cards as they visit clients.

Those interested in financial matters may refer to "The Trip of Kesha the Parrot" to see what happens to cash afterwards.