The ‘Pitfall’

Throughout the years, we have seen multiple customers facing issues when they want to expand their Customer Service Application to new business areas because they already have customized the very core of their Customer Service Application. 

How is that?

When implementing Customer Service Management, it is crucial to acknowledge that each business area or even department has its own processes and ways of working. Suppose you don’t keep this in mind during implementation. In that case, you might end up configuring and customizing the entire application to only support one specific business area and lose your agility to scale.

What you should avoid

The core of Customer Service Management is cases, and the base table for that is called ‘sn_customerservice_case.’ If you modify the configuration for this table, such as:

• Adding new fields to support a specific business area need
• Changing the state flows of the process
• Modifying/adding categorizes that only apply to a business-specific area
• Changing process logic to comply with business-specific procedures.

You will likely end up losing your ability to onboard other business areas. 

Why? 

If you modify the base table, you will no longer have the opportunity to extend the base table without retaining the already configured/customized business logic, states flows, fields, etc.

Reverting or fighting against existing logic that contradicts your new requirements and logic that shouldn’t be there in the first place is a tiresome and unnecessary battle, which is why this blog post exists and why we want to avoid it.

An important consideration before implementation

When you decide to implement CSM, you should ask yourself the following:

• Do we have multiple business areas that we need to onboard to CSM? Not just now, but also further down the road?
• Do we need to configure or customize the ‘Out of the box’ behavior of cases? E.g., Adding new fields to the case form, modifying state flows, etc.
• Are there different processes based on products and services that the company supports?
• Do the fulfillers of cases need different experiences and guidance for each issue type?

If the answer is yes to any of the above, or even if the answer is that you are unsure, you should consider leveraging Customer Service “Case types.”

What are Case Types?

A case type is a collection of data, processes, UI, and flow logic that is needed to support and resolve a specific type of issue or request. Take the banking industry as an example. Within a bank, there could be multiple types of cases:

• Loan processing
• Complaints management
• Credit card processing
• etc.

Each of these case types could require its own workflows, processes, and UI experience that drives the end-to-end flow from the customers’ case submittal to resolution.

When do you need Case Types?

Case types are needed when an organization has different processes for supporting customers across multiple departments, business units, or products. Case types help separate these processes through separate applications to support each process. 

Note: The picture applies to the Paris release, but the same counts for newer releases.

How do you create Case Types? 

You create a case type by extending the CSM case table (sn_customerservice_case) to create a case application specific to a customer process, e.g., claims, complaints, onboarding, etc. For each case type, you create a table that extends the Case table and then configure items, such as business rules and client scripts, that drive customer issues of this type from creation to resolution.Feel free to contact us if you plan to do a Customer Service Management implementation, or need to implement Case types.