IBM account ​management

Jan - Jul 2023

Overview

A few of IBM’s strategic platforms include Slack for ​internal collaboration and communication, ​Cognitive Support Platform (CSP) for our support ​staff to track tickets and cases, and IBM Sales ​Cloud (ISC, an instance of SalesForce) for our ​sellers. In addition, IBM has thousands of “home-​grown” tools that we utilize.

Our transformation executive aimed to reduce the ​number of home-grown tools by amplifying the ​strategic platforms.

To amplify our strategic platforms, our design team ​decided to investigate account teams (sales) to ​identify motivating factors for collaboration as well ​as why certain tools were used over others. This ​reasoning enabled our broader team (non-design) ​to prioritize and develop capabilities within ​strategic platforms that are applicable to day-to-​day operations of account teams, ultimately driving ​adoption and increasing use of strategic platforms.

IBM Cognitive ​Support Platform

Process

Research: phase 1

After working with our project manager, the design team and I scoped this initiative to understanding which tools ​account teams utilize in their day to day jobs. With our project manager, we conducted a “questions and ​assumptions” activity along with relevant stakeholders to give us, the design team, a jumping off point on areas ​to explore. We then formed hypotheses of areas we wanted to address, defined anticipated outcomes, and ​defined our research activities into 3 pockets to address our hypotheses: “onboarding” interviews to gain ​domain expertise, secondary research to better understand tools and user interviews to gain account teams’ ​perspectives.

For the “onboarding” interviews, we met with 6 different product owners within IBM to learn about IBM’s ​strategic platforms, their intended purpose, priorities for the platforms and future direction.

We then moved into secondary research where we explored strategic platform tools on our own. We then ​compiled a “master list” of tools used by account teams along with their intended persona / IBM role, and ​questions we, the design team, had. This exercise, along with the “questions and assumptions” activity ​completed with stakeholders, gave us enough questions to form an interview guide.

After we had gained domain expertise and felt comfortable talking to account teams, we set up user interviews ​with members of account teams.

After the interviews, the design team and I ​imported each quote into an Excel ​spreadsheet to tag it. After tagging in Excel, ​we then imported all quotes into Mural so we ​could affinity map and find patterns among ​the data.

My team and I were headed into a strategic ​workshop for our team. We needed these ​insights polished so we could share them at ​the workshop and influence the direction for ​our broader team.

Workshop + read out

Our broader transformation team gathered to prioritize work for the remainder of the year in a workshop.

We presented our research in a vignette format. We made 5 vignettes that showed key aspects of the account ​management process. The vignettes included the various roles / personas we interviewed, their processes, pain ​points and tools within each vignette. We also included anonymous quotes from our user research next to each ​vignette to show what “real” account team members were saying.

The team and I were able to influence the prioritization of our team’s direction for remainder of year.

Research: phase 2

Scoping

Post-workshop, our design team ​analyzed the gaps in our ​knowledge in a “gap analysis” ​activity and through another round ​of “questions and assumptions”.

While we felt confident in the ​processes and tools, we lacked a ​sense of specific information that ​account teams were searching ​for, where they expected to find it, ​and why, as well as relationships ​within the account team.

This led to our team creating ​another interview protocol to take ​to account teams to close the ​gaps in our understanding. Not ​only did we hope to do more user ​interviews, but we also wanted to ​do ethnography / contextual ​research to understand how ​account teams operate.

Research

Our team started with user interviews. The interview protocol we created ​focused around collaboration, data within tooling, and relationships within ​the account team. We managed to interview account team members ​within one particular account to better understand their dynamic and ​relationships.

While the user interviews were underway, we started our ethnography / contextual research. I sat in on the ​team’s quarterly planning meeting, their weekly calls and I joined their Slack channels to observe their written ​communication. This allowed our design team to truly observe the account team in how they interacted with one ​another, without influence of us, the design team, or potentailly biased answers in user interviews.

Synthesis

We concluded collecting data from and on the account team after we interviewed all available members and ​sat in on a few weeks’ worth of meetings. We then began synthesis.

We tagged interview transcripts in Excel to easily identify themes. We then imported the Excel tags into Mural ​so we could affinity map. We clustered 600+ sticky notes into themes surrounding tooling, relationships, and ​steps within the account management process.

Outputs for this synthesis included persona cards. Persona cards were necessary to identify the various roles ​within the account team, their needs, pain points and tools.

I also created a backstage process map aligned to IBM’s Universal Experiences (IBM’s common journey ​mapping framework). I aligned each account team role to the phase that they influenced, and articulated what ​actions each role took with or for the customer in each phase.

My team and I then created short ​vignettes to tell stories of the account ​team members in their day to day roles. ​We captured 8 different main ​responsibilities that the account team ​does, and created stories out of those ​while also alluding to the pain points ​experienced and potential opportunities to ​resolve those pain points. These vignettes ​summarized our entire account team ​research we did so far. It was important ​for us to create these vignettes so our ​broader team could empathize with the ​account team members.

Lastly, I created a spreadsheet that documented all of the tools utilized within the account team. This ​spreadsheet highlighted pain points, value proposition, user types and use cases. This gave our team an overall ​view of the most frequently used tools and their pain points.

Validation + read out

After our research and synthesis was complete, we shared our artifacts with the account team to get validation ​on what we heard and what we planned on sharing with the broader team. We had 3 validation sessions with the ​account leadership team to work through our findings, get feedback and iterate.

After validation, the design team and I began our “presentation roadshow”. We gave 7 different presentations to ​various stakeholders and executives within IBM to tell the story of the account teams and how difficult it is to ​complete their jobs given the complexity of tooling. We also gave 2 presentations to external stakeholders ​(product owners) that we identified as opportunities to improve our tooling.

Prioritization

Using the pain points from ​our research, the extended ​team (design + project ​management + product ​management) prioritized ​which opportunities would ​be most beneficial to tackle ​first based on the value to ​users and the value to ​business. After we ​completed the prioritization, ​we validated this with the ​account team that we did ​our research on. This gave ​us confirmation that we were ​advocating for our users.

Execution

After prioritization, our team moved ​to ideation. We collaborated with ​external strategic platform partners ​to ideate solutions to the prioritized ​pain points. We also worked with ​IBM developers to ideate solutions ​that could be implemented without ​the support of strategic partners.

Our team decided to build a Slack ​application that pulls in up-to-date ​information from multiple tools into ​one platform (Slack). This reduces ​the amount of touch points that an ​account team member needs to go ​to and reduces the amount of time ​spent looking for information (both ​of which were major pain points in ​our research). We later infused this ​app with IBM AI (watsonX) which ​does content summarization of ​documents.

The design team and I collaborated closely with developers to represent voice of account teams, emphasizing ​what information is needed within the Slack app.

After the developers created a prototype, we ran feedback sessions with the account team using mock data to ​show what the app would look and feel like. Quotes from the feedback session are below:

“This looks great, like this would be helpful just on its own.”

“I’m excited for this. This would save so much time when joining a new squad.”

“I have an idea, how about I give you all of my accounts so I can play with this?”

Learnings

• IBMers often defaulted to utilizing “path of least resistance” when it came to sharing information, ie Slack ​DMs or Webex calls, instead of creating formalized documents & sharing those out
• Relationships within an account team heavily influence when specific tools and processes are used
  
• Silos and different product teams/orgs create duplication of work and efforts in different tooling – which ​was a huge pain point to the account team
  
• IBMers not using tools to their fullest capabilities today
  

Results

• We influenced the direction our broader transformation team took for 2023
  
• We worked with one of our strategic platform partners to ideate features / functions to add to said platform ​to enhance capabilities and ensure easy use
  
• We worked on Slack apps / APIs to enhance productivity within tool. The tool GA’ed April 2024, and was ​available for use in July 2024
  

Research phase 2 brought to light the relationship aspect of an account team – something not deeply touched ​on in research phase 1. Understanding relationships and behaviors allowed our broader team to understand the ​“why”. This led us to think how we could better design features to be adopted to fit current behavior or design ​processes to change behavior.

While I did not have a hand in the design of the Slack application, our team paved the way through research and ​service design for the app to exist.