Derek Daley

Home > Modernizing Support Tracking Tools

The Kroger Logo

Modernizing Support Tracking Tools

Role: Product Designer

Chapters:
    Building Empathy & Understanding
    Early Insights
    Designing a Feedback Loop for Trust
    Solving for the Future
    What I've Learned


Backstory

In November of 2020 I was promoted to Associate Product Designer in the Associate Experiences pillar (“AX” for short). Associate Experiences range from In-Store applications, all the way to support ticketing (CRM) software. I was assigned to be a Product Design partner for Support Tracking Tools, essentially the software that our Agents use to create tickets when a customer’s angry they received spoiled milk in their grocery delivery order.

We manage all this through our CRM vendor, Astute Agent. An important note is that the program we leverage is via a third-party vendor. This creates an abundance of interesting, sometimes frustrating scenarios, where understanding capabilities is important, and communication is key.



Upon getting settled into the role, a couple of things became quickly apparent.
Astute Agent has been used for 5+ years with minimal improvements.
There’s never been a product partner for this product.
(Make these two points more visual, possibly with some color)

One thing I had to learn early on is that traditionally Associate Experiences at Kroger value consistency foremost. “If it isn’t broke don’t fix it” was the motto. However, With the success of our grocery pickup and delivery applications (covid!), the business saw an opportunity to bring these product-led ways of working into other parts of the business, and that's why I accepted a position in the new product frontier of Associate Experiences! So I wanted to get to work.


Building Empathy & Understanding

So I began doing everything I could to understand how the program worked and build empathy for my users, the agents. It was interesting learning about how Agents perceived Astute Agent and what needs Astute Agent filled in the ecosystem of our different programs related to Customer Support. I quickly realized that this software was much more technical than I had worked on previously, and I saw this as a great opportunity to grow myself both technically, and mentally as a Designer.

I began to build out a base of design artifacts that would help me establish a foundation of knowledge for the space. Through Flowcharts, Ecosystem Maps, Shadowing Agents, monthly Agent user interviews, and Personas, I started to build a set of Qualitative and Quantitative Data that I could leverage for my understanding, and the future.
(Possibly create a graphic here with Flow Chart / Ecosystem Map / Agent Interviews Icon)


Early Insights


1) Agents have never had a way to give feedback past “Button has stopped working”. Because of this, Agents have a low trust built up with management. They don’t feel as though they are part of anything, besides just doing their job and clocking out for the day.

2) The program itself is outdated and unoptimized. From my talks with stakeholders as well as agents, it became clear that Astute Agent has changed only slightly in 10+ years. I learned that this is mainly because we hosted the software on-prem (locally, on our own servers) due to the high amounts of customer data going through the software. Security is at the forefront of every discussion in this domain, and it also is the main reason Associate Applications typically innovate much slower than customer-facing applications.

These were the main two things I had to tackle in my first year with the software, and I started working with my Product Manager to find solutions right away.


Designing A Feedback Loop That Builds Trust


Through a quick discovery we focused on finding a way to gather feedback more efficiently, allowing our agents to feel heard in the process.

We developed a monthly “sprint” plan which involved engaging managers and knowledge stakeholders (the main two POC’s for our Agents), gathering feedback, and acting on the feedback in whatever ways we could, while simultaneously allowing our agents to see the feedback we are gathering so they can feel heard.



The issue this solves is that a lot of times in the past feedback would be gathered and then either forgotten about or never acted upon, oftentimes both. In reality, sharing the feedback back with the agents was a way to give us more time to solve these issues at a higher level, all while starting to build that trust with them. Our goal was, in each “loop”, more and more trust would be built, and we could see that through increased engagement with our feedback portal that we built out in collaboration with our Qualtrics team.

The business value we identified as the key goal of this process was to open up better avenues of communication between the business and our agents so that we could identify better opportunities to save our agents (and customers!) time, and ultimately the business money.

Results:
Initially, we saw a huge initial surge in feedback after we engaged managers and other stakeholders, with 300 responses in two weeks of the qualtrics portal being live. This was great and a sign that Agents wanted to be heard, they had just never had the applicable portals to be able to do so without complaining to a manager. We’ve seen a drop-off since those initial first two weeks, but this was to be expected. After we let the data settle a bit, we’ve been seeing a month over month steady improvement for the last 6 months from roughly 5-10 weekly responses, up to 15-20 as of now.

But now came the harder part, acting on the data we were gathering.


Solving for the Future


Now that we had an abundance of feedback to work from, we got to work affinity mapping, trying to identify the major themes and plotting them on impact vs effort charts to determine some things we could tackle first.

Quickly, we identified the major roadblock we would run into.

We were running a 5-year-old version of the software due to all the security implementations required around a company of our size. This caused issues because Astute Agent, while they did support us and we could make changes to the software, it was a tall task to work with them. We had to: get the funding, get approval, get a contract written up etc. etc. All if we wanted to change ONE button. ONE sentence. ONE word. This is something I had never dealt with before, but something that would help me develop one of the most important skills I’ve ever developed, which is communication.

Through talks with my PM about the issues we were running into, we scheduled talks with our business stakeholders and stakeholders over at Astute. We found that if we could convince the business, there were opportunities to get Astute upgraded to their most recently updated cloud-based solution which would provide our agents with an abundance of new features as well as a more optimized interface. Perhaps most importantly it would be easier to update for our businesses' own specific needs. Our goal was not just to fix the issues we were seeing with Astute Agent, but to position ourselves so that our solution to the issue looked to the future, not just the present.

My PM and I began the push for this, talking to development and product stakeholders to understand their frustrations with the current Astute product, and then we organized and took these talks to buisness stakeholders who could drive change. Surprisingly it wasn't as difficult to convince the business to push for this change. Everyone knew about the frustrations around our on-prem version of Astute Agent, however, in classic Associate Experience style, nobody wanted (or tried) to actively try and fix the issue, as that's just the way it had been for 5+ years. This is such a foreign concept to me as a designer who just wanted to get to work, iterate, and build better products.
[Make a graphic of a timeline.]

We’re currently past contract negotiations and onto implementation which should be completed near the end of Q1 22’. There are a ton of security concerns when switching from a locally hosted on-prem service to a cloud-based service, but talks between dev teams are ongoing and I’m more or less sitting back playing a support role.

Currently, I'm revisiting the design artifacts I’ve built out and polishing them up, conducting user interviews so we have a clear perspective of agent wants and needs in the current on-prem AA version so that once the upgrade has been completed, we can check to see what issues the upgrade has fixed, as well as what new opportunities there are to make our agents lives easier when we hit the ground running in Q2.


What I've Learned


Overall, this experience (so far) has taught me a lot more about the technical, communication-based side of product design. Prior, I had worked on much faster sprint-based teams where we iterated on products quickly. But what do you do when your product hasn't established a foundation to get to the point where you can iterate? This has taught me those lessons which I feel are so important to understand a total product life-cycle, and for that I'm thankful. I'm looking forward to following through with everything talked about above and continuing to modernize a vital component of the Kroger support software landscape.





   Daleyvisuals@gmail.com 

Back To Home