"Let's make a deal!"

Monty Hall

This article describes a project to develop a platform that promotes transactions between customers and suppliers within a business ecosystem. A web-based platform is being developed to track customer interactions and manage the flow of deals through development stages. The solution will be implemented using an open source customer relationship management (CRM) tool that will be customized to suit the particular needs of a business ecosystem.

Introduction

A key indicator of a healthy business ecosystem is its ability to generate revenue for all the players involved. In his June 2010 OSBR article, Tony Bailetti defined a business ecosystem as "a community of companies, organizations and individuals that share a desire for achieving high-impact, system-level results and deliver benefit to their customers, partners and community members from their interactions using a multi-sided platform." Within this community, deals are the key revenue generator. This article examines how a platform can promote ecosystem health by encouraging more deals to be created and closed.

In the Technology Innovation Management program (TIM) at Carleton University, a lead project is underway to develop a deal development platform for business ecosystems. Using a local technology business ecosystem, Lead to Win, a prototype framework is being developed that can be extended to other business ecosystems. The first half of this article defines a deal flow process. The second half of this article describes the implementation of an open source CRM tool to track customer interactions and manage deal flow, with functionality customized to the particular needs of business ecosystems.

Lead Project Overview

The goal of the deal development project is to provide a web-based prototype solution tailored to business ecosystems. The project began in June 2010. Development of the deal flow platform is proceeding through the following steps:

1. Define deal players and their responsibilities.

2. Define stages of ecosystem deal flow.

3. Specify technical requirements.

4. Implement technical solution.

5. Deploy the prototype to be tested by lead users.

6. Evolve as necessary.

The following sections describe the project's progress to date through each of these steps and the lessons learned.

Players and Their Responsibilities

A typical deal supported by the platform will have the following players:

1. A customer: a company or individual that brings a problem to be solved.

2. An orchestrator: a company that will serve as a middleman between the customer and the rest of the ecosystem to simplify interactions with the customer and coordinate the actions of the suppliers.

3. A primary contractor: an entity responsible for delivering most or all of the solution.

4. Suppliers: other companies who will be delivering parts of the solution.

Without a customer and their problem, there is no deal. Customers bring the problems that need to be solved and they contribute feedback to the development of the proposed solutions. Importantly, they also bring the money.

The primary responsibility of an orchestrator is to mediate between the ecosystem and the customer. An orchestrator should find companies within the ecosystem with the necessary skills to craft a solution to the customer’s problem. The orchestrator should also interact with the customer to ensure that changes to requirements are passed along to the primary contractor and suppliers. Any ecosystem player could theoretically become an orchestrator. However, orchestrator selection will usually favour the most qualified, experienced, well-connected, and trusted players. In special circumstances, a customer may orchestrate their own deal, which is more likely when the customer has participated in the ecosystem long enough to become familiar with the way deals operate within it.

The primary contractor is responsible for performing most or all of the work. It advises the orchestrator of the required timescales, resources, and services. It may also help the orchestrator find contractors with the skill sets necessary to build a solution for the customer, particularly if specialized skills are required. There are no formal requirements for primary contractors. The selection is made by an orchestrator based on the primary contractor's level of trust, reputation, and technical skills.

Suppliers are typically small companies that cannot reach customers directly or have a limited view of the big picture of a customer’s problem even when the customer is already affiliated with the ecosystem. These companies need a channel to go to market and the deal development platform provides this channel. Suppliers may be contracted directly by the orchestrator or by the primary contractor depending on the requirements of the solution.

Other players may be involved during different stages of a deal development process to provide their expertise and services. For example, subject experts acting as service providers may be involved during the screening of potential opportunities to help to help determine whether there is sufficient capability within the ecosystem to solve the problem. Later on in the process, a contract may require legal and intellectual property experts to ensure that it fully covers the rights, responsibilities, warranties, and liabilities associated with the deal, as well as the relationships of other companies who participated in creating a solution for the customer.

Why Deals Within Business Ecosystems Are Different

The roles described in the previous section and the nature of interactions between the players represent a significant shift from the traditional customer-supplier relationship, where the supplier interacts directly with the customer or through an intermediary to make the deal. In a business ecosystem, both the suppliers and customers are affiliated with the ecosystem. Tony Bailetti discussed this shift in his June 2010 OSBR article and his illustration of these relationships is reproduced here as Figure 1.

The business ecosystem approach takes advantage of shared affiliations to connect suppliers and customers to intermediaries, orchestrators, and other members through the deal development platform. The existence of the platform creates advantages for all members over the traditional model and brings players together through their common interest in making a deal. Efficient deal making, reduced transaction costs, and greater opportunities for collaboration and co-creation are expected.

Figure 1. Traditional Supplier-Customer Relationships Versus the Business Ecosystem Approach

Deal Flow Stages

As a deal progresses, it moves through several defined stages (Figure 2). In the first stage or the proposed deal flow, a potential deal begins when a customer submits a problem. The problem is then evaluated to determine whether it represents an opportunity for a deal. To proceed, a problem must be feasible and a good fit for the supplier capabilities in the ecosystem. Once a problem is qualified as an opportunity, it progresses to the next stage, where orchestrators submit proposals to solve the problem.

Figure 2. Deal Development Stages

During the proposal stage, iterative improvements may be suggested based on customer feedback. Once the customer accepts a proposal, a memorandum of understanding (MOU) is created by the customer and the orchestrator. The MOU is not binding; if subsequent progress is unsatisfactory, the customer can re-open the problem for additional proposals.

The MOU stage is also known as Gate 0. Gates are points in the process where certain conditions must be met before the deal can proceed to the next stage. For example, the condition for moving through Gate 0 is acceptance of the MOU by all sides.

Next, the deal moves to the contract development stage, where the objective is to pass through Gate 1 by completing and signing a contract. The contract is developed between the customer, the orchestrator, and the primary contractor. In parallel, the primary contractor and suppliers will also work on the prototype solution, which may be complete by the time the contract is signed and the deal passes through Gate 1.

Once the contract is signed, the deal moves into the solution delivery stage, where the solution is developed and then delivered. Once it is delivered, the deal passes through Gate 2 and is considered to be fulfilled. Finally, Gate 3 signals the completion of postmortem reviews, undertaken to capture feedback and to evolve the deal flow mechanism.

Implementing the Platform

Up to this point in the project, the focus had been on the players and the procedural stages that a deal passes through until completion. The next step is to implement a platform for managing this process. The previous steps provided insight into the technical requirements of a platform:

1. All ecosystem members must have access to the platform.

2. All proposal and deal documentation must be stored in a common database.

3. All interactions between players must be tracked.

4. The status of a each deal must be tracked, including the details of its progression through each stage of the deal flow.

5. Different levels of access privileges must be implemented to prevent access to confidential information by members of the ecosystem who are not part of that deal.

6. An individual may have different access privileges for different deals, depending on their role in each deal.

The parallels between the proposed deal flow and the activities involved in managing customer relationships in a single company pointed to a customer relationship management tool as the preferred starting point for implementing the platform. Considering the diversity of players that need access, a web-based solution was required. Finally, the need to customize the application to suit the unique context of a business ecosystem suggested that an open source solution should be used.

In the following section, the traditional use cases for CRM and its related tools provide the necessary background to understand the key functionality of these tools and how they may require customization to suit business ecosystems.

Traditional CRM Use Cases

CRM has been well studied and practiced for over a decade. All commercial CRM tools support processes for lead management, sales, marketing, and support. They enable the user to efficiently manage the flow of each customer account through each of these processes. A typical CRM use case is in support of sales force automation and call center management.

Many proprietary and open source CRM tools are available and they are now commonplace in traditional business settings. However, the presence of a CRM tool and related IT technology does not automatically achieve good CRM practice and outcomes. Most off-the-shelf CRMs support marketing and sales processes very well, but they are limited to these activities. To be effective, the technology must handle all of the customer information management processes necessary to achieve end-goal performance for the organization.

The ideal approach is to establish a customer-centric culture and management approach and then select and modify the technology to provide the necessary support. The processes should be evolved over time based on feedback from the outcome performance, which is measured relative to the goals of the company or platform. An organization’s CRM must be focused on managing the entire customer lifecycle relationship rather than being solely concerned with transaction-based relations or one-on-one relations. In other words, a strategic approach is required to achieve the goals of the firm. A good CRM tool is of little use if the data are not being used for strategic planning or if it is not known how data from the tools and CRM processes relate to end goals of the company. This approach requires an ongoing and evolving process for managing customer relationships. Feedback from past performance informs new strategies for the organization to provide value to the customer.

Adapting a CRM for a Business Ecosystem

While a CRM system can be a useful tool in streamlining the way that a company interacts with customers, deploying such a tool for ecosystems presents significant challenges. Existing CRM applications are made for single companies. In an ecosystem, there are many players interacting with other members and customers. During deal making, each of the players should be able to see the content relevant only to deals in which they are participating. This requires an extended system of access privilege control and additional account features. Similarly, a process for deal development within an ecosystem is different from traditional contract development between one company and another. In order to develop such a process, ecosystem researchers should work together with orchestrators, suppliers and customers, as well as legal experts and other users of the processes, creating opportunities for multidisciplinary work.

The deal flow has implications for the adaptation of a CRM tool at the level described in Figure 2, but also within each stage of deal progression. Throughout the process, the CRM must log all decisions and interactions between players, along with the documents required for that stage. As the deal progresses within and between stages, the relevant documentation must follow.

To illustrate how the CRM tool may be used, Figure 3 shows the possible activities that comprise the proposal stage (Gate 0). This stage starts with the input of a qualified opportunity and ends when the proposal is accepted or withdrawn. Before starting, teams are assembled and roles are assigned and the team structure and player roles are reflected in the CRM tool. Orchestrators have access to all data, but the access of members is limited by their role. Each update their documents and submit them for review by one or more team members and then the customer. The outcome of the review could result in further changes with or without a change in orchestrators, acceptance of the proposal, or cancellation of the proposal. If the proposal is accepted, the deal has passed Gate 0 and it enters the next stage of the deal flow.

The CRM tracks the progression of the deal and automatic notifications can be sent to all interested parties when a new stage is reached. Throughout the process, the CRM logs all interactions, including emails, voice communications, notes, documents, contacts, and meetings. The data will be used to analyze relationships and inform future strategy planning and performance improvement.

Figure 3. Activity Flow Within the Proposal Stage

To help users initiate a deal and progress it through the various stages, the CRM tool should provide generic templates for documents and activity flow. In a large ecosystem with a variety of companies supplying products and services for customers, and with participants of various roles contributing towards a final deal, the level of deal complexity and variability is likely high. It is difficult to anticipate what will be required for a "generic deal". For the purposes of this project, a number of case studies will inform the initial template, which will evolve over time. The goal is to make it flexible to support future evolution.

Conclusion

A CRM-based deal development platform adds value to a business ecosystem by providing customers with an interface to an ecosystem and reducing their transaction costs. For suppliers, it provides an efficient means to submit proposals and make deals, which ultimately increases their opportunities for revenue generation. A robust deal development platform that simplifies the response to a customer’s need, while reducing the cost of going from problem to solution, can provide a competitive advantage for a business ecosystem and its members.