The setup only vendor could finish
Turned a data-import setup Tealium's own team finished 86% of the time into one customers ran themselves.
Tealium AudienceStream · Offline data ingestion · Shipped in 2012
Team: Lead Product Designer · Product Designer · VP of Engineering · Director of Software Engineering · 2 Digital Strategists
Tools: Sketch · InVision · Lucidchart
Duration: 9 months
Methods: Heuristic evaluation · Competitive analysis · User interviews · Usability testing · Journey map · Personas & HMW · Wireframing & prototyping
1. The problem nobody owned
A major retailer with 3,500+ stores asked for a way to bring their offline data into Tealium automatically, as CSV files from a storage bucket. We built it for them, and it quietly became the product's answer for every customer with offline data. Nobody owned the question of whether a customer could actually operate it. So our digital strategists absorbed the gap, spending their hours on manual setup work for every account.
2. What I saw
Based on my access to telemetry data, I pulled task completion and abandonment from our telemetry data, then split completion by who completed it. Tealium's team had done 86%. No single customer accounted for more than 4%.
Because white-glove service was normal then, that number read as good service rather than a product that didn't work.
During interviews, there were five themes for blockers:
- Tealium nomenclature
- Too many options on one screen
- Dependency on documentation and training
- No manual on-demand upload
- No path for users without repository credentials
The data ingestion mess
3. Who I pulled in
There were two digital strategists who were burdened with this problem by doing manual setups more frequent than they expected. I brought in the VP of Engineering and the Director of Digital Strategy, along with an additional product designer later on for support.
Based on user interviews, I had created a journey map to share so everyone was looking at the same big picture of pain points our users were experiencing.
At the time both the VP of Engineering (acting product manager) and the Director of Digital Strategy had strong opinions for what features the product needs to support. So we ran a design sprint across digital strategy, community, engineering, and design to get alignment on top requirements.
When we disagreed about where to start, or in situations where Engineering was pushing for solutions that did not map to user need, rapid research with users make that clear. The sprint also opened the room for others to constructively chime in.
The architecture that we finalized on after many iterations
4. What changed
- Shipped one File Import flow in place of six separate screens and tools, with fault detection built-in, offline data made optional, and manual upload for users without repository credentials
- Turned customer-completed setups from 14% to 78% within six months, while white-glove service was still on offer
- Cut helpdesk tickets 64%
- Returned more than 75% of the digital strategists' setup hours to focus on other work.
5. What I'd tell a leader facing the same thing
A completion metric that doesn't record who completed the work will hide a services dependency indefinitely. Features built for one customer generalize on paper and fail in the field. The tell is which accounts still need hand-holding. Even when timing isn't ideal, rapid prototyping with user validation can still shape outcomes.
