WO2006099905A1

WO2006099905A1 - Dynamic on-demand workload balanced system

Info

Publication number: WO2006099905A1
Application number: PCT/EP2005/056293
Authority: WO
Inventors: Stefan Behl; Volker Juergensen; Stefan Liesche; Andreas Nauerz
Original assignee: International Business Machines Corporation
Priority date: 2005-03-23
Filing date: 2005-11-29
Publication date: 2006-09-28

Abstract

The present invention relates to networked computing, and in particular to a method for dispatching multiple real-time communication channels -B- to multiple incoming communication requests- A. In order to provide a request dispatch method, which at least reduces an imbalance at the target side B, it is proposed to perform the steps of: a) measuring the current incoming workload for each channel of a respective target partner B, b) maintaining a personal profile on each of said plurality of communication requesting users A, c) maintaining a personal profile on each of said plurality of target partners B, d) determining for an incoming request one or more target partners B, by a personal profile evaluation of both personal profiles, e) determining for an incoming request one or more target partners B, by a workload evaluation of the current workload of a target partner, f) dispatching the requested communication channels according to a predetermined weighting of both of said evaluations.

Description

D E S C R I P T I O N

Dynamic On-Demand Workload Balanced System

1. BACKGROUND OF THE INVENTION

1.1. FIELD OF THE INVENTION

The present invention relates to networked computing, and in particular to a method for dispatching multiple real-time communication channels to multiple incoming communication requests .

1.2. DESCRIPTION AND DISADVANTAGES OF PRIOR ART

Above-mentioned prior art dispatching is implemented in today's real-time communication tools. The communication channels in question often offer mail-based communication. An example is an "Instant-Messaging" (IM) tool, sold as the product "Sametime" offered by Lotus. This tool is increasingly used by enterprises for implementing a software solution which provides for a quick and easy communication within teams . Such software usually has a client and a respective server side functionality. Other types of communication, for example voice-based or video-based types are planned to be included into such tools.

However, not only enterprise-internal communication but also publicly available web applications increasingly use this kind of communication: in web application environments there is often a need for interaction between persons involved in the web application's context. For example in a Portal environment the users - after they have successfully logged in - might want to interact with other users, or, in a WebShop application the customers might want to interact with other customers or with employees of the Webshop looking help relating to products .

A prior art system overview is given in figure 1. A web server 10 receives and processes communication requests 15 sent by a plurality of communication requestors 12, denotes as Al ..A8. A portion of the software provided by server 10 is dedicated to dispatch the incoming requests 15 to a plurality of communication partners 14, denoted Bl.. B8. Typically, there are far more requestors 12 than partners 14, for example 100 times more.

Often - as a state-of-the-art solution - a context-sensitive list of contact persons is provided to a web user, enabling him to interact with one of the persons on that list. This interaction often starts by the use of above-mentioned instant-messaging tool.

An example of how such a list of potential target communication partners 14 (i.e., the receivers of such requests) is displayed to a requesting user, is given in figure 2. Exemplarily, eight partners 14 are available and depicted with respective nick names as a column of names accompanied with a respective numbers of currently open communication contacts, i.e. the number of currently existing "requestor" 12 web users, who have marked to wish to communicate with a respective desired target partner, in brackets behind. The schema in figure 2 illustrates the development of such situation over time from left to right. When operation starts, all partners 14 begin with zero contacts . A problem involved therein is that such contact lists are implemented to be "static" in the sense that all logged-in users see the same list of contact persons offered for selection. The list coincidence includes the persons as well as each person's individual placement in the list. As a result of statistical evaluations, a typical user tends to chose the person on the top of the list when requesting help or initiating an interaction. This may be motivated psychologically according to the principle "the most competent person will probably be on top of the list...".

This leads to the problem that in the course of such instant messaging tool's runtime, the person on top of the list (Kermit the frog) is confronted with a relative high workload. Further, the more a person 14 is located bottom-most in the list, the lower is his workload, see "Rizzo", and "The animal". Thus, the workload is highly unbalanced amongst the list members. This leads in the end to a response time, which gets increasingly worse, and to increasing latency in the system.

1.3. OBJECTIVES OF THE INVENTION

It is thus an objective of the present invention to provide a request dispatch method, which at least reduces this imbalance .

2. SUMMARY AND ADVANTAGES OF THE INVENTION

This objective of the invention is achieved by the features stated in enclosed independent claims . Further advantageous arrangements and embodiments of the invention are set forth in the respective subclaims . Reference should now be made to the appended claims

According to the basic aspect of the present invention a method and respective system for dispatching communication channels to communication requesting users in a networked environment is disclosed, comprising a first plurality of said communication requesting users requesting one of said communication channels to one of a second plurality of communication target partners, wherein the method is characterized by the steps of: a) measuring the current incoming workload for each channel of a respective target partner, b) maintaining a personal profile on each of said plurality of communication requesting users, c) maintaining a personal profile on each of said plurality of target partners, d) determining for an incoming request one or more target partners, by a personal profile evaluation of both personal profiles, e) determining for an incoming request one or more target partners, by a workload evaluation of the current workload of a target partner, f) dispatching the requested communication channels according to a predetermined weighting of both of said evaluations .

Further, the majority of the first and the second plurality of communication partners may also be identical. This is the case in Intranets of enterprises or in Internet chat rooms, where basically every person may initiate a communication to every other person.

Thus, according to the present invention the request dispatch logic is implemented at the communication server and includes a system component called "workload analyzer" continuously measuring and maintaining information about existing connections to the communication partners 14. The modifications of the client part software can be neglected except minor details described later below.

Further, according to a preferred feature of the invention useful user data telling about user preferences is stored within a further system component called user-preference analyzer .

Further, a system component called "competence analyzer" is used upon new requests .

Contact lists, or in general, the way of providing means to initiate interaction with other persons are performed based on various metrics which might include workload balancing, skill coincidence and user preferences .

The metrics may also reflect and help to select the appropiate communication channel - offer e-mail for "low profile" users, while Instant Messaging, a phone call or even a personal visit could be offered to "high profile" users, for instance like executives within a company - they will get a higher level of service compared to other employees .

According to one alternative of the invention a contact list could e.g. be replaced by a general "Request help" button. The system has then to determine the contact with the least workload and initiate the interaction correspondingly. Of course, this solution supports multi-channel interaction, which means that the communication channel chosen for the interaction might be instant-messaging, a (VoIP) phone call, a video conference etc. Moreover, the inventional solution does not depend on any device-specifics - so, it can be used from within a webbrowser on a PC, as well as on any other device (PDA, cell phone) for which the inventional analyzer components are available.

Further advantageously, the system can give a feedback to the interaction requestor if no contact person is currently available. It may display a "ticket-like" number which is counting down in realtime, so that the requestor can decide whether to wait until it's his turn or it would be better to try again later. Another modification is to let the list itself appear sorted by workload, the smallest workload on top of the list. The list displays the contacts sorted in realtime and a connection to the server system is maintained and the list changes dynamically in time.

Stickiness to a desired target partner is another aspect bringing-in an inventional advantage -at least from the view point of the requestor. An interaction-requestor might want to talk to a particular person he has talked (e.g., days etc.) before. The system stores to whom the current requestor usually talks and initiates preferably an interaction with this person, as long this is compliant to other needs - be that on behalf of the server system due to essential workload balance reasons or on behalf of the requestor, due to urgency reasons involved in his request.

All these approaches can be combined in a meaningful manner.

Note that the "system" the requestor wants to interact with, needs not necessarily to be a human being as described throughout the samples below. Also a bot or any agent would be valid, too. 3. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and is not limited by the shape of the figures of the drawings in which :

Figure 1 is a schematic overview block diagram of a prior art system for dispatching multiple real-time communication channels to multiple incoming communication requests,

Figure 2 is a scheme of lists of target persons with respective indications of currently open communication contacts, developing in time from left to right,

Figure 3 is a schematic overview block diagram of an inventional system for dispatching multiple real-time communication channels to multiple incoming communication requests,

Figure 4 is a schematic system block diagram illustrating the software components provided for the functionality of the analyzer 30 in Figure 3,

Figure 5 is a schematic system block diagram illustrating data used by the three essential core software components provided for the analyzer 30,

Figure 5 is a schematic workflow diagram illustrating a general architectural overview on a preferred embodiment of an inventional method using a dynamic sorting of contact lists before displaying them to a requesting user,

Figure 6 is a schematic workflow diagram illustrating a general architectural overview on a preferred embodiment of an inventional method modification which involves the analysis of workload, staff competence, and user preferences,

Figure 7 is a schematic workflow diagram illustrating an alternative to figure 6, in its end portion,

Figure 8 is a scheme of lists according to figure 2, as achievable according to the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With general reference to the figures and with special reference now to figure 3 a particular embodiment of the invention will be described next, which is implemented in a web server application of a help-line provided via the Internet. In this exemplary web application it is assumed that the help-requesting users can select a target partner from a list of available target partners, as mentioned above in the introductory chapter. When the requesting user clicks a name from the list, the working queue for this target partner is increased by one contact.

A web application server 20 is provided with a plurality of inventional software components comprised of a block 30, denoted as "Analyzer". The analyzer is connected to the communication layer of the incoming requests 15 as well as to the communication channels (17) to be dispatched. Further, a connection to a client database and to a staff database is provided. All connections are operable by a respective software interface implemented in analyzer 30.

Details of the analyzer block 30 are given with reference to figure 4 next below.

The inventional analyzer block 30 comprises a workload meter 42. This workload meter measures the depth of the working queue on a logical level for each of the target partners 14, denoted as Bl, .. BM. It returns an ID for the target person and a number describing the number of requesting persons 12, who momentarily wait for a contact with a respective target person, to a so-called "dispatch manager logic" 44. This logic controls the total of subfunctions needed to perform an intelligent dispatching of communications.

The measuring procedure is repeated in an adequate frequency, i.e., in a helpline where a contact is done by telephone (e.g., Voice over IP), this might be one (1) measurement per minute. Measurement data is stored in memory of the web server hardware .

Further, a history database 46 is maintained where for each of the plurality of clients, i.e., the requesting users 12, the IDs of every helpline target partner is stored with which a contact was already established before. This means a mapping of one or more target partners B to a given requesting user A is performed. A maximum length is pre-defined for the number of target partners in each entry for a user Al, .. AN. This history database is fed with data freshly coming from the workload meter 42.

If a contact between user A and a target person B has successfully provided and has completed, the respective waiting time queue is decreased by this user A, and the history database 46 is updated by adding B to the entry for the respective client A, as it is depicted in figure 4 with Al-> B5, B3, etc.. An entry for a user A can take up to 16 target person IDs. When this limit is reached, the oldest addition is replaced by the new one.

Further, a staff database 48 is operatively connected to the inventional dispatch manager logic 44. This database holds for each of the staff members, i.e., the target persons B (14) a plurality of entries :

Entry 1 is the personal ID, entries 2 to 10 hold skill and experience information, e.g., by defining an ID for each technical field, e.g., Fl, .. FN , and a respective qualifier for each field ranging from 0 (no skill, no experience, to 10 (adequate skill, multiple years of experience) .

A further attribute can be mapped to a target person which qualifies other competence attitudes like the degree of executive duty competence (e.g., beginner, junior, senior, and top senior) .

A further attribute may be maintained comprising a feedback rating input by the user after having completed a communication, e.g. 0 = very good, 3 = average, 6 = very bad.

A further entry can be provided which takes the value of the current workload, i.e., the queue depth value.

Further entries may comprise hobbies, or other characteristic properties of a person.

Further, a client database 48 is operatively connected to the inventional dispatch manager logic 44. This client database holds for each of the requesting clients 12 amongst others the basic data like name, addresses, and optionally and preferably data like:

Age, gender, total amount of money paid for goods or services in the last two years (also intervals are possible like < 500 €, < 1000 € < 5000 €, > 5000 €) , number of years to be client, preferred target partner, optionally hobbies, or other characteristic properties of a person.

The basic inventional function of server 20 is to dispatch the incoming requests of persons A to communication channels associated each with on of the target partners 18 (B) by applying an "intelligent" algorithm which consists of different independent algorithmic components which can be combined arbitrarily; their results can be combined into a final result (see Fig. 2) . The decision to which potential receiver (B) a requestor (A) is dispatched is performed by this inventional dispatching logic 44 with the following functions of software components, as depicted in figure 5 and an exemplary control flow as depicted in figure 6:

First a client A3 is assumed to make a request for a particular communication channel, say to target person B3, in step 610. Then the inventional dispatching module 44 is invoked in step 620.

One of above-mentioned components thereof is called "Competence analyzer" 52. This algorithm is started in step 630. Note that the algorithm could also be started with a different module. The sequence can be varied widely.

Basic input elements of competence analyzer 52 are depicted in figure 5, relating exemplarily to requestor A3, and target persons B3 and B7.

In this example requestor A3 is assessed to be a "good" client, as he spent more than 4000 USD in a given actual time period. His fields of interests are specified as F7 and F8.

It should be noted that a general aim of this competence analyzer algorithm is to dispatch ,,good" requestors (e.g. customers) to ,,good" receivers (e.g. employees); good requestors might be ,,long" customers, that have spent a lot of money etc., whereas good target partners might be long-time, experienced employees having good feedback ratings so far and being skilled and experienced in the technical fields F7 and F8 .

Another aim is to offer at least to good clients a more flexible way to get connected to a good target partner. That's why an additional "in-hurry" field can be clicked by clients A for YES or NO. If YES, than the evaluation automatically weights higher a target partner, having a short current waiting time involved. Similarly, an "emergency" field can be clicked by a requestor, which even increases such weights.

The inventional algorithm compares the personal profile of a requestor to all profiles of the potential target partners;

A lookup 632 for those interest fields in the staff database may serve to yield target partners B3 and B7, which are selected for a "good client" as they both have at least 5 years of helpline experience (see the since-field) . In this exemplary workflow this is done independently of the client's A3 choice for B3. In variations thereof, A3's choice can be weighted higher for the dispatching decision.

In presence of above-mentioned plurality of criteria stored in said databases 48, 49 a weighting function of these criteria is predetermined and stored in system memory. By this weighting function the best match between requestor and target person can be defined in an objective manner. A set of weighting factors and rules can be adapted to the needs of any- specific application, where the invention is implemented. Here, for example, practical experiences are weighted higher by the system than the more theoretical skills, e.g., in a 70%, 30% ratio.

Thus, the competence analyzer may lead to a partial result "PRl" to select target partner B3 for requestor A3. Bl and B2 may assumed to be junior staff, not primarily to be connectable to "good clients" like A3. Exceptions thereof would be for example very urgent requests, i.e. "emergency cases" .

A further inventional component is called "Workload analyzer" 56. It is operatively connected to the workload meter 42 (see figure 4) and reads the current queue depth values for each target partner B in step 642. It holds a map about all currently opened connections for each target partner B. By that the waiting queue depth is traced over all target partners and is updated frequently. Thus, the partial result "PR2" of the workload analyzer is a current version of the workload map comprising either all or the subset of the target partners preselected by the competence analyzer in PRl .

A further component is called "User-preference analyzer" 54. It is invoked in a step 650. It holds a map about personal preferences a requestor might have; in the example above requestor A3 ,,likes" to talk to B3; this might be the case when A3 has often talked to B3 in the past, for example. Thus, analyzer 54 looks up the client database 48 in step 652, where the preferred target partners for A3 is stored.

Further, in this context, also a high weight can be spent to a target person, who has got a good feedback rating by a particular requestor, e.g., by A3, or a good average feedback rating by other requestors, an information which is preferably only made visible to "good clients" in order to avoid a "run" to those "very good" target partners triggered by new clients .

Thus, the user preference analyzer 54 may lead to a partial result "PR3" to select also target partner B3 for requestor A3.

As may be seen from the description above, all analyzer components 52, 54 and 56 are input with the relevant personal data from the client database 48 and staff database 49, and with the measured workload data. Each of the partial analyzers ends up with a partial evaluation result PRl, PR2, PR3.

Depending of each individual implementation in a respective individual applicational field of the inventional method, a subsequent, higher level, general evaluation 660 takes a particular primary criterion as the most important entry point for an improved dispatching decision.

Consider a technical hotline, it makes sense to chose highest possible coincidence in the technical field as an adequate entry point.

The above determined partial results are now evaluated in a step 660 by a higher level part of the inventional evaluation algorithm, for example with the technical field highly scored as follows :

The required coincidence of the technical field filters the total of target partners to a rest of say, Bl, B2, B3, and B7 as a partial result PRl of the competence analyzer. The partial result PRl of the competence analyzer proposes to select B3, followed by B7, Bl, B2.

In this exemplary implementation the value of the "in-hurry" field is evaluated in step 662. The value "YES" leads to a relatively high weight of the partial workload result: In the example of figure 5 the queue for being connected with target partner B3 is currently of a length "9", which means that 9 requestors A desire to speak with B3. Assume an average time of 2 minutes for a call in the B3 communication channel, this means that A3 must wait about 18 minutes until he might be connected to A3. B7 however, will probably be free to be connected much earlier as his queue depth length is only 2. Thus, B7 is preferred over B3.

Then it is checked, if the "emergency " field is clicked. If so, B2 would be selected directly as this target person is currently immediately available, as his queue depth is 0 (figure 5) . Here, however, no emergency case is present.

Then, the partial result of the preference analyzer ("Take first B3") is evaluated and weights are given as follows:

20% for user preference,

60% for "in-hurry" and

20% for system-reserved workload optimization purposes. This is a provision preserved for the queue management system, to

"overrule" the requestor-owned possibilities to influence the dispatching decision. This may be very useful, if the queue depths are too less balanced.

This general evaluation leads to a final result "R" to select finally the target partner B7 for requestor A3.

This final result "R" is used to perform the dispatching of the communication channel to "B7" in step 670 for the incoming request of A3.

Optionally, this control flow can be modified as shown in figure 7. If an interaction (i.e. a switch through to B7) is immediately possible the dispatching to B7 is performed and the communication channel between A3 and B7 is switched active. Otherwise a "tickef'-message is output telling to the requestor the current queue length of his desired channel. Then the inventional dispatching algorithm (step 620) is re- invoked in step 664. This ends up in step 660 with a new final result R. According to the new result R the requestor's queue position is updated and re-displayed to him, step 665. Then a last decision 666 is taken if or if not the requestor is progressed so far to be ready to be switched through to B7. If not a branch back to step 664 follows, if Yes, a branch to the dispatching step 670.

As a person skilled in the art may appreciate, the inventional algorithm comprises different algorithmic components 52, 54, 56, basically independent from each other at the first glance. Thus, it may make sense to adapt the inventional method to a given situation by selecting either one or to combine two or all three of them. The above-mentioned psychological background to the selection of potential target partners, however, leads to a inter-dependency between workload and skill/ sympathy qualities of a target person. The negative workload effects brought into the system by such positive feedback closed-loop effect between workload and skill / sympathy can now be handled better than in prior art.

The following variations might be useful:

The final dispatch evaluation result may be also weighted to find a well adapted overall dispatch result directly from the partial results without defining a well adapted criterion as entry point or any other intermediate filter; for example, the result of the workload analyzer might be weigthed 50%, the user-preference analyzer 30% and the competence analyzer 20%.

In addition to what has been stated in above, the following modifications 1) to 3) of the inventional method are proposed:

D

1. The end-user sees a "Request button" at his browser.

2. Upon click of the button the workload for all potential target persons to interact with is determined.

3. If no person is available to interact with - due to too high workload - the system will display a ticket number - otherwise continues with step 6.

4. The ticket number counts down in realtime.

5. When the requestor is on turn, the scenario proceeds with step 6.

6. The interaction is initiated via the chosen communication channel .

2)

There could be an alternative button allowing to trigger an interaction with the contact person the requestor usually or preferably talks to (see 1), step 2) .

In this case, the system would fall back to scenario "I) " in case that this person is under heavy workload or not available .

The so called contact list is a system component holding a permanent connection to a server system and allows to determine and display the workload for contact persons in real-time to requesting persons .

1. The contact list is built up displaying all potential target persons .

2. The requestor sees the "contact list" and selects a target person therefrom.

3. The workload is recalculated.

4. The list dynamically resorts (in realtime), and the target person with the least workload is displayed at the top.

5. A requestor can always choose the person displayed at the top and may trust in that this is the one best available for him. Or, he may pick a special person motivated by his personal preferences) .

Figure 8 shows a sequence of contact lists according to figure 2, but improved by the invention. As it reveals from the right part of it, the target persons having low workload are displayed topmost in the list and are selected statistically more frequently than those persons at the bottom of the list. The dynamic recalculation and resorted display of the list thus provides for a balanced workload.

Obviously all these approaches can be combined in a meaningful manner:

Upon the requestors request to initiate an interaction the system could first try to initiate an interaction with the users preferred contact (via a preferred communication channel) - this reflects the ,,stickiness" aspect.

If this contact is not available or under too heavy workload, the system may fall back to the other mechanism mentioned above and initiate an interaction to another target person currently available.

Or, according to figure 7, if no target person is currently available at all, the system can issue a ,,ticket number" to the requestor and inform him about his position in the queue. The system will display the current position in realtime and initiate the interaction as soon as the user is on turn.

The following aspects may also be involved with the inventional method:

• Names of persons do not need to be visible at any time (even for the "stickiness" aspect the system can "store" the information about a user's preferences) . This can prevent users from deciding whom to chose on their own which can lead to the fact that some contacts are preferred against others .

• Of course, this solution may be implemented to support multi-channel interaction, which means that the communication channel chosen for the interaction might be instant-messaging, a (VoIP) phone call, a video conference etc.

• The inventional method does not depend on any device- specifics - so it can be used from within a webbrowser on a PC, as well as from any other device like PDA, cell phones, etc ..

The present invention can be realized in hardware, software, or a combination of hardware and software. A tool according to the present invention can be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems . Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.

The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which - when loaded in a computer system - is able to carry out these methods .

Computer program means or computer program in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a) conversion to another language, code or notation; b) reproduction in a different material form.

Claims

C L A I M S

1. A method for dispatching communication channels (17) to communication requesting users (12) in a networked environment comprising a first plurality of said communication requesting users (12) requesting one of said communication channel (17) to one of a second plurality of communication target partners (14) , characterized by the steps of: a) measuring (642) the current incoming workload for each channel (17) of a respective target partner (14), b) maintaining a personal profile on each of said plurality of communication requesting users (12), c) maintaining a personal profile on each of said plurality of target partners (14), d) determining for an incoming request (15) one or more target partners (14), by a personal profile evaluation (630, 650) of both personal profiles, e) determining for an incoming request (15) one or more target partners (14), by a workload evaluation (640) of the current workload of a target partner, f) dispatching (670) the requested communication channels (17) according to a predetermined weighting (660) of both of said evaluations.

2. The method according to claim 1, further comprising the step of a) maintaining a history about communications completed by each of said target partners (14), and b) displaying a target partner list to a requesting user (12) for target partner selection purposes, which comprises the target partners having the smallest number of contacts top most in said list.

3. The method according to claim 1, wherein the majority of the first (12) and the second plurality (14) of communication partners is identical.

4. The method according to claim 1, wherein the personal profile of the first plurality of requesting users (12) comprises skill demand information, and the personal profile of the second plurality of target partners (14) comprises skill information.

5. The method according to claim 1, further comprising the step of giving (663) a feedback to a requestor comprising waiting time information until a connection will be established to a desired communication partner.

6. A computer system used for dispatching communication channels (17) to communication requesting users (12) in a networked environment comprising a first plurality of said communication requesting users (12) requesting one of said communication channel (17) to one of a second plurality of communication target partners (14) , said computer system being characterized by: a) means (42) for measuring (642) the current incoming workload for each channel (17) of a respective target partner (14) , b) database means (48) for maintaining a personal profile on each of said plurality of communication requesting users (12), c) database means (49) for maintaining a personal profile on each of said plurality of target partners ( 14 ) , d) a functional component (44) for determining for an incoming request (15) one or more target partners (14), by a personal profile evaluation (630, 650) of both personal profiles, and for e) determining for an incoming request (15) one or more target partners (14), by a workload evaluation (640) of the current workload of a target partner, and for f) dispatching (670) the requested communication channels (17) according to a predetermined weighting (660) of both of said evaluations.

7. A computer program for execution in a data processing system for dispatching communication channels (17) to communication requesting users (12) in a networked environment comprising a first plurality of said communication requesting users (12) requesting one of said communication channel (17) to one of a second plurality of communication target partners (14) , characterized by programmed logic components (42, 44, 48, 49) for performing the steps of: a) measuring (642) the current incoming workload for each channel (17) of a respective target partner (14), b) maintaining a personal profile on each of said plurality of communication requesting users (12), c) maintaining a personal profile on each of said plurality of target partners (14), d) determining for an incoming request (15) one or more target partners (14), by a personal profile evaluation (630, 650) of both personal profiles, e) determining for an incoming request (15) one or more target partners (14), by a workload evaluation (640) of the current workload of a target partner, f) dispatching (670) the requested communication channels (17) according to a predetermined weighting (660) of both of said evaluations, when said computer program code portions are executed on a computer.

8. A computer program product stored on a computer usable medium for execution in a data processing system for dispatching communication channels (17) to communication requesting users (12) in a networked environment comprising a first plurality of said communication requesting users (12) requesting one of said communication channel (17) to one of a second plurality of communication target partners (14) , characterized by programmed logic components (42, 44, 48, 49) for performing the steps of: a) measuring (642) the current incoming workload for each channel (17) of a respective target partner (14), b) maintaining a personal profile on each of said plurality of communication requesting users (12), c) maintaining a personal profile on each of said plurality of target partners (14), d) determining for an incoming request (15) one or more target partners (14), by a personal profile evaluation (630, 650) of both personal profiles, e) determining for an incoming request (15) one or more target partners (14), by a workload evaluation (640) of the current workload of a target partner, f) dispatching (670) the requested communication channels (17) according to a predetermined weighting (660) of both of said evaluations, when said programmed logic components (42, 44, 48, 49) are executed on a computer.