Lead Assignment Rule Logs
Making automated lead routing transparent, explainable, and actionable.
Duration: 6 MOnths
COMPANY
Tekion Corp
ROLE
Product Design • IA
SCOPE
UX strategy · IA · Interaction · Launch
PARTNERS
Product • Engineering • Dealership Stakeholders
ABOUT TEKION
Tekion is a Silicon Valley based automotive retail technology company that launched the Automotive Retail Cloud (ARC), the industry’s first cloud-native DMS. It combines DMS, CRM, digital retail, and AI-driven analytics into a single platform to deliver a seamless, customer-centric dealership experience.
PROJECT INFO
Bringing transparency to complex lead assignment automation by helping dealerships understand exactly how leads are routed, reassigned, and distributed across their sales teams.
MY CONTRIBUTIONS
Led UX strategy and information architecture.
Defined diagnostic workflows for assignment investigations.
Partnered with Support, Product, and Engineering teams.
Designed multi-level drill-down experiences for complex rule evaluation.
Created scalable patterns for assignment transparency and auditing.
01 / PROBLEM
The system knew why. The user didn't.
Lead Assignment Rules could evaluate qualification, schedules, relationships, round-robin logic, availability, acceptance, and escalation but users mainly saw the final assignee.
01
What Happened?
Dealerships could see the result, but not the sequence of decisions that produced it.
02
Why did it happen?
Users struggled to determine which rule or condition qualified or disqualified a lead.
03
What changed?
User availability, lead acceptance, and reassignment settings could alter the outcome without an obvious explanation.
02 / REFRAME
One system. Three levels of investigation.
The key design move was separating diagnostic depth from diagnostic access. Users could start with a surface-level distribution view and progressively move into an individual lead's execution history only when needed.
See the Signal
How are leads, assignees, and rules performing?
Find the case
Which lead, rule, or assignee needs investigation?
Explain the decision
What exactly happened and why?
This framing lets the same feature serve everyday dealership monitoring and deeper Support-style diagnosis without forcing every user into the most complex view.
03 / PRODUCT ARCHITECTURE
Progressive disclosure, from signal to explanation.
We created two views – simple list view and detailed view. Three simple list answer "where is the problem?" The detailed view log answers "what exactly happened?"
LEVEL 01 • LEAD DISTRIBUTION
Start with the individual lead.
The original experience: a searchable history of lead outcomes, assignment, reassignment, and the rule involved
ANSWERS
What happened to this specific lead?
SIGNALS
Assigned · Reassigned · Not assigned · Rule
NEXT STEPS
Open the detailed execution log.
LEVEL 02 • ASSIGNEE DISTRIBUTION
Understand who is receiving the leads.
Introduced to answer a dealership-level question: are eligible leads actually reaching the people who can receive them?
ANSWERS
Which assignees are receiving or missing eligible leads?
SIGNALS
Eligible · Assigned · Missed · Miss reasons
NEXT STEPS
Investigate availability or assignment settings.
LEVEL 03 • RULE DISTRIBUTION
See which rules are driving the outcome.
Introduced to give managers a high-level view of rule effectiveness and the most common reasons leads were not assigned.
ANSWERS
Which rules have the biggest assignment gaps?
SIGNALS
Qualified · Assigned · Not assigned · Success rate
NEXT STEPS
Drill into a specific rule or reason.
04 / DESIGN EVOLUTION
From Signal to Explaination
We evolved the experience from a support-dependent investigation into a progressive diagnostic workflow, helping dealerships move from spotting a distribution issue to understanding the exact decision behind it.
BEFORE
A support-dependent investigation
User sees a missed or unexpected assignment.
No clear surface-level explanation.
Support investigates configuration and user settings.
Answer requires product knowledge.
AFTER
A progressive diagnostic path
Spot an issue in distribution metrics.
Identify the affected rule, assignee, or lead.
Open the execution log when needed.
Inspect the exact decision and rule state.
05 / TURNING QUESTIONS INTO EXPERIENCES
One assignment problem. Multiple ways to investigate.
Dealerships don't always start an investigation from the same place. We designed three views around the questions they ask most often, then provided a deeper execution view when they need to understand the exact decision.
WHAT USERS WANT TO KNOW
EXPERIENCE
01
What happened to this lead?
Lead Distribution
02
Who is receiving or missing leads?
Assignee Distribution
03
Which rules are creating gaps?
Rule Distribution
04
Why did this assignment happen?
Rule Execution
DESIGN CHALLENGE
How do we make a complex automation system understandable without exposing all of its complexity upfront?
DESIGN DESCISION
Progressive disclosure.
Give users the summary they need first. Let them drill into execution details only when they need to explain a specific outcome.
06 / MAKING AUTOMATION EXPLAINABLE
When a surface-level view isn't enough.
For complex cases, the user can move from the distribution views into an individual assignment and reconstruct the system's decision.
DETAILED EXECUTION LOG
Detailed diagnostic view: use this after the three simplified views to show how the experience supports deeper investigation.
01 · Outcome Summary
Answers what happened at a glance: status, rule, assignee, assignment time, and reassignment.
02 · Execution Trace
Shows each decision and reassignment event in a chronological flow.
03 · Processed Rule
Displays the rule and conditions evaluated during execution—not simply today's configuration.
07 / PRESERVING THE DESCISION
Preserving the decision at execution time.
Rules change. Past decisions shouldn't become mysterious.
A key design requirement was preserving the rule state used when the assignment happened—not just showing the current rule configuration.
This makes the log an explainable audit trail rather than a simple activity history.
RULE AT EXECUTION
Department = RetailSource = KBBMake = MazdaDay = TuesdayTime = 8:00 AM–8:00 PM→ Qualification: PASSED→ Assignment: ROUND ROBIN
08 / VALIDATING IN THE REAL WORKFLOW
We tested the diagnosis where the problems actually happened.
We didn't release the Rule Execution Log directly to dealerships. We first validated the experience with the teams already investigating assignment issues every day, then used real production cases to refine the experience and uncover gaps in the underlying assignment logic.
01 • INTERNAL VALIDATION
ISM + PSM feedback
Before involving Support, we ran internal demos with ISMs and Product Specialists to validate whether the investigation flow made sense.
Could they understand the assignment outcome?
Was information presented in the right order?
Could they find the important rule and assignment details?
WHAT CHANGED
Refined the UI, information hierarchy, and presentation of assignment details.
02 • SUPPORT PILOT
Real investigation
Support became our first real validation group because they were already resolving recurring assignment questions.
Logged assignment issues in a shared Excel tracker.
Captured the rule and what the log revealed.
Tracked whether issues were configuration or system related.
Began tracking ticket volume and diagnostic time.
WHAT CHANGED
Validated the workflow against real investigation scenarios instead of relying only on demo feedback.
03 • DEALERSHIP LAUNCH
Production usage
Once refined, the experience was made available to dealership users. Production usage revealed issues that weren't visible during design validation alone.
Dealerships could identify rule-configuration problems.
Unexpected assignment behavior became traceable.
Support and Engineering gained evidence to investigate deeper system issues.
WHAT CHANGED
The log became both a user-facing diagnostic tool and a feedback mechanism for the assignment system.
PRODUCTION DISCOVERY
The logs uncovered hidden rule-engine issues.
The experience didn't just validate the UI. It exposed problems in the underlying assignment logic that were previously difficult to diagnose.
Schedule & availability
Execution history exposed cases where user schedules and availability affected selection in unexpected ways.
Round-robin selection
Unexpected assignment behavior revealed gaps in how the round-robin algorithm selected users.
A NEW DIAGNOSTIC FEEDBACK LOOP
What we measured: We began tracking assignment-related tickets and diagnostic time to quantify the operational impact. At this stage, we don't have enough reliable data to claim a specific reduction, so the case study intentionally does not manufacture a metric.
09 / WHAT CHANGES FOR THE DEALERSHIP
From “Why did this happen?” to “Where is the problem?”
The biggest outcome wasn't another log. It was giving dealerships a path from a distribution signal to a specific explanation without starting with the most complex view.
01 • USER IMPACT
Faster issue discovery
Users can scan lead, assignee, and rule distribution to identify where assignment gaps are occurring before investigating individual records.
02 • OPERATIONAL IMPACT
Less dependency on Support
Common questions about missed or unexpected assignments can be answered closer to the dealership workflow instead of requiring manual investigation.
03 • PRODUCT IMPACT
A scalable diagnostic foundation
The pattern creates a reusable way to explain complex automation: summarize the signal, narrow the scope, then expose execution-level reasoning.
10 / WHAT CHANGED
The biggest outcome wasn't another log. It was giving dealerships a path from a distribution signal to a specific explanation without starting with the most complex view.
BEFORE
Assignment was a black box
Users saw outcomes but had limited visibility into the factors behind them.
DESIGN SHIFT
Make the system inspectable
Organize information around the questions users ask: what happened, who was affected, which rule was involved, and why.
AFTER
Summary → diagnosis → explanation
Dealership users can start broad and go deeper only when the situation requires it.
11 / WHAT I LEARNED
Complex systems don't need simpler logic. They need better explanations.
The design challenge wasn't hiding automation complexity. It was organizing that complexity around the questions users actually ask—and giving them a path from a high-level signal to a defensible explanation.
Back to Work
©
Mrunali Ogriwala
Powered by teas and desserts!