Opening your systems to build a closer relationship
Over the last two years, our customer relationships have grown to be more online, and this is a trend that looks like it will continue and become more critical in the future. This could be something as simple as logging in to your Amazon account and seeing the location of the delivery van, so you can decide if you have time to nip out to the shop before your delivery arrives.
In opening your systems to your customers or even internal groups, there are several considerations:
- What is the purpose of the interaction?
- What is the risk of this information being available externally?
- How much information should they see at each stage of interaction?
- What information can they modify, and will it require validation?
- What controls need to be put in-place to make sure the user is acting within their authority?
What is the purpose of the interaction?
Clarity on the interaction is key to planning what's visible and what can be done by the user.
Let’s look at a few examples:
Following up on a customer support question
Firstly, the information or communication should only be restricted to one, or at the very most two external parties. What they need to see would be summarised and in most cases not contain any detail of the internal communications that are connected with the case.
How could this be delivered?
- By restricting the case/communication to include only the relevant parties, rendering the other cases invisible to the external user.
- Providing summaries that are produced by status fields or targeted narratives created by the agents dealing with the case and hiding all other data from the external user.
This shows two levels of data: the external level, which is summarised and allows discussion with the agent; the second is the information that the agent used to decide on what to do with the case, this may include third-party info managed by the agent.
These restrictions would allow for a normal case to progress to a satisfactory conclusion without any of the people involved having to meet or be in the same location.
If there's a complaint then the case may have to be exculpated, and we've created a new layer of data, which could be viewed by a manager or auditor depending on the organisation. This user will need to be able to see the two previous layers of information and record their thoughts/findings as they work through it, this creates the third layer of information.
The third layer in most cases won't be available to the agent apart from a summary (in the same way the agent's information is only available to the client in a summarised form).
Layers of information – Narrative
This explanation introduces the concept of layers (or views) of information. Let’s try to explain exactly what we mean. Each individual is interacting with the case for different purposes, and this affects the information they need to see or input to gain value from it.
As for the agent answering the quire, they may have to gather and use information from the logistic team, accounts, and many other areas and then condense this into something meaningful for the client.
It's this curation of several sources of information that allows the customer to feel that they have an answer, and they can fully understand without having details that may expose the company.
At a basic level, we can look at the layering of information as a way to simplify interactions between the different users.
Layers of information – Security
The other reason for layering information is to provide a level of security and stop users from having information in cases that isn't relevant to them; in the example above, the complaint would be dealt with by another member of staff, and their thoughts are hidden from the initial agent until a decision has been made.
In cases where there's the potential for fraud, this segregation becomes even more important, as it means that the individual being reviewed is unaware of the information being gathered.
Available functionality
The other area where we may want to limit a user's abilities is in the system functionality that they can use, for example, a client may be able to create or close a case and message the agent. The agent can in most situations update individual data elements that show the current status of the case.
The restriction of functionality is most often used within an organisation to make sure that people can only undertake actions that they have authority over. Required decisions are only made/approved by someone with the right level of authority.
Mapping it all out
When you start to map out the different users and the layers and functionality they have, it's important to do this from a persona that your assumptions can be tested against. See blog on personas.
Let's look at how we can work with you to layer the data and bring your customers and staff into a closer way of working.
Take a look at our Workflow and case management solutions to see where we can help.
