Streamlining Technical Support: A Service Mapping Journey
Due to confidentiality agreements, specific insights, product information and company names have been removed
Problem:
Over the course of many years, the technical systems purchased and built to provide technical support for the employees of a multinational company were disjointed and broken. Domain leaders were unable to identify which system or issue was highest priority for fixing technical support within an organization. This led to duplicating investment in Saas based services, productivity loss when employees were unable to quickly get help and disjointed asset management for hardware.
My role:
Conduct extensive research across multi-channel and multi-touchpoint areas within the technical support organization to create a map of services and identify opportunities that would inform the support team's roadmap.
Approach:
-
Prioritize the services at risk, and verify their significance with the stakeholder
-
Create plan for observation of tasks, and gather list of technicians who are responsible for each task
-
Outline roadmap of activities, questions, and material gathering
-
Observe each action/service (contextual inquiry), and gather data supporting the issues related to said service
-
Categorize each service with the following: Systems, touchpoints, actors, actions, policies
-
Create mapping to show dependencies
UX Research Methodologies Used:
-
User interviews
-
Contextual inquiry
-
Information architecture diagramming
-
System analysis
-
Stakeholder workshop
-
Task Analysis
Outcome 1: Highlight dependencies
I created an ecosystem map that combined the various domains that were responsible with the services that customers needed. The result highlighted the complexities and inefficiencies of trying to keep services segmented by device type or domain.
Note: Due to confidentiality agreements, the image has been altered from its original presentation form to remove specific information.
Outcome 2: Show the gaps in experiences and systems
I created several service blueprints to highlight the visible and invisible aspects of technical support. Due to the fractured ecosystem, multiple maps were created because not a single service had a streamlined team to support.
Note: Due to confidentiality agreements, the image has been altered from its original presentation form to remove specific information.
Outcome 3: Re-define the strategic roadmap
After conducting research and creating the different service maps, I facilitated an 8-hour workshop with the domain leaders for technical support.
STRUCTURE:
-
Discover system duplication and overlapping areas of responsibility
-
Empathize with the issues this causes users by focusing on the journey maps
-
Co-create the remaining sections of service system maps ("ah-ha moments" and "questions")
-
Cluster insights into root issues
-
Prioritize root issues
-
Select top 2 - 3
-
Ladder reasoning for root issues
-
Map ideas into new strategic map for organization
Results
The outcomes of this approach sparked a redesign of several operational systems in 2018. However, I'm unaware of the subsequent developments as I departed from the company.