Introduction

About this document

Negoisst is a prototype electronic negotiation support system (NSS) that covers semi-structured communication as well as document management and decision support. The key characteristic of the system is the integration of these components. This document presents the system using a simple fictitious negotiation case which will be introduced in the next section.

You can download this document as a pdf-file here:

Negoisst training case 10/21/2003, 350 kb, pdf-document

Background Information

The Negoisst system is developed by the e-negotiation group located at Hohenheim University and the e-business group at Informatik V (Information Systems), University of Aachen (RWTH). If you have any questions concerning this document or the system, feel free to contact us (fkoehne [at] uni-hohenheim.de).

Negoisst supports bilateral electronic negotiations, i.e. negotiations between institutions via the internet. You choose your negotiation partner from a list of companies and then send different types of messages to your contract partner: an offer, a request or just a piece of information. The message types represent your intention, e.g. whether your utterance is meant as a formal request or as a mere informal enquiry. Throughout your negotiation, you are able to draw up a contract by selecting specific words in your e-mail-text and matching them with certain contractual points. This is an implementation of the DOC.COM framework.

top

   The training case

This section introduces a simple negotiation case as an example. The training case was delevoped in preparation for the 3rd Annual International eNegotiation Tournament in November 2003 (register here). Although Negoisst was designed with B2B-negotiations in mind, the demonstration case will be a Union-Management collective bargaining situation. The parties are Management and the Teachers Labor Union of the fictitious eSchool. You can find some background information on the case here.

The two parties have been negotiating for some time and have agreed on all issues except which values will fill the blanks in following framework for agreement.

Table 1: Issues to negotiate

While the structure of issues is more or less common knowledge, each negotiating party has its own private / confidential information, in particular regarding its preferences. In this case, we will first take the role of the management party, assuming the following preferences.

Table 2: Management's confidential preference information

top

   Guided system tour

In the follwoing paragraphs, the key functionality of the Negoisst system will be described on a step-by-step basis. In the system, the online documentation can be accessed through the links in the upper right corner of each window.

Registration and login

Both parties agree to use Negoisst for the negotiation. Since they use the system for the first time, they first click on the link subscribe in order to register. They also have to choose a user name and a password. Remember that both username and password are case sensitive and passwords must have at least 5 characters.

Another important point is for each user to provide a valid e-mail address, because the address will be used for sending notifications.

Figure 1: Subscription

As all necessary information was provided and saved, the representative finds her team in the list of registered institutions. She chooses Home in the upper right corner in order to go back to the login screen.

Figure 2: Login

The management representative now uses the chosen name and password to log into the system. On the left hand side of the screen, the main menu appears and will remain there during all further steps. On the right side, there is a list of negotiations which is currently empty.

Structuring the issues

As a first step, the management representative now structures the issues to be negotiated (only one party has to do this). In terms of the Negoisst philosophy this means that the representative first creates a topic with those properties that both parties have agreed upon. She, therefore, chooses Define Topic from the menu.

Figure 3: Defining a topic

Topics need a name and some other obvious information. The representative fills in the form and saves the information. In some industry sectors, identical contract points appear over and over again (e.g. price, delivery date etc.). These attributes are presented in a pre-defined list to choose from. In our case, only the basic element 'Agreement' - the root of the issue tree - is predefined. We choose and copy it into our framework with Add to topic.

The Agreement attribute must not have any values since it is a container for other attributes. Furthermore, the representative will now create own attributes and click on Define new attribute.

Figure 4: Creating a topic attribute

Attributes need to have names to be included in a topic. The representative just copies the first name from Table 1: "Salary". Furthermore, a type must be chosen for the new attribute. Salary is obviously a numerical attribute and is a top level attribute of the labour contract. Thus, she chooses Agreement as the parent attribute of the new one (Note: defining hierarchies of attributes is extremely useful if there are a lot of elements like payment with payment intervals, payment dates, type of payment etc.).

Figure 5: Adding values to a choice attribute

After confirming the information with "Save", the whole topic is visible again and the management representative repeats the process for the remaining attributes Teacher Evaluation and Arbitration Method. The latter attribute is of categorial type and Negoisst asks for the attribute's values. In the present case, the representative then inserts the values "binding" and "advisory" and then chooses Back to topic view.

Starting the negotiation

After saving the topic, the management representative starts the negotiation process and chooses the according link in the menu. A new dialogue is presented. She chooses a meaningful name for the negotiation: "Labour Contract, November 2003" and selects the negotiation partner from the list, in this case eSchool Union Team.

Figure 6: Initiating a negotiation

Now the representative selects the topic that she has just created, namely "Labour Contract November 2003". Furthermore, she can choose to enable decision support in the negotiation. Because she thinks that she can benefit from any support whatsoever, she enables the decision support module and proceeds by choosing New negotiation (Note: all negotiation parties can choose their preferred mode or decisision support independent of the other party's choice; each party can only see their own choice; the choice of the other party is not visible. The union team can enable the DSS module using the DSS link in the list of negotiations).

A second dialogue now shows the elements of the contract and numerous text fields to be filled in. The representative is asked to express weights (importance) for the three contract attributes. Furthermore, she is asked to express the desirability of each option offered. She uses the information from Table 2 and fills in the values you see in the following screenshot. The value of 4% in the minimum value field is meant to be the least desirable value for the eSchool management.

Figure 7: Definition of preferences in the DSS module

Negoisst's decision support module uses this information to estimate the representatives utility function. This function can later be used to evaluate offers - with some limitations. However, if the negotiation becomes long and difficult, this estimation might be extremely useful to identify "good" offers in the negotiation's history at a glance.

Figure 8: Evaluating full packages

In a third step, Negoisst evaluates some possible outcomes using the given preference information and shows the results on a percentage scale (with 100.0 meaning "perfectly desireable" and 0.0 meaning "absolutely undesireable"). The representative changes some of these estimations because they do not seem to reflect her own ratings and Negoisst tries to correct the utility function to represent the management's preferences as precise as possible.

The representative can change the preferences at any time during the negotiation process, e.g. when receiving additional information.

Exchanging messages

After the preference elicitation, a message form is offered to the management representative. She can now write a first message as a free text in the text field on the left. However, Negoisst offers tools allowing each user to clearly express the meaning of the message in order to avoid ambiguity in the communication.

Figure 9: Message Editor

Please note that the exchange of messages is strictly alternating! After sending a message, negotiators have to wait for a response. This ensures that it is always clear who is responsible to send the next message.

Messages have types

Each message consists of a message type which specifies the intention of the sender in order to avoid abiguity.

1. Request	A negotiation can begin with a request. It can be used to e.g. express interest in purchasing a selected product.
2. Offer	A negotiation can begin with an offer. It can be used to present some products to a (potential) customer.
3. Counter-offer	A negotiation can proceed with a counter-offer that can be issued by both parties and is used as a reply to a request or an offer. This message type represents the fact that the sender is not yet satisfied with the previous message sent by the other party.
4. Accept	A negotiation can end with an acceptance which refers to the acceptance of the current contract version. It indicates that the sender agrees with the previous message.
5. Reject	A negotiation can end with a rejection which indicates a serious disagreement and terminates the negotiation unsuccessfully, i.e. without providing a contract.
6. Question	If a clarification is required during the negotiation process or if there is a need for a discussion between the negotiation partners, the mssage type question can be used. Such a message can only occur in the informal area.
7. Clarification	A clarification message is the answer to a question and can only be placed in the informal area.

The type of a message can be declared in the upper left part of the window and the system ensures a consistent order of message types exchanged. For example, a question message can only be answered with a message of the clarification type. The representative declares her first message as an offer.

Messages are situated in an "area"

To guarantee a flexible negotiation process and to avoid the criticism that negotiations are not only rational processes but might contain contexts where ambiguity or vagueness concerning the intention is common or maybe even intended, Negoisst offers two workspaces or negotiation areas.

The formal workspace (or the "red area", indicated by ) is the medium for serious formal negotiations whereas the informal workspace (or the "green area", indicated by ) can be used for discussions, preliminary exchanges etc. without any commitments. In the informal workspace, no message type need to be specified. A message can be placed in an area using the selection field in the upper right corner of the window. Messages can later be switched from one area to the other, under some consistency constraints.

Messages in the green area can only be answered by messages in the green area, messages in the red area can be answered by messages in both areas.

In our example case, the management representative does not change the default setting and the message will be located in the red area.

Parts of messages can be explicitly associated with contractpoints

Free text communication can be highly ambiguous and often leads to misunderstandings. This problem is adressed in Negoisst by providing structured elements with a defined meaning to be used in the free text communication.

When the representative offers a certain salary increase in the first message to the union, say 2%, she chooses Salary from the attribute tree on the right hand side and enters a value there. When she then clicks back into the text field, "Salary: 2" is automatically inserted into the text and she can proceed with the message.

The selection process makes clear that here the SALARY from the framework for agreement is meant and not any other number or, for example, the salary in other contracts which might be mentioned in a negotiation for a strategic purpose. Furthermore, the entered value is inserted into the current version of the Labour contract automatically if the message is in the read area. The value will be kept in further contract versions unless it is changed by one of the negotiation parties.

It might be the case that negotiators do not stick to the initial framework of agreement. In that case, new attributes can easily be introduced to a negotiation using the according link above the message text (Note that this is not allowed in the Tournament). Adding new attributes works the same way as described for structuring the issues. However, the topic data is not changed - all changes affect the current negotiation only (You might want to change your preferences in the DSS-module if you introduce a new attribute).

The mere specification of a value for a contract point is often not sufficient. In addition, it must be made explicit whose obligation it is to fulfil a certain contract point. In this case, the management commits to the duty of paying an increased salary (see screenshot above). There are situations in which it is not obvious who has a certain obligation and where the obligations themselves are the subject of a negotiation. Consider e.g. the delivery of goods. The representative explicitly commits herself by activating the red light next to the contract point. A red light means "My responsibility" while a green light means "The responsibility of the other party". This commitment will later be part of the contract. To avoid misunderstandings, each user can only activate the red light since it is not possible to commit someone else to a duty. It is also possible that both parties commit to a duty. For example, in our case management and union will have to commit to an arbitration method.

To understand the interaction of free text and the attribute tree, please have a look at the following animation (requires Flash):

With enabled DSS functionality, the system gives an estimation of the current offer's utility value as the representative creates her initial offer. However, as long as there are issues that have not yet been negotiated, the estimation can only give an upper and a lower bound for the utility estimation. The system calculates these bounds by assuming best and worst cases respectively for all attributes that have not yet been addressed. The bounds indicate the 'room to negotiate' if the user would like to have this option.

Contracts and the history of the negotiation

After adding some free text, the representative decides to send the message with the most important salary offer in order to see if the union will accept it. After sending the message, a tree-like overview of the message exchange is shown. The room to negotiate in each message is indicated graphically, here between utility values of 0.6 and 1.0 in the message just sent. Furthermore , the sent date, the type, and the area (there is a red circle on the left side that indicates: area red) of the message are shown.

Figure 10: Negotiation view

If a user receives an answer to his/her message or another company makes an offer to a user, Negoisst will send a notification via eMail to the adress specified on the registration form. However, we advise each user to log in regularly in order to check whether there has been any activity.

It is one of the fundamentals of the Negoisst system to give an integrated support to the management of communication, e.g. the exchange of messages, and the management of documents. Messages and documents are linked in that each message in the formal negotiation workspace defines a new contract version. Therefore, each message in the message history provides a Contract-option. With this option, the current version and all past contract versions can be accessed.

You see such a contract document below (fig. 11). It includes all values and explicit duties, if specified.

Figure 11: Example Contract

The integration of documents and messages also works the other way round: Each contractpoint specified is linked to the message in which the contractpoint has been defined. After clicking on the according symbol (), both the contract version and the message will be shown. This makes it easy to find out why certain decisions were made, what specific arguments were used in relation to a particular contractual item etc.

For easier reference, there is also an odered view of the duties each party committed to ("to do" lists, if you like). If you choose "Actual duties" below the list of messags sent, you should see something like the following figure (fig. 12). Note that this is an optional functionality and the contents of the lists can only be changed using the red buttons next to the contractpoints while editing a message.

Figure 12: Example Contract

Finishing a negotiation

The end of a negotiation is represented in a straightforward manner as a message type. A negotiation ends once a message of the type Accept or Reject is sent.

However, the negotiation data and especially the final contract will remain accessible in the way described. For the purpose of documentation, it will not and indeed cannot be deleted.

top