Preparing for a New Customer Engagement: Part Four
Published On : Friday February 7, 2020
4.6 Solution information
What have we sold them?
Perhaps the most obvious information to discover is information about what has been sold. It certainly pays for the CSM to ensure they have a thorough understanding of this topic since they will be responsible for helping the customer to make sense of what they’ve bought and to get it up and running and creating value for them. A bill of materials or similar list that details on a line-by-line basis what precisely the customer has purchased is a very good start point. However sometimes the bill of materials is quite technical and it may require some interpretation and explanation by the account manager or solution architect who put the list together. In any case it will only give you a very basic understanding since it only explains what they have purchased and not why or how.
Alongside the (interpreted and explained as necessary) bill of materials, and assuming that the solution is a complex one with multiple components to it, the CSM should enquire about the architecture of the solution. What I mean by the architecture is how the different components of the solution fit together to deliver a particular output or result for the customer. In other words as well as understanding what each line item is, it is equally important to understand what role that particular item plays within the overall solution. This will give the CSM a more holistic (or architectural) understanding of what has been sold and how it all fits together to generate value. Of course there will potentially be many highly technical decisions made by a solution engineer in determining solution components that will be beyond the technical understanding of a CSM. This is fine however, since regardless of our level of technical understanding, CSMs are principally focused on business outcomes not technical ones. We need enough of a technical understanding to appreciate the concepts and to follow the conversation, but our role is not to replace the engineer but to work with the customer to get value delivered. Remember that the CSM is not expected or required to always be the “smart” one in the room nor to have an answer for every question that is asked. The CSM’s role is to provide access to others’ knowledge and expertise as much as or more than their own.
Additional Components
As well as the solution itself there may be additional professional services items that have been sold alongside the solution to enhance its effectiveness. These might include consultancy around requirements, customization or one or more of the products or services, installation and configuration services, and ongoing management and maintenance contracts. Of course there is likely to be some kind of technical support contract in place and possibly user support as well. All of this needs to be uncovered and understood by the CSM.
Revenue Information
Finally, the CSM should make sure they are aware of how revenues will be generated from the deal. In particular the CSM needs to be aware of any renewable contracts for services, and expectations as to the lifecycle for these contracts. A significant part of the CSM’s duties is to ensure as best as possible that customers renew their contracts. Of course not every contract is anticipated to be continued each period (monthly, quarterly or yearly) since some services may be deliberately planned to be temporary, hence it is essential to understand lifecycle expectations for each renewable service. An understanding of overall revenue amounts from the deal (both immediate and planned) can also be useful as it provides a basis for determining how much of the CSM’s time and effort should be allocated to this customer engagement.
4.7 Initiative information and customer outcome requirements
Understanding the Customer’s Initiative
The next aspect of the engagement to research is the reason behind the customer’s decision to purchase your solution – the customer’s initiative. Make sure you know what the initiative that you are supporting is called and the purpose of the initiative i.e. what it will achieve. It is also useful to understand how the initiative fits within and supports the wider vision, mission and corporate strategies of your customer’s business.
Of course the most essential initiative information to understand about the customer’s initiative is their outcome requirements from it, since these will be what you will be working with them to help them attain. However it is also important to understand any significant milestones along the way to attaining those outcomes that are also important to the customer. In addition there may be other considerations about the initiative that are worth the CSM knowing about, such as technical or business challenges, installation, configuration or customization work, security concerns and business continuity implications. All information of this sort should be understood and documented by the CSM so that when they meet the customer they will understand the landscape of the initiative sufficiently well to be useful in helping the customer’s stakeholders formulate meaningful plans for adoption and utilization.
Outcomes
Now let’s turn to a more in depth discussion about outcomes. Customers require outcomes from their purchases. This is only reasonable since they have invested their time and other resources and of course they have invested (and will continue to invest) their money in determining the business case and making the purchase. Now they need to work hard to gain a return on this investment in time, money and effort for their shareholders, their owners and/or their customers or clients as appropriate. This generation of value is very much the central focus of a CSM’s efforts, so it is critical to the CSM that they ensure they have as full and detailed an understanding of the customer’s outcome requirements as possible.
Capabilities, Inputs, Outputs and Outcomes
In order to understand how outcomes are attained, it is important to grasp the relationship between outcomes, inputs, outputs and capabilities. The word capability simply means “the ability to perform a function or task” and it includes the people, the process and the tools that are needed to perform that task, together with the inputs and outputs for it. Inputs are things like raw materials or data from a person or previous task, and outputs are the end results from the performance of the task or function such as the creation of a product or the processing of information into a report. The basic concept of a capability is simple: the people involved in the capability follow the processes and use the tools to turn the inputs into outputs. Outputs can be defined therefore as the direct results of the actions taken within each capability. All the outputs from all relevant capabilities combine over time to create the outcome or outcomes that the customer has defined as its target or goal. Outcomes therefore describe the end result that is ultimately attained by performing all the relevant capabilities over time.
It is customary to define business capabilities in three levels from the most macroscopic to the most detailed. An example of a high level business capability would be “Sales”, which could be defined as the capability to engage with clients, negotiate contracts and win new business. An example of a mid-level capability within Sales is “Taking New Orders” which could be defined as the ability to take a new order for a product or service from a customer. This is not the only thing that happens within the overall Sales capability, but it’s certainly an important part of it. An example of a detailed level capability would be “Taking New Orders for Product X” which of course is the ability to take a new order for a specific product from a customer. Taking an order for Product X might be significantly different from taking orders for other products and services. For example perhaps there are a range of options for the customer to select from, a range of financing or payment choices to be made, customization work to be documented, a delivery date to negotiate, and so on.
The concept of capabilities is often used in both the technical and business consulting worlds to break down an entity such as a company into its constituent parts in order to see how those parts fit together. From there decisions can also be made as to which parts (i.e. capabilities) are no longer required, which can be kept as they are, which need improving and which are needed but do not yet exist. This is called capability analysis and of course it leads to capability improvement that in turn leads to better outcomes for the company.
Capabilities are very powerful since they define everything that needs to be done at all levels within the business and can therefore serve as a simplified model of either the business as a whole, or a department, or even a specific function. Once we know what the business’s capabilities are and how they work it becomes easy for consultants and senior decision makers to determine what changes need to occur and at what level within their business in order for that business to successfully adapt to change, whether that change is due to external drivers such as new customer requirements or updated legislation, or internal drivers such as an low productivity or high costs.
We will discuss how CSMs use their understanding of their customer’s business capabilities in later chapters of this book when we deal with adoption research and planning. For now the important thing to grasp is that because capabilities comprise people, process and tools, an understanding of which capabilities are being modified by our solution will also tell us which people may be impacted, which processes are likely to change and which tools might be replaced, adapted or used differently.
Finally, this understanding of how the customer’s capabilities will change helps CSMs to understand the differences in outputs between the existing capabilities as they are now and the new capabilities as they will be post solution adoption. From this information the CSM can determine how these outputs might be measured in order to calculate and report on value creation and (since outputs combine over time to generate business outcomes) how to track and prove progress towards customer outcome attainment.
Documenting Outcome Requirements
With all of the above in mind, the CSM should make sure they have documented all of the known customer outcome requirements for the initiative in as much detail as possible. At a minimum it should include a description of what the outcome is together with a quantity (either relative or absolute) and a deadline (either relative or absolute) for achieving the outcome. Ideally, the way in which the outcome will be measured should also be included if known. Examples of outcomes documented with this information might be:
| Description | Quantity | Deadline | Measurement |
| Quality of service experienced by customers after they have purchased our products | 15% uplift | 24 months from now | Annual customer survey |
| Reduction in raw materials wastage in the manufacturing process for Product X | 20% reduction | By end December 2020 | Materials used divided by number of products made |
| Faster speed to market for new releases of Software Y | Max 6 months between releases | Immediate | Date of release of Software Y upgrades |
Hopefully what you can see from this is the level of clarity this information brings to the CM (and often to the customer as well) around the targets the customer has for the engagement, and therefore what the CSM needs to ensure happens in order to ensure (as much as possible) that the customer renews their service contracts and/or makes further purchases and/or provides some great advocacy for marketing to other prospective customers.
Validating Customer Outcome Requirements
Sometimes customer outcomes are known for certain (generally because the customer has stated them during the sales process) but sometimes either the outcome itself or some of the data pertaining to an outcome such as the quantity, deadline or method of measurement are not known for certain but have been assumed or estimated. It is important that the CSM is clear what is definitely an outcome requirement as stated by the customer and what is an assumed outcome requirement that needs validating with the customer.
Primary and Secondary Outcomes
A final point on customer outcomes. Sometimes one or more outcomes are the most important ones and attaining just these outcomes alone might be the driving force behind the purchasing decision. In other words if those outcomes are attained then the customer will be at least satisfied with their investment. However in the course of delivering these outcomes, other outcomes may also be attained which were not necessarily the reason for the customer’s initiative going ahead, but are still of value to the customer. These could be described as primary and secondary outcomes. Examples of this might be where the primary (ie the required) outcome is increased productivity in the Manufacturing department and a secondary outcome from the initiative put in place to support this outcome might be increased customer satisfaction due to reduced waiting times between ordering and receiving their products. It pays therefore for the CSM to always be asking themselves “how else might this initiative impact my customer’s business?” when they are researching and uncovering customer outcome requirements.