Operate > WebSphere Commerce Accelerator > Business relationship management
Business relationship model
The key elements in the business relationship model include the different kinds of contracts, the various buying units, and the distinct customers who have access to the site. These elements will be discussed further from different scenarios to explain their role in each.
The WebSphere Commerce business relationship functionality is illustrated by the following diagram:
Extended sites
In an extended site model each store, representing an extended site, should have a base contract which governs the interactions between the store and the customers of that store. An account is not necessary. When the extended site is created, a default contract must also be created for the site, and it would refer to the base contract. A customer of the extended site can then browse the site, and is governed by the specific terms and conditions that comprise the contract for which they are eligible. In this scenario, many of the items in the diagram can be safely ignored.
For example, consider a site that does business in both Canada and the United States. It might be appropriate for them to create two extended sites, each of which provides a unique store fronts to the customers in either country. In this case, they would have to create a default contract. Furthermore, each extended site would have a base contract. The thing that is unique about this scenario is that all of the customers in a given geography would be members of a single buying unit. That is, all of the customers browsing the site in Canada would be browsing according to the terms and conditions defined in the contract for the "Canadian" extended site. In the same manner, all of the customers in the US would browse the site under the terms and conditions defined in the contract for the "American" extended site.
Customer groups
In an customer group model, the store needs to have multiple contracts which govern the interactions between the site and the various customer groups. Again, an account is not necessary. When the customer group is created, it is assigned a contract. A customer that belongs to the customer group can then browse the site, and is governed by the specific terms and conditions that comprise the contract for which they are eligible. In this scenario, many of the items in the diagram can be safely ignored.
For example, consider a site that wants to implement a member rewards program, in which customers who have spent $500 qualify for a Gold membership. The Gold membership offers a 5% discount on future purchases. In this case, all that would be required is a default contract, and then a second contract for Gold customers. The customers who qualify as Gold customers would have to be explicitly added to the member group to which the contract applies. After that, whenever they log in, they would be able to browse the site and be subject to the terms and conditions of the applicable contract.
Business customers
In a business-to-business model, the store needs to have multiple contracts which govern the interactions between the store, and the customer account. Once the account is defined, it is assigned a base contract. For each buying unit that is created, an additional contract is required which inherits the base contract, and then defines further terms and conditions as necessary. An employee of the customer account can then browse the site, and is governed by the union of the terms and conditions that comprise the contracts for which they are eligible.
As an example, consider an office supply store. This store would have an initial default contract that would govern any people that came to the site, who did not belong to a customer account. These people are nominally guest customers. The diagram expands upon this to include anonymous customers, and unentitled customers. The store would also require additional contracts which target specific market segments. When the store establishes an agreement with a business customer, an account must be created. During account creation, a base contract is associated with the account. This contract typically defines some account-wide terms and conditions, such as acceptable payment options and shipping methods.
To better accommodate different employees, they can be assigned to different buying units. In the diagram, let's assign the following conditions to the three buying unit. The first buying unit includes the regular staff. The second buying unit includes employees with ten years of service, which provides an additional 5% mark down on the cost of shipping. The third buying unit includes the management, and offers an expanded set of products. In the diagram, you can see that Buyer A is a member of two separate buying units. When they browse the store, they are allowed to see all of the products that are available to both of the first two buying units. This means that they would see the negotiated product assortment for the customer account, but would be able to purchase items and receive the lower shipping rate. Buyer B browses the site and sees the expanded product assortment, but would only receive the shipping rate defined in either the contract for their buying unit, or the base contract.
In this scenario, a store requires a default contract, a base contract for each account, and additional contracts for each buying unit within the account.