“I got 99 problems… and I need you to solve all of them.” I love to hear this from a client. It’s a mental trigger that gets my attention and starts the gears whirring in my mind. “What’s wrong with the system?”, “why does the integration not work?”. It’s the beginning and end of everything I do as a consultant, and it all starts with asking the right questions (I’m NOT necessarily talking requirement gathering though for stories— I’m referring to before you buy the product)

To effectively assist a Customer Service Management (CSM) client in really uncovering pain points, adept questioning plays a pivotal role. It is imperative to delve beyond the surface and inquire about not only their foundational data setup, but also to uncover their challenges and points of concern around other business processes, departments, integrations and even enterprise planned projects (because a project can provide insight into a pain point they may not even recognize yet, or see coming).

While certain challenges might transcend software solutions (i.e. they are business process issues), it is worth noting that most challenges articulated by clients are able to be addressed with the software.

I highly recommend signing up for the CSM Fundamentals Course with ServiceNow Learning if you are working with CSM.

Case Study PDF for examples related to CSM business scenarios you may encounter.

Common Pain points CSM can solve:

• A customer would contact customer service about an issue and the agent would have no visibility into backend problems causing a service disruption
• Customer service agents were experiencing the ‘swivel chair challenge’ working within multiple systems (aka they had to input the same data into multiple systems)
• Customer support received too many simple requests for information, and for minor issue support, resulting in expensive resources being used for basic services. It also meant they were sometimes not readily available for proactive work or when major issues occur
• The incident process was being used to log ‘cases’ making it difficult to separate incidents and cases for reporting purposes
• Customer service agents had no easy way to review customer historical case and product data
• Customers experienced inconsistent levels of quality in the services provided
• Support staff had used too many disconnected and disparate delivery systems, many of them legacy systems that were challenging and costly to maintain
• Support staff had limited visibility into video network issues and reporting
• There was no real-time sharing of data

But wait, what are other things to ask about up front?

As a consultant, be it sales or technical, in order to sell a product you MUST know the applications foundational tables, which columns are required and how the tables are used in the ServiceNow platform.

First and foremost with the pain points above, you need to ask about the systems and setups AROUND the ServiceNow parts. Not just integration questions – but the dirty details regarding if their foundational data is unified across the enterprise in the scenario they are trying to set up — or not. If you know table and column [x] are required for it, and then you ask their AD employee ‘does this all match’ and that person says ‘sorta’ or ‘no’ or preferably ‘yes’ — then you know how to proceed.

Scenario Example: You are assigned to a company that acquires a lot of other companies, and find out that corporate doesn’t enforce everyone using the same HR system or fields (because maybe they are subsidiaries or need to remain as a semi-independent group). However, the main ‘corporate’ company wants ‘corporate’ IT to support everyone (including shadow IT departments) — well, you can very easily end up with a client who has REQUIRED but mismatched foundational user data being pushed to AD and loaded into ServiceNow. What seems like an overly detailed question being asked up front turns out to save your co-workers, and the business, from a massive headache. You have now helped the business to identify additional internal business work that must be done first in order for the ServiceNow product to work the way the corporate business executives want it to.

Product Example: in FSM the ‘location’ field must be unified across the enterprise or potentially even scenarios in CSM — if an address you need to call forth and use to identify a case location for can’t be used because some groups use 123 Main St., some may just require 123 Main, some use another field altogether for some legacy reason — or worse — some don’t use it at all, well suddenly you are in a pickle because it is not unified and the product won’t work the way it was pitched and sold to them.

Lesson: ask questions up front about the clients needs. Double check the sales reps (because I’m not sure they always ask the right questions) and make sure before anyone agrees to a sale, that the product can actually work how you — as the business owner — expect it to in your business environment.