Customer relationship management vs business relationship management

Opinion

Customer relationship management vs business relationship management

During a recent talk to the Service Desk Institute about the future of the service desk, I asked the audience which processes they were involved in.

No-one mentioned business relationship management, despite the fact that direct contact with customers was probably the most prominent interaction between the service desk and customer – often the only contact. Even when I asked the attendees whether anyone thought that the service desk should be involved in business relationship management, only three people put their hand up.

Matthew Burrows.JPG

At some point in our lives we may all be both customers and service providers. The ability to see both sides of the coin will help to understand that business relationship management (BRM) and customer relationship management (CRM) are different, yet must work hand-in-hand.

When we talk about BRM what do we mean? BRM aims to maintain a positive relationship with customers. ITIL business relationship management identifies the needs of existing and potential customers and ensures that appropriate services are developed to meet those needs.

There are conflicting views around the definition though. Some see CRM as a sub-set of BRM because CRM only deals with customers, who are only one type of stakeholder. Others see BRM as being the IT service management equivalent of CRM.

To be honest, like most things in this industry, it’s about how we choose to adopt and adapt best practices to suit specific circumstances and respond to the objectives of customer and business. Many organisations will have a CRM process or similar already embedded in customer service, marketing and sales functions – and it’s good to be able to make a link between this and BRM. 

The service desk is already involved in BRM, even if they don’t recognise it. Even if only viewed as a service encounter, a good or bad experience with the service desk is likely to positively or negatively influence the relationship between the service provider and customer.

If you want your customers to see you as a trusted partner, you need to have progressed to competent supplier before you earn the right to try for a deeper relationship. Here is a suggested approach to building a strong relationship:

1 – Identify customers and other interested parties: Typically, the customer would be the person who buys the services, and they may or may not be users of the services. Other interested parties could include management, customers of our customers, shareholders, government, regulators, professional bodies, and suppliers. Depending on the situation, we may want to start off by deciding whether we want to do business with the potential customer or not, before we waste time or money. We should ask whether we want / need a relationship; what’s in it for us and for them; are we compatible? Can we help each other? Do we have a choice?

2 – Appoint a relationship manager: Assuming we do need a relationship, we need someone at an appropriate level of seniority who will be responsible for managing the relationship, accountable to the customer for performance, but also acting as an advisor and advocate, facilitating that two-way communication, including any required translations. Named individuals should be responsible for managing the relationship and customer satisfaction.

3 – Establish communications and engagement: BRM identifies customer needs and ensures that the service provider is able to meet these needs with an appropriate catalogue of services: “This process has strong links with service level management,” according to ITIL 2011 Edition. The main purpose of BRM is to capture demand in a business / service context. The BRM process should be used to identify customer need / demand; identify changing business strategy and objectives; and ensure that continual improvement opportunities are being fed in.

4 – Understand required outcomes: The requirements can come from any number of interested parties, such as regulators, professional bodies, suppliers, internal groups, shareholders, and so on. Their objectives and desired outcomes could include improvements in efficiency and effectiveness, cost reduction, standardisation, service quality improvements, greater maturity, and revenue protection or growth. It’s important to identify who gets the benefits as well as what they are.

5 – Define how outcomes will be achieved: According to ITIL 2011, the service management system (SMS) is a “management system to direct and control the service management activities of the service provider.” The SMS includes all service management policies, objective, plans, processes, documentation and resources required for the design, transition, delivery and improvement of services to fulfil the requirements in ISO/IEC 20000-1:2011. Design the SMS and the services which aim to meet the outcomes and requirements. Agree with the customers and other interested parties what you’re going to do and how you’re going to do it – service catalogue, service level agreements and contracts etc.

6 – Change and improvement: Manage change, including requirements; proactively drive improvements; measure satisfaction and deal with complaints.

For the relationship to work, it must be rewarding for both parties – the first law of interpersonal attraction. Encounters can lead to relationships, even possibly a life-long partnership, but both sides have to get something out of it and make a firm commitment.

Matthew Burrows (pictured) is managing director of BSMImpact and a member of the management board of the IT Service Management Forum (itSMF UK).

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in October 2012

 

COMMENTS powered by Disqus  //  Commenting policy