Courtney Vigo
All work Dense data & 0 → 1

PurchaseIn

The purchasing platform LinkedIn had tried to build for five years. One product, three very different users, each landing exactly where they need to be.

Problem
Purchases started on a form built for IT and HR, then disappeared into email. Requesters skipped Sourcing and couldn't see where their orders were.
Solution
A new purchasing platform with a dashboard for each role, a timeline requesters check themselves, and every message kept inside the request.
Role
Senior product designer, end-to-end design lead. Portfolio refresh made with Claude
Company
LinkedIn, internal tools
Timeline
3 years
Team
Product manager, engineering teams, Procurement and Sourcing stakeholders
Users
~10K requesters, plus the Sourcing and Procurement teams
  • ~$2.8Bof employee spend a year runs through it
  • 47 → 29 daysrequest cycle time, ~38% faster
  • ~43%fewer “Where's my order?” tickets
  • 4.5+CSAT, and it never dipped below

Estimated. About 500–800 tickets a month, including ~$800M a year in data center spend.

  1. 01 Listen Interviews with all three user groups
  2. 02 Map How tickets flow, and where they break
  3. 03 Audit The request form, question by question
  4. 04 Explore Three dashboard ideas
  5. 05 Route The right dashboard at sign-in
  6. 06 Align Weekly meetings with both teams
  7. 07 Ship 47 → 29 days per request
How it came together. Jump to any step.

The problem

LinkedIn’s Source-to-Pay organization had been trying to build a purchasing platform for more than five years. Employees requested purchases on a form built for IT and HR, and everything after that happened over email and spreadsheets: about $2.8B a year running through workarounds, with an average cycle time of 47 days.

A shared spreadsheet Sourcing used to track requests, with duplicates, missing owners and unverified vendors PurchaseIn's Purchase requests page: a phase timeline from Draft to Closed, filters at the top and a sortable table of requests BeforeAfter
Drag to compare. Before: requests arrived by email and were copied into spreadsheets by hand. After: one table every team works from, with the phase of every request.
Before
  • 47 daysaverage cycle time per request
  • ~$2.8Ba year through email and spreadsheets
  • No visibilityfor requesters after they submitted
  • Sourcing skippedso vendors went unchecked
  • 3 user groupswith very different needs, in one process
  • 5+ yearswithout a purchasing tool
Results
Cycle time47 days 29 days
“Where's my order?” tickets−43%
Across ~10K requesters
Vendor checksEvery purchase
Every request goes through Sourcing
CSAT4.5+
Never dipped below, against a goal of 5
Where it started, and where it ended up. Estimated.
3 tools
  1. 1IT & HR form Fill in a purchase form built for IT and HR requests
  2. 2Email Email Procurement the item and the store, skipping Sourcing
  3. 3Email The form lands in a team inbox
  4. 4Spreadsheet Sourcing copies it into a shared spreadsheet by hand
  5. 5Email Back-and-forth emails for missing details
  6. 6Spreadsheet Update the spreadsheet: status, owner, supplier
  7. 7Email The requester emails: “Where's my order?”
  8. 8Spreadsheet Look it up, and fix the duplicate rows
  9. 9Email Reply, and wait for the next follow-up
How a purchase moved before PurchaseIn. Hover or tap a tool to see how often the work jumped between them.
An inbox full of purchase request follow-ups
Every request turned into an email thread, and every thread turned into “Where's my order?”

Research

We first had to learn how tickets flowed today, where they broke down, and how they should flow.

  1. Interview notes on sticky notes, grouped by participant, about how they request and change purchases
    Listen Interviews with all three groups

    Requesters, Sourcing and Procurement, to see how each one works and where requests get stuck.

  2. A flow diagram of the Sourcing part of the ticket lifecycle, with Apttus contract steps and decision points
    Map Flows for the ticket lifecycle

    Every step a ticket takes today, and where it should go instead.

  3. An affinity map of requester feedback, sorted into potential bugs, confusion and usability
    Synthesize Affinity maps for requesters

    Feedback sorted into bugs, confusion and usability, to find what to fix first.

It all starts with the request

Requesters had to answer a confusing set of questions to start. A wrong answer sent the ticket down the wrong path, and the purchase stalled.

The old purchase request form on an IT and HR request site
Before: a General Purchase Request form on the IT and HR help center.
  1. With requesters Audit every question What confuses them, and where do they guess?
  2. With Legal Word it with Legal Question language that is clear and still correct.
  3. With both teams Keep only what's needed Sourcing and Procurement decided what the form needs, and what it doesn't.
How we rebuilt the questions.

Three dashboard ideas

Evolution of dashboards

How should everyone see their requests?

Kanban board with a column per phase: Request, Sourcing, Contracting, Purchasing and Closed
A board of cards by phase

It didn't work for requesters: they thought every card needed them to act. It did show that all three groups needed messaging tied to each request, that everyone loved the alerts, and that a timeline worked, if requesters could read it too.

Explored, not the final direction

Three users, solved at sign-in

Requesters, Sourcing managers and Procurement managers needed very different things. Instead of asking people to pick a view, the back end sorted them into four permission groups, and each person landed on the right dashboard automatically.

Sign inThe back end reads your permission group
  1. RequesterA simple dashboard with only their own requests
  2. Sourcing managerThe Sourcing dashboard, with every subtask and the settings to work tickets
  3. Procurement managerThe Procurement dashboard and settings to work tickets
  4. AdminCan sign in as all threeSo the PM, engineers and I could test every experience end to end
Nobody had to choose a view or wonder whether they were in the right place.
Three dashboards

Where does each person land?

A requester's dashboard: what needs them in a banner, count cards, filters and a table of requests with plain-language status
  • What needs you comes first, with one action
  • Count cards that double as filters
  • Status in plain words, and the next step on every row
  • Search and filters that scale from three requests to hundreds

Each dashboard is built around what that role does all day.

One request, three views

What does each person need from the same ticket?

A requester's request: what's happening in plain words, the phase timeline, the request owner with a message button, and the requirements with their owners
  • Only what matters to them: where it is, who owns it, and what's needed from them
  • A timeline Sourcing and Procurement update, so there's nothing to email about
  • Messages with whoever owns the ticket now

The same request, Workday HR software, as each group sees it.

Watch it

One walkthrough per person, built from my PurchaseIn designs.

Silent walkthroughs with sample data. Each one loads only when you play it.
Read the steps instead
  1. Priya starts a new request from her dashboard.
  2. She says who it's for: herself, People Operations, with Tina Belcher watching.
  3. No contingent workers, a category, and a short description of the welcome kits.
  4. No supplier in mind. Sourcing will find a verified one.
  5. She answers the privacy questions, worded with Legal.
  6. She adds the need-by date, region, delivery location and expected spend.
  7. Attachments are optional. She reviews every answer on one page and submits.
  8. Her dashboard confirms the request and shows its status in plain words.
  9. She opens Workday HR software, which needs her sign-off for Security.

Try it

One working prototype per person. Updates from Security, Apttus and Oracle arrive on their own, a few seconds after they’re possible.

Working prototypes, with sample data, built from my PurchaseIn designs.
Open full screen

Aligning two teams

Procurement and Sourcing each had strong, sometimes conflicting views on how the process should work. I led weekly stakeholder meetings with both teams.

Every week, with both teams
  • Learned what the real goals were
  • Aligned on common goals
  • Defined success together
  • Brought them into the decisions
  • Presented design progress
  • Backed creative decisions with research

The outcome

Before
47 days
PurchaseIn
29 days
Average cycle time per request, drawn to scale. About 38% faster.
  • Email and spreadsheetsOne platform
  • Requesters skipping SourcingVendor checks on every purchase
  • “Where's my order?” emailsA timeline they check themselves
  • One process for everyoneA dashboard for each role
What changed for the people doing the work.

All LinkedIn employee spend, about $2.8B a year, ran through PurchaseIn, built end to end over three years: what Source-to-Pay had pursued for more than five.

  1. Shipped · Shipped PurchaseIn
    • A dashboard for each role
    • A timeline requesters check themselves
    • Chat on every request
    47 → 29 days
What's next.

What I learned

Most of the “Where’s my order?” problem wasn’t about tracking. It was about visibility.

Giving requesters the same timeline the teams were already updating removed thousands of emails without asking anyone to do extra work.