WO2003017173A1

WO2003017173A1 - Method and apparatus for processing user requests

Info

Publication number: WO2003017173A1
Application number: PCT/US2002/026134
Authority: WO
Inventors: Kwok Hung Chan; Josh Horwich
Original assignee: Epeople, Inc.
Priority date: 2001-08-17
Filing date: 2002-08-16
Publication date: 2003-02-27

Abstract

A service network is presented that provides for the input of user requests (10) and the input of service contract terms (20) (e.g., by the user or from a third-party supplier). A service network platform (50) receives and classifies user requests (51), service contract terms (52), and service provider profiles (53), etc. Once a user request is submitted, the service network platform (50) can apply an appropriate service profile that controls how a third-party service provider is selected and what contract terms will apply to the servicing of the user request by the selected service provider.

Description

METHOD AND APPARATUS FOR PROCESSING USER REQUESTS

Cross-Reference to Related Patent Applications

[001] This patent application claims the benefit of U.S. Provisional Patent Application Serial

No. 60/313,163, entitled "Method and Apparatus for Processing User Requests", filed August

17, 2001.

Background of the Invention

[002] The present invention pertains to a method and apparatus for controlling interaction of

users and service providers over a network. More particularly, the present invention pertains

to the creation and management of a service relationship between a user and a service

provider under the terms of a service contract that may define the conditions under which a

service provider services a user request.

[003] In the computer industry, users rely heavily on computer hardware and the software

that is being executed by the hardware. For example, when a software application is released

to the public, the developer must provide user support when different technical questions,

such as problems with the software application or how-to questions about the software are

raised by the user. Similarly, for system software and computer hardware (including main

computer hardware such as the memory or the disk drive) and computer peripheral hardware

such as a printer, mouse, a keyboard or a scanner, the developer of that system software or

computer must also provide user support to answer the user's technical questions.

[004] The user support of a software application, system software or hardware, however, is very costly and time consuming. For a typical company, the user support of a software

application may be a group of "experts" who listen to the user's technical questions and

complaints and attempt to solve the user's technical questions by following a script of

potential solutions. These experts may include internal or external resources. The cost of

maintaining this group of user support people is enormous. In addition, support people can not

possibly know the answer to every technical question that a user asks and therefore, often end

up with low satisfaction ratings. Often, a single support person cannot answer the question by

themselves, and it is difficult for them to find and communicate with the other experts needed

to collaboratively answer the question. The process may be frustrating to both the user and

the support personnel. In addition, support people cannot possibly remember all of the prior

solutions to the technical questions they see infrequently, and often get bored with repeatedly

answering common technical questions. For a user that has a technical question, the user

often does not know whom to call to resolve the technical question, waits on hold a long time

to get the technical question answered and, even after waiting on hold receives poor or

inaccurate advice. The company that seeks to provide technical support for its products may

contract with third-party service providers so as to avoid hiring its own technical staff.

However, doing so creates additional problems related to control, contract terms, and quality.

[005] It is clear that companies face many technology related challenges, from the rapid

proliferation and adoption of diverse new technologies to recruiting and retaining IT staff, to

managing in-sourced and outsourced services, to supporting a global and diverse workforce.

These companies must ensure that the computer systems, networks and applications they rely upon are efficiently managed and supported by knowledgeable and experienced IT

professionals, external service companies and technology vendors. Such companies may have

made large investments in CRM helpdesk software, but this software may only be able to

route service requests within the boundaries of the company's internal support organization.

In view of the above, there is a need for a system that improves the handling of user requests

for technical support.

Summary of the Invention

[0061 JAccording to an embodiment of the present invention, a service network platform is

provided coupled to users, service providers and service contract providers. This service

network platform may handle the routing of service requests and the delivery of web-based

technical support through an integrated suite of support tools, which match the user request

classifications with the appropriate service contract. More particularly, the service network

platform may be designed to a) define which support entity or entities addresses which type of

requests depending on the products, priority or even the status of the user, b) direct requests to

a higher level of service which might be in their own organization or to a different support

entity, and c) define the quality of the people who can answer the requests, and d) define how

multiple entities collaborate to answer requests that cannot be answered by a single person.

The service network platform also assists the service provider in finding questions they may

know how to solve as well as to give service providers sufficient information to know what

the exact product is that requires service. [007] The service contract terms are the business rules that define the criteria that govern the

service rules attached to the service request. The contract terms may include, for example, a

defined level of qualification that service providers can be qualified for depending on their

performance, skills and certifications, the routing rules that accepts requests and then routes

and reroutes the requests to their appropriate destination and pricing variables. A service

contract may be provided by a network administrator, and may also be provided by service

contract providers (e.g., supplier of the software, hardware or other product that is presumed

will lead to user requests). The contract terms may be stored at the service network platform.

The service providers are to handle user requests according to the contract terms previously

entered. Accordingly, once a user request is entered, depending on the user, the subject matter

of the user request, and other parameters, the user request is matched to one or more sets of

contract terms that control the relationship between an appropriate service provider and the

user in handling the user request.

Brief Description of the Drawings

[008] Fig. 1 is a block diagram of a system for handling user requests constructed according

to an embodiment of the present invention.

[009] Figs. 2a-b are examples of forms for entry of a user request at a user computer.

[010] Fig. 3 is an example of a form for entry of service contract terms by a user.

[011] Figs. 4a-b are an example of a form for entry of a service contract by a supplier or the

like. [012] Fig. 5 is an example of a display that allows a service provider to bid for and service a

user request.

[013] Fig. 6 is a flow diagram for applying a service profile to a user request and service

contracts.

[014] Fig. 7 is a table diagram for classifying a service contract.

[015] Fig. 8 is a table diagram for classifying a service profile.

[016] Figs. 9-11 are table diagrams for selecting an appropriate service profile.

Detailed Description

[017] The present invention will be described with reference to a network system. In one

embodiment, the network system is the Internet, but the present invention can be extended to

other types of network systems including local area networks (LANs), wide area networks

(WANs), Intranets, etc. Broadly, the present invention concerns the submission of service

requests (also referred to herein as "user requests" and "trouble tickets") by users or by

systems on behalf of users; the submission of service provider profiles for individuals who

will potentially provide services to the users to resolve their requests; and the submission of

contract terms by service contract providers that may be used to govern the providing of

services.

[018] Referring to Fig. 1 , a block diagram of a network including a system of the present

invention is shown. In the network system, a plurality of user computer systems may be

provided (e.g., user 10) coupled to the network. In this embodiment of the present invention, a user will send a request (i.e., a user request or trouble ticket) to the service network platform

for servicing.

[019] In this embodiment, user computer systems are general purpose personal computers

including one or more processors to execute instruction code stored in a storage media such as

a hard-disk drive, Compact Disc - Read Only Memory (CD-ROM), or the like. One skilled in

the art will appreciate that the present invention can be expanded to a variety of other

computer systems (e.g., those operating over a local network) or electronic communication

systems (e.g. two-way pagers).

[020] Referring to Fig. 1, one or more user computers 10 (e.g., personal computers coupled

to the Internet) are in communication with a service network platform 50 (e.g., a server

coupled to the Internet). In this example, the user operating user computer 10 may have a

service request that he/she would like resolved through the system of the present invention. In

this embodiment, the user 10 transmits service requests to the service network platform as a

trouble ticket.

[021] Referring to Figs. 2a-b, examples of forms for creating a trouble ticket are presented

according to an embodiment of the present invention. After logging into the service network

platform in any of a variety of known methods, the user may be presented with a welcome

page as shown in Fig. 2a. In this embodiment, the welcome page lists active requests 101 and

past requests 103 that are currently being serviced or have been serviced in the past. In input

area 100, the user can input the category of the service request he/she desires to be resolved.

In this embodiment, those categories include software, hardware, administration, telephone, output, storage, hosting, and others. Though the present invention is described with respect to

handling service requests concerning computer problems, the present invention should not be

so limited.

[022] Once the user selects the category for the service request, an input form for the service

request can be presented such as the one shown in Fig. 2b. In this form, the user may enter a

title for the service request along with a category 107 for the request and the type 109 for the

request. The contents of the entire form (including the pulldown menus) can be customized

based on the category of the service request. The form may also allow the user to enter the

operating system 111 for his/her computer, the version 113 of the operating system, the

amount of random access memory 115 in the user's computer, the user's level of knowledge

117 in the problem area, a description 119 of the service request, the native language 121 of

the user, and the priority 123 of the request. Other information may be made an automatic

part of the user request, such as diagnostic data for the user computer. For example, the type

of processor being used, the software programs loaded on the user computer, etc. can be

determined without user intervention in a known manner and included with the user request to

assist an eventual service provider.

[023] In addition to submitting the service request, the user can also select contract terms for

the payment for servicing the request. Referring to Fig. 3, a form for selecting contract terms

is provided according to an embodiment of the present invention. In this example, the user

can state a price that he/she will pay for resolving the service request (see field 125) or may

request a reverse auction where service providers submit bids to resolve the service request from which the user can choose (see field 127). The reverse auction is discussed in more

detail below. Though not shown here, it may also be possible that the supplier or other

provider has already setup contract terms to handle the servicing of the user request. This

option is also discussed in more detail below.

[024] Referring back to Fig. 1 , the user trouble ticket or service request and the desired

contract terms (see block 15) are submitted to the service network platform 50. This

information can be stored in a trouble ticket database 51. Likewise, a database of available

service contract terms (e.g., those provided by a service provider 30 or network administrator

via Service Network Management 60) may be stored in database 52. As described in further detail below, a database of service providers 53 may be provided as well at the service

network platform.

[025] In addition to the contract terms that are submitted by the user as described above, additional contract terms may be provided by a service contract provider 20. For example, a

supplier of operating system software may desire to allow a particular third-party service

provider (discussed below) to handle service requests from users who have purchased the

operating system software. In such a case, the supplier may want to pay for all or a portion of

the assistance provided by service providers to the users under terms that they so designate.

Referring to Figs. 4a-c, a form for entering service contracts is shown. In Fig. 4a, the service

contract provider can input its name 141 and a description 143 of the service contract. The

service contract provider can also specify a service network 145. A service network is a

collection of business rules that specify service request categories, matching rules, etc. For information purposes, a summary 147 of previously entered service contracts may be

provided. Referring to Fig. 4b, an example for the entry of contract terms is shown. In block

151 , an example of a request classification is given. In this embodiment, the request

classification includes three category levels that describe the subject matter of the service

request. In this example, the category levels include "web browser" and a specific example of

one "Microsoft Internet Explorer." The request classification can also be used to specify the

operating system its version, the programming language, whether the service is to be handled

at the user's locale (i.e., on-site). Other contract settings can be set forth in block 153. In this

example the settings allow the user to see the compensation to be paid to the service provider,

and automatic matching at a final tier timeout. The settings may also include an up-front

charge to be paid by the user and a budgeted cost for all users under these settings.

[026] Tiers define the sequence in which different providers are able to solve requests. There

may be different levels of support that are provided based on inaction on the ticket or the

difficulty level of the problem, with, for example, tier 1 supporting the easiest and tier 3 the

most difficult. If tier 1 is unable to solve the problem, the request could be "handed off' to a

router to route it to the higher tier (e.g., at the request of the service provider). Alternatively,

the request could be re-assigned in tier 1 (e.g., if the service contract disallows the service

provider from transferring the user request to a different tier). An example of routing based

on inaction on the ticket is shown in Fig. 4b. Each tier may have a time out associated with it

and the service contract provider should be able to specify the matching time out period. The

matching timer is restarted every time a request is matched to a service option. A tier may specify multiple service contracts and rules for adding and removing secondary service

providers, enabling multiple service providers to collaborate to solve the user request. When

multiple service contracts are used at a single tier, any of the multiple service contracts may in

turn select tier 1 of another service network, and invoke that network's escalation rules for

that tier. Looking at block 155, a "status" field indicates whether the tier is active. A

"matching model" indicates a set of rules for how a service contract is awarded. In this

example, the user accepts a bid from a service provider. Another example of a matching

model would be one where the user defines the service request and the contract terms and it is

to be serviced by the first qualified service provider that agrees to do so, and that service

provider has the option of adding other secondary service providers to collaborate on solving

the service request. A "pricing scheme" field designates the pricing for the service contract.

In this example, the pricing scheme includes a parameter that the cost for satisfying the user

request will be paid by the service contract provider, that there will be a fixed price for each

service request of $30.00 and that the service contract provider will pay $10.00 of this fee. In

the "provider pool" field, a designation is made as to which service providers can provide

services to satisfy the user request. In this example, the qualified service providers are pooled

together and labeled SM Pooll . In the "response price" field, the amount charged by the

service network platform for matching the user request and the service provider is set ($5.00

in this example). Other fields in block 155 include a bid timer initialization, which specifies

the amount of time that is allowed for a service provider to respond to a user request that fits

into tier 1. For example, a default time of one day may be specified. If no response is received in one day, then the conditions of tier 1 have not been and will not be satisfied, and

the conditions of tier 2 may be checked. There may be a new matching model and pricing

scheme for the service contract of the higher tier. Also in block 155, an answer accept time

initialization can be specified. In this example, the default time is one day. If the response to

a proposed solution is not made within the specified period of time, then the proposed

solution will be automatically accepted. In summary, the bid timer and answer accept fields

allow the service provider to set a time limit when a response needs to be submitted to service

a user request and when a response needs to be accepted by the user. As stated above, if the

terms of tier 1 are not met, then additional tiers (e.g., tier 2, block 157) may be specified by

the service contract provider so as to ensure that the user request will be serviced. In this

example, if no acceptable agreement is made by the service provider (e.g., one who made a

valid bid) and a user (e.g., one who is to accept or "answer" the bid), in the time frame set out

in tier 1, then a second tier may set larger time windows, higher prices for the service contract,

etc.

[027] Referring to Fig. 5, an example of a display that allows a service provider to bid for

and service a user request is shown. In this embodiment, a service provider can log into the

service network platform and all user requests that match his/her qualifications can be

displayed at the service provider's computer system (including user requests from different

service networks that may have different service contract providers). For example, the service

provider can register with the service network platform by indicating his/her technical areas of

expertise (e.g., what software programs he/she is expert in). This may include which software programs the service provider has been "certified" in. Once registered, the service provider's

qualifications can be matched with the subject matter classification for the user request as

entered in the example above. The service provider is given a list of user requests that match

his/her level of expertise. The service provider may select one such user request to find more

details about the request. In providing the user request to the service provider, the service

network platform may also include the proposed contract terms for the service request.

Referring to Fig. 5, an example of a display for a service provider is shown. As discussed

above, there are several options for how these contract terms are specified. In this example,

the user request 161 is displayed to the potential service provider. The user request includes

the user request classifications such as the type of question being asked, the operating system,

etc. Under "description" the text of the user request can be presented. In a reverse auction

transaction, field 163 can be provided for a text message for the user and field 165 can be

provided for the service provider's bid.

[028] The first example is one where the user specifies that he/she will pay a predetermined

monetary amount for a service provider to handle the service request. In the second example,

the service contract provider specifies the contract terms. In these examples, the user's

request will include these stated contract terms. If the service provider is willing to provide

the services to handle a specific user request, he or she can submit a bid to the user giving the

service provider's identity and willingness to agree to the contract terms. In this embodiment,

this becomes a bid for the user to accept or reject. If the user accepts, then a contract is

created by the predetermined terms. The user's request is then serviced by the service provider. In a third example, the user requests bids for servicing the request. As discussed

above with respect to Fig. 5, the service provider can provide contract terms for the user to

agree to. For example, the service provider may state that it is willing to service the request

for a set monetary amount, the user is presented with this bid and can accept or reject the bid.

Alternatively, the service network platform can add a surcharge to the bid (i.e., increase the

bid to be accepted by the user) as a price for providing the service of bringing the service

provider and the user together.

[029] From the forgoing, it can be seen that a system has been described that allows for a

user to enter a user request or trouble ticket, that allows for a service contract provider to

provide contract terms for a contract between the service provider and the user, and that

allows for a service provider to create a contract to service the user's request. The following

provides a more detailed discussion of a system for handling user requests and contract terms

constructed according to an embodiment of the present invention.

[030] In generating a user request, a service profile is generated. The service profiles defines

the mapping between the various classifications of the user request (e.g., category, type,

operating system, etc.) to a service contract. For each service profile it is possible to have

multiple service contracts attached to it. The service profile defines what service contract rules

should be applied to the service request, which may also be based on a classification for the

user (e.g., the user may belong to a group that will be provided service paid for by a service

contract provider). The service profile can also be used to determine if the user is entitled to a

particular service (e.g., has the user registered with the service contract provider to receive services from a qualified service provider paid for by the service contract provider). A

flowchart illustrating the use of a service profile is shown in Fig. 6, in step 201, the user enters

a user request (e.g., using the form shown above in Figs. 2a-b). The user request may be

defined by a number of predefined table fields. These could include the following:

1. A category for the user request (e.g., hardware, software, etc.)

2. A type for the user request (e.g., a request concerning an operating system

under the software category)

3. the operating system for the user ' s computer system

4. The operating system subtype (e.g., the version of the operating system).

[031] Alternatively, the user request can also be defined by the user. Accordingly, the user

can belong to a particular user group (e.g., a group of users whose use of the service network

platform is paid for by a third party, such as a service contract provider). The user may also

be defined by the entity that referred the user to the service network platform. For example, if

the user originally sought help for his/her user request at a first web-site, that web-site may

redirect the user to the service network platform. In this case, the "referrer" is the first web¬

site or the organization that hosts the first web-site. Also, the user may not be affiliated with a

user group of a referrer as described above. Referring back to Fig. 6, in block 203, the user

request is classified as set forth above, for example.

[032] Before a service profile can be applied during service network administration, the

available service contracts are also classified. In this embodiment, each service contract can

be defined by table definitions as shown in Fig. 7. To summarize, a service contract defines the terms under which a service provider services a user request. In particular, the service

contract may include a name, the payment scheme (e.g., open market bidding, fixed price,

etc.), who is paying (e.g., the user, or a service contract provider), the payment method (e.g.,

by credit card, a previously created account, etc.), the matching model (e.g., who decides

which service provider will service the user request), etc. Referring back to Fig. 6, the service

contract is entered in block 205. As stated above, the service contract can be entered by the

service contract provider, by the network administrator for the service network platform, etc.

A service contract entered by the network administrator may be "standard" contracts that may

service as default or commonly used contracts (e.g., a fixed price of $30.00 is to be paid by

credit card by the user and the user request is to be serviced by the first service provider to

accept the request). In block 207, the service contract is classified (e.g., by applying the table

definitions set forth in Fig. 7). With the user request and service contracts classified, a service

profile may be used to control assignment of the service contract to the user request.

[033] Referring to Fig. 8, a table diagram is shown for a service profile. As set forth above,

the service profile can be a set of rules used to match the user request with the generated

service contracts. A variety of service profiles can be created according to the table of Fig. 8.

Referring back to Fig. 6, in block 209, a service profile is selected based on the user request.

For example, a standard service profile may be used where the user offers to pay a preset

monetary amount for servicing the user request by the first available/qualified service

provider. The standard service profile in this case will then take an available service contract

that follows these features of the user request. For example, the service contract in this case would designate the name of the user, that the payment method is "fixed price," that the user

is paying the fixed price, that the user is paying by credit card, that the matching model is

where the user accepts a bid from a service provider offering to service the request for the

fixed price, etc. A customized service profile can be created where a company has provided

the service contract. For example, XYZ Company may have provided a service contract to

control the interaction and compensation between service providers and users having service

requests related to XYZ's products. In such a case, the service profile may be applied when

the user belongs to a specified group and/or the question concerns a particular XYZ product. The resulting contract may then specify that the payment method is fixed price that the service

contract provider (XYZ company in this example) is paying that fee, that the fee is being paid from an existing account, that the matching model is where the user accepts an offer from a

certified service provider (e.g., a service provider who has been certified as an expert in the

product in question), etc.

[034] Referring to the table in Fig. 7, a qualification set can be specified for the service

provider. The qualification set defines what skill set is required for the service provider. It

can specify one or more service provider groups, where each group includes one or more

service providers (e.g., service providers certified by the service contract provider as expert in

its products). The qualification set can also be used to specify certificates to be held by the

service provider as well as a minimum number of service request solved through the service

network platform, and a minimum rating level (e.g., provided by previous users via the

service network platform). [035] In step 211 (Fig. 6), an appropriate service contract is selected based on the service

profile. Referring to Fig. 9, a table defining the rules for determining the service profile is

shown. The table in Fig. 9 is similar to a boolean truth table with the following variables:

"Logged In" Is the user logged in to the service network platform?

"Has Referrer ID" Has the user been directed to the service network platform from

a recognized referrer?

"Has UserlD" Does the user have a UserlD?

"Has GroupID" Is the user part of a predefined group?

This mechanism can be extended to include other variables. If the user is not logged in and

does not have a Referrer ID, then a default standard service profile is used such as the one

described above. If the user has not logged in and has a recognized referrer ID, then memory

can be accessed that is linked to the referrer to specify a service profile for that particular

referrer. If the user has logged in and only has a UserlD, then a service profile may be preset

for this user, otherwise a default or standard service profile may be used. If the user has

logged in and has a ReferrerlD and a UserlD then the service profile is selected based on the

table in Fig. 10. If the user has logged in and has a UserlD and a GroupID, then the service

profile is selected based on the table in Fig. 11. If the user has logged in and has a ReferrerlD,

UserlD and a GroupID, then either the referrerlD is ignored and the table in Fig. 11 is used, or

the GroupID is ignored and the table in Fig. 10 is used.

[036] Referring to Figs. 10 and 11, additional tables for selecting a service profile are shown.

In the table of Fig. 10, the only variables of interest are whether the referrer has a service profile ID and whether the user has a service profile ID. If neither do, then a default standard

service profile is used. If only one is specified, then that ID is used to look up a matching

service profile in memory (e.g., at the service network platform). If both are specified, then

only one should be used (e.g., the referrer ID should be used to select the appropriate service

profile). In the table of Fig. 11, the only variables of interest are whether the group has a

service profile ID and whether the user has a service profile ID. If neither do, then a default

standard service profile is used. If only one is specified, than that ID is used to look up a

matching service profile in memory. If both are specified, then one should be used (e.g., the

group ID) to look up a matching service profile in memory.

[037] Referring back to Fig. 8, and the service profile tables, these tables can also specify the

user request category and type as well as the operating system and subtype to further control

the service contract selection.

[038] If the service provider cannot properly service the user request, then it can indicate this

occurrence to the service network platform. In such a case, the service network platform is to

re-apply the service profile so that a new service contract can be created.

[039] Although several embodiments are specifically illustrated and described herein, it will

be appreciated that modifications and variations of the present invention are covered by the

above teachings and within the purview of the appended claims without departing from the

spirit and intended scope of the invention. For example, though the description above

concerns user requests related to computer hardware and software issues, the present

invention can be extended to providing servicing of a variety of other types of user requests. Also, "user requests" can come from sources other than the user. For example, the service contract provider computer can supply the user request (e.g., transmitting information to the

service network platform to create a user request for a user). In this case, the user request can

be generated in response to interaction between the user computer and the service contract

provider computer, for example.

Claims

What is claimed is:

1. A service network comprising:

a service network platform to store at least one set of contract terms;

a user computer to transmit a user request to the service network platform,

wherein said service network platform is to apply a service profile to said user request

to assign a set of contract terms to control servicing of said user request.

2. The service network of claim 1 wherein said service profile defines a mapping

between a classification of the user request and attributes of a set of contract terms.

3. The service network of claim 2 wherein said set of contract terms define a set of

service providers qualified to service said user request.

4. The service network of claim 2 further comprising:

a service contract provider computer coupled to said service network platform to

configure said service profile.

5. The service network of claim 2 wherein said set of contract terms includes a plurality

of tiers such that said service network platform is to determine whether all conditions of a first

tier are met in assigning a service contract to control servicing of a user request.

6. The service network of claim 5 wherein said service network platform is to specify

that multiple service providers are to collaborate to service said user request according to said

first tier.

7. The service network of claim 6 wherein if all of the conditions of said first tier are not

met, then said service network platform is to determine whether all conditions of a second tier

are met.

8. The service network of claim 4 further comprising:

a service provider computer coupled to said service network platform, wherein after

said set of contract terms are assigned to control servicing of said user request by said service

provider computer, said service network platform is to re-apply said service profile if said user

request is not properly serviced by said service provider computer.

9. The service network of claim 3 further comprising:

a service provider computer coupled to said service network platform, said service

provider computer to receive a plurality of user requests.

10. The service network of 9 wherein said plurality of user requests are to be restricted to

qualifications of a service provider at said service provider computer.

11. The service network of claim 1 wherein said user request automatically includes

diagnostic data for the user computer.

12. The service network of claim 1 wherein said service profile includes rules defining

whether the user computer system is entitled to a particular service.

13. The service network of claim 1 wherein said set of contract terms define payment

terms.

14. A method of creating a service contract comprising:

transmitting a user request to a service network platform; and

applying a service profile to said user request to assign a set of contract terms to

control servicing of said user request.

15. The method of claim 14 further comprising :

storing sets of contract terms at said service network platform.

16. The method of claim 15 further comprising:

transmitting one of said sets of contract terms from a service contract provider to said

service network platform.

17. The method of claim 16 further comprising:

configuring said service profile by said service contract provider.

18. The method of claim 17 wherein each of said sets of contracts includes a plurality of

tiers, the method further comprising:

determining whether all conditions of a first tier are met in assigning a service contract

to control servicing of a user request.

19. The method of claim 18 further comprising:

if all of the conditions of said first tier are not met, determining whether all conditions

of a second tier are met.

20. The method of claim 14 further comprising:

entering of proposed contract term at a user computer coupled to said service network

platform.

21. The method of claim 20 wherein said contract terms include a set price to be paid by a

user for service of said request.

22. The method of claim 21 further comprising:

transmitting said user request to a plurality of service provider computers coupled to

said service network platform..

23. The method of claim 22 further comprising:

transmitting an acceptance of said user request from on of said service provider

computers to said user computer.

24. The method of claim 14 further comprising:

said service network platform.

25. The method of claim 24 further comprising: transmitting to said user computer a plurality of bids from said service provider

computers.

26. The method of claim 25 further comprising:

accepting one of said bids at said user computer.

27. A set of instructions residing on a storage medium to be executed by a processor to

implement a method of creating a service contract, the method comprising: transmitting a user request to a service network platform; and

applying a service profile to said user request to assign a set of contract terms to control

servicing of said user request.

28. The set of instructions of claim 27, the method comprising:

storing sets of contract terms at said service network platform.

29. The set of instructions of claim 28, the method further comprising:

service network platform.

30. The set of instructions of claim 29, the method further comprising:

configuring said service profile by said service contract provider.

31. The set of instructions of claim 30, wherein each of said sets of contracts includes a

plurality of tiers, the method further comprising:

to control servicing of a user request.

32. The set of instructions of claim 31 , the method further comprising: if all of the conditions of said first tier are not met, determining whether all conditions

of a second tier are met.

33. A service network comprising:

a service network platform to store at least one set of contract terms;

a service contract provider computer to transmit information to the service network

platform to create a user request for a user;

to assign a set of contract terms to control servicing of said user request.

34. The service network of claim 33 wherein said user request is to be generated in

response to interaction between the user and the service contract provider computer