Agent Experience

This case study is password protected

Incorrect password
← All work
Agent Experience

Optimizing a major platform investment through constraint-led design. A blueprint for what third-party tools can do for a business.

Role Lead Product Designer
Users 500 CS Agents
Time Reduced 1 min per call
Monthly Savings $6k via chatbot
Agent Experience widget
A major tool not working as expected

Sprinklr is a customer experience platform. Shipt's customer service team, called the X-Team, uses it to handle calls, chats, and emails from members, shoppers, and delivery drivers.

The company had invested heavily in Sprinklr as a replacement for their previous tool. Three months after launch it was not yielding the results expected. I was brought in to find out why.

Sprinklr agent screen before integration
The tool did not know enough

I started by shadowing agents during live sessions. What I found was not a broken tool. It was a tool that did not know enough.

X-Team performance is measured on speed. Handle time affects their metrics and their pay. So agents had built their own workarounds. Admin, Shipt's internal tool, was always open in a separate tab because almost everything they needed during a call lived there, not in Sprinklr.

When I presented to directors and VPs, I showed them a matrix mapping tool adoption against usage frequency. The goal state was clear: all agents using Sprinklr, all the time. But based on what I observed during shadow sessions, I was able to plot where we actually were. Most agents were using it partially, working around it for anything that required speed. The matrix made the gap visible in a way that a list of problems could not.

Feature matrix discovery artifact

The gap came down to a few things, some of which they were already aware of and some they weren't.

01
Agents still had to live in a separate tool
To get any meaningful context before a call, agents had to open Admin, Shipt's internal tool, in a separate tab. Member details, order history, shopper payment info. None of it was in Sprinklr. So before they could even start helping, they were already context switching.
02
Canned responses lived in a Google Doc
Agents brought this up themselves. The pre-written replies they relied on for speed were so hard to find inside Sprinklr that they had copied them into a Google Doc and used Control F to search. Stakeholders knew agents used canned responses. They did not know they were not using them from inside the tool.
03
Wrap up codes added time after every case
Agents flagged this too. At the end of each interaction they had to fill out case summary codes. Too many questions, nothing pre-selected, and the case timer kept running until wrap up was complete. Stakeholders knew the codes existed. They had not realized how much time the process was costing.
Designing inside someone else's platform

Working inside Sprinklr meant we could not use our full design system. Their components, their visual language. We had access to a specific slice of the codebase and not much more. So instead of leading with UI, we led with information. What we surfaced, how we prioritized it, and in what order became the design. That constraint pushed us to be more intentional than we might have been otherwise.

This shifted our entire design focus. We were not designing UI. We were designing UX. Readability, cognitive load, ease of use, and accessibility became the primary design decisions because they were the ones we actually owned.

What we owned
  • Information architecture
  • What data to surface and in what order
  • Interaction patterns and flows
  • Cognitive load decisions
  • Accessibility
What Sprinklr locked
  • Button styles and colors
  • Typography and fonts
  • Overall visual language
  • Direct external URL navigation
A widget that brought admin into the room

The solution was a widget embedded in the active case view. When a call or chat came in, Sprinklr would detect who the caller was. If there were multiple account matches, the widget listed them so the agent could verify quickly with the caller. Faster than searching admin and navigating a results page.

Widget close-up Widget in context on screen
Research that outlived the project

The discovery work for this project ended up informing a roadmap that was not ours.

The wrap up code problem led to an idea I brought to engineering. The transcript and chat data already existed. We could use behavioral pattern detection to pre-select the most likely wrap up codes, leaving agents to confirm or edit rather than fill from scratch. This was our first experimentation with AI at Shipt, before the company had a formal AI feature strategy. It was born from a simple observation. The data was already there. We just needed to use it.

The canned response problem, the timestamp problem, and several others I surfaced became officially roadmapped features for the X-Team product. A year and a half later that team still reaches out to reference the original research when they are building new features.

Agent journey map across voice, chat, and email Shipt Livechat chatbot
Returns on the investment
1 min
Reduced per call across all 500 agents
$0.80
Cost per minute saved on every call
500
Fewer human-handled cases per month via chatbot
$6k
Monthly cost reduction from chatbot and IVR parity

The Sprinklr investment started showing returns. X-Team directors and leaders cited cost reduction as a direct goal met. The research I did in those first three months became the foundation for two teams' roadmaps, not one.

A blueprint, not just a fix

The tool was not working as expected and we found a way to optimize it. But more than that we set a blueprint for what the integration could become, with a clear vision and actionable next steps already in motion.

Designing inside someone else's platform forced a clarity that is easy to lose when you own everything. We could not hide behind visual decisions. Every choice had to earn its place through usefulness alone.

← All work Next: MonetizeNow →