Saving 60-90 monthly hours
by fixing what users couldn't see
Timeline
1 Month
Client
My role
End to End design
Collaborators
Introduction
This case study focuses on improving Deel’s credit request experience by reducing rejected tickets that created bottlenecks for the RevOps team and confusion for sales reps. Through product improvements, we helped reps take the right actions and restored trust in the crediting system.
My Role
I led this project as the product designer, driving the work from end to end: user research, data analysis, product strategy, prototyping, and final design. Collaborated closely with RevOps, sales stakeholders, and product management.
Impact
+25%
Submission accuracy
-10%
RevOps ticket volume
60-90
Monthly hours saved
Introduction
This case study focuses on improving Deel’s credit request experience by reducing rejected tickets that created bottlenecks for the RevOps team and confusion for sales reps. Through product improvements, we helped reps take the right actions and restored trust in the crediting system.
My Role
I led this project as the product designer, driving the work from end to end: user research, data analysis, product strategy, prototyping, and final design. Collaborated closely with RevOps, sales stakeholders, and product management.
Impact
+25%
Submission accuracy
-10%
RevOps ticket volume
60-90
Monthly hours saved
Saving 60-90 monthly hours by fixing what users couldn't see
Timeline
1 Month
Client
My role
End to End design
Collaborators
Every month, RevOps processed dozens of credit requests. Nothing seemed broken. Just... a little slow. But the tickets kept piling up.
A closer look revealed a surprising signal
much of the volume wasn’t complex edge cases - it was avoidable mistakes. Not because reps were careless, but because they lacked the visibility to get it right.
"I didn’t know we had to check the invoice first - no one told me."
Sarah Johnson
Senior Sales Rep, Deel
There’s a written procedure, but reps don't use it."
Brian Doe
Director, Sales operations
How might we help Sales reps submit credit requests more accurately so they feel confident in the process - while also reducing RevOps ticket load, cutting rework, and improving overall efficiency?
The big constraint
We had to deliver a high-impact solution in under 2 sprints, before the next payment cycle - leaving no room for lengthy discovery or heavy lifts.
Turning invisible system logic into visible, helpful guidance.
I designed targeted validations at key points in the flow to prevent misrouted submissions - without overhauling the entire system.
Validation #1
Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
Validation #2
Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an 'Owner change' request.
I didn’t want to guess. I wanted proof.
Over 3 months of ticket data. I sorted them by category, volume, and resolution time - looking for patterns and anomalies. Two patterns stood out: Request a change (62.5%) and Missing credits (21.8%). Time to dig deeper.
One seemed like a dead-end. The other opened a door.
“Request a change” looked promising at first - but quickly we realized it relied on systemic data inconsistencies. No quick fix. So I focused on Missing credit submissions. And that’s when I noticed something strange...
Over 70% of “missing credit” submissions were getting rejected.
I needed to understand why the system was saying no. To uncover the root cause, I broke down rejection reasons.
Two patterns showed up across all months:
Duplicate/ Already Exists
Unpaid Invoices
These accounted for 40-50% of all rejections. It wasn’t user error.
It was missing context.
Patterns in the data told me what was going wrong but to fix it, i needed to understand how requests were being made.
I mapped the journey. it was too linear.
When I traced how reps interacted with the credit form, it became clear: It was a straight line -no checks, no nudges, no context.
But were users really flying blind?
To stress-test my assumption, I spoke with multiple reps. Their responses confirmed the hidden friction. Turns out, the system wasn’t just silent - it relied on tribal knowledge. New reps were left guessing. Experienced reps were shortcutting. Everyone was operating on assumptions.
“There’s a written procedure, but I just submit and hope it gets through”.
Brian Doe
Sales (New joiner), Deel
“I didn’t know we had to check the invoice first - no one told me”.
Sarah Johnson
Senior Sales Rep, Deel
“I just follow the form. If it lets me submit, I assume everything’s fine”.
Alex Tiran
Account Executive, Deel
It wasn't a form problem, it was a feedback problem.
Reps couldn’t see if a credit already existed or if the invoice was unpaid.
RevOps spent hours each week reviewing invalid requests that could’ve been caught earlier.
A written procedure existed - but new reps didn’t know it, and veterans often ignored it.
70% of credit requests were rejected due to missing context (e.g. invoice status, ownership).
How might we help Sales reps submit credit requests more accurately so they feel confident in the process - while also reducing RevOps ticket load, cutting rework, and improving overall efficiency?
Where’s the Leverage?
Now that we understood the real problem wasn’t a form- it was feedback- we mapped the breakdowns across the user journey and spotted opportunities where a small nudge could drive outsized impact.
Turning insights into plan.
Missing credits weren’t caused by bad reps - but by invisible logic. So I reframed the problem: not how to collect better inputs, but how to design smarter defaults. Using existing data - like invoice status and credit assignments - I mapped a smarter, preventive flow that would catch most mistakes before they’re submitted.
Validation #1
Block unpaid invoice credits
When reps tried to request credits for invoices that hadn’t been paid, this validation explained why they needed to wait. This alone prevented 15% of premature tickets.
Validation #2
Redirect to correct ticket type
When credits already existed under a different rep, this prompt clarified the situation and redirected them to request ownership change instead of submitting a duplicate.
Full journey. Transformed.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
Thoughtful, Not Flashy
💾
Used existing data
Leveraged information already available in the system - no new inputs or integrations required.
📈
High perceived intelligence
Created the feeling that “the system has my back,” building trust and perceived product quality.
⚡
Fast to implement
Minimal engineering effort. The logic lived close to the data, making dev cycles short and clean.
👁️
Invisible until it matters
No extra fields, no friction. These nudges appear only when needed - avoiding form fatigue.
A small change unlocked big wins
+25%
/Submission accuracy
By flagging missing context in real time, reps corrected issues before hitting submit - reducing guesswork and boosting trust.
-10%
/RevOps ticket volume
Smarter submissions meant fewer unnecessary tickets, easing the load on RevOps and speeding up valid requests.
60-90
/Monthly hours saved
Time previously spent reviewing avoidable tickets was reclaimed, letting RevOps focus on higher-value work.
Self reflection
🎉
What surprised me
I was honestly shocked that RevOps and Sales had been working around this issue for months. The data to flag the problem was there all along - but no one surfaced it. It made me realize that even the simplest fixes often stay hidden until someone’s willing to dig through the mud.
✍️
Main lesson
Impact doesn’t always require heavy lifts. Sometimes, a small nudge at the right moment can drive major change.
Thanks for scrolling! 🙏🏻
Every month, RevOps processed dozens of credit requests. Nothing seemed broken. Just... a little slow. But the tickets kept piling up.
A closer look revealed a surprising signal
much of the volume wasn’t complex edge cases - it was avoidable mistakes. Not because reps were careless, but because they lacked the visibility to get it right.
"I didn’t know we had to check the invoice first - no one told me."
Sarah Johnson
Senior Sales Rep, Deel
There’s a written procedure, but reps don't use it."
Brian Doe
Director, Sales operations
How might we help Sales reps submit credit requests more accurately so they feel confident in the process - while also reducing RevOps ticket load, cutting rework, and improving overall efficiency?
The big constraint
We had to deliver a high-impact solution in under 2 sprints, before the next payment cycle - leaving no room for lengthy discovery or heavy lifts.
Turning invisible system logic into visible, helpful guidance.
I designed targeted validations at key points in the flow to prevent misrouted submissions - without overhauling the entire system.
Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an 'Owner change' request.
I didn’t want to guess. I wanted proof.
Over 3 months of ticket data. I sorted them by category, volume, and resolution time - looking for patterns and anomalies. Two patterns stood out: Request a change (62.5%) and Missing credits (21.8%). Time to dig deeper.
One seemed like a dead-end. The other opened a door.
“Request a change” looked promising at first - but quickly we realized it relied on systemic data inconsistencies. No quick fix. So I focused on Missing credit submissions. And that’s when I noticed something strange...
Over 70% of “missing credit” submissions were getting rejected.
I needed to understand why the system was saying no. To uncover the root cause, I broke down rejection reasons.
Two patterns showed up across all months:
Duplicate/ Already Exists
Unpaid Invoices
These accounted for 40-50% of all rejections. It wasn’t user error.
It was missing context.
Patterns in the data told me what was going wrong but to fix it, i needed to understand how requests were being made.
I mapped the journey. it was too linear.
When I traced how reps interacted with the credit form, it became clear: It was a straight line -no checks, no nudges, no context.
But were users really flying blind?
To stress-test my assumption, I spoke with multiple reps. Their responses confirmed the hidden friction. Turns out, the system wasn’t just silent - it relied on tribal knowledge. New reps were left guessing. Experienced reps were shortcutting. Everyone was operating on assumptions.
“There’s a written procedure, but I just submit and hope it gets through”.
Brian Doe
Sales (New joiner), Deel
“I didn’t know we had to check the invoice first - no one told me”.
Sarah Johnson
Senior Sales Rep, Deel
“I just follow the form. If it lets me submit, I assume everything’s fine”.
Alex Tiran
Account Executive, Deel
It wasn't a form problem, it was a feedback problem.
Reps couldn’t see if a credit already existed or if the invoice was unpaid.
RevOps spent hours each week reviewing invalid requests that could’ve been caught earlier.
A written procedure existed - but new reps didn’t know it, and veterans often ignored it.
70% of credit requests were rejected due to missing context (e.g. invoice status, ownership).
How might we help Sales reps submit credit requests more accurately so they feel confident in the process - while also reducing RevOps ticket load, cutting rework, and improving overall efficiency?
Where’s the Leverage?
Now that we understood the real problem wasn’t a form- it was feedback- we mapped the breakdowns across the user journey and spotted opportunities where a small nudge could drive outsized impact.
Turning insights into plan.
Missing credits weren’t caused by bad reps - but by invisible logic. So I reframed the problem: not how to collect better inputs, but how to design smarter defaults. Using existing data - like invoice status and credit assignments - I mapped a smarter, preventive flow that would catch most mistakes before they’re submitted.
Validation #1
Block unpaid invoice credits
When reps tried to request credits for invoices that hadn’t been paid, this validation explained why they needed to wait. This alone prevented 15% of premature tickets.
Validation #2
Redirect to correct ticket type
When credits already existed under a different rep, this prompt clarified the situation and redirected them to request ownership change instead of submitting a duplicate.
Full journey. Transformed.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
1) Input credit details
User initiates a missing credit request. Behind the scenes, the system prepares real-time validations based on invoice and credit data.
2) Validation 1- Invoice unpaid
System instantly checks invoice status. If unpaid, a soft block warns the rep and halts the submission - preventing rejected tickets upfront.
3) Validation 2- Credit already exists
The system cross-checks if the credit is already logged under another rep. If found, it reroutes the user to submit an Owner change request.
4) Review before submission
Reps are redirected to the correct submission type, now pre-filled with relevant context - ensuring cleaner, more accurate requests.
5) Confirmation & reassurance
A clear confirmation closes the loop, reinforcing trust that the request followed the correct path and was submitted successfully.
💾
Used existing data
Leveraged information already available in the system - no new inputs or integrations required.
📈
High perceived intelligence
Created the feeling that “the system has my back,” building trust and perceived product quality.
⚡
Fast to implement
Minimal engineering effort. The logic lived close to the data, making dev cycles short and clean.
👁️
Invisible until it matters
No extra fields, no friction. These nudges appear only when needed - avoiding form fatigue.
Thoughtful, Not Flashy.
A small change unlocked big wins.
+25%
/Submission accuracy
By flagging missing context in real time, reps corrected issues before hitting submit - reducing guesswork and boosting trust.
-10%
/RevOps ticket volume
Smarter submissions meant fewer unnecessary tickets, easing the load on RevOps and speeding up valid requests.
60-90
/Monthly hours saved
Time previously spent reviewing avoidable tickets was reclaimed, letting RevOps focus on higher-value work.
Self reflection
🎉
What surprised me
I was honestly shocked that RevOps and Sales had been working around this issue for months. The data to flag the problem was there all along - but no one surfaced it. It made me realize that even the simplest fixes often stay hidden until someone’s willing to dig through the mud.
✍️
Main lesson
Impact doesn’t always require heavy lifts. Sometimes, a small nudge at the right moment can drive major change.