Gett - Enterprise Booker Request Management
Large workflow
Enterprise scale
Web
B2B
Mobility
Redesigned the authorization workflow to help corporate bookers identify employees, track requests, and recover expired permissions. Improved key metrics by 25-40%.
Product: Gett Web Platform | Team: Gett B2B | Role: Product Designer | Timeline: Jun - Aug 2023
Context
Gett Web Platform is a service for ground transportation.
Product context
Gett Web platform allows authorized employees, referred to as bookers, to arrange corporate rides for other people within their organization.
Because booking on behalf of another employee may expose sensitive information, including saved addresses and previous trip details, bookers cannot automatically arrange rides for every employee in the company.
Before booking for a passenger, the booker must send an authorization request. The employee can then approve or decline it. Once approved, the employee is added to the list of passengers the booker is permitted to book for.
Business Context
Large corporate accounts often rely on bookers to coordinate transportation for multiple employees. As organizations grew and more booking permissions were created, managing authorization requests became increasingly difficult.
The existing solution had originally been designed as a compact section within the booker profile. It worked reasonably well when users managed only a few passengers, but it did not scale to organizations with dozens or hundreds of employees.
This created several business risks:
bookers could send requests to wrong employees because bookers don’t see the email and division;
expired or declined requests were difficult to recover;
users sometimes needed support assistance to understand request statuses;
authorization friction delayed future ride bookings;
the experience reduced the perceived reliability of the enterprise product.
The project was initiated to make authorization management more transparent, scalable, and suitable for larger corporate accounts.
Constraints
| Constraint | Impact on the solution |
|---|---|
| Existing permission model | The redesign had to preserve the current employee consent and authorization logic |
| Sensitive passenger data | Access could only be granted after explicit employee approval |
| Legacy profile architecture | The previous experience was embedded inside a narrow sidebar |
| Multiple request statuses | The interface needed to support pending, expired, declined, and approved states |
| Large employee directories | The solution had to remain usable when a booker managed many passengers |
| Existing backend processes | The project focused primarily on improving the experience without redesigning the entire authorization system |
Problem
What Was Happening
Authorization requests were displayed as compact tags inside the booker profile sidebar.
Requests were divided into several categories:
new requests not yet sent;
pending requests;
expired requests;
declined requests;
approved passengers.
Although the layout was compact, it did not provide enough information or functionality for bookers managing more than a few employees.
Bookers could see employee names, but not enough supporting information to reliably identify the correct person. They could not see when a request had been sent, when it would expire, or quickly resend an unsuccessful request.
When more than a few employees existed in one category, the remaining names were hidden behind a generic “+X more” label.
Sending a request also required an indirect two-step interaction: the booker first added employees to a temporary list and then in the bottom of the profile click Save and send requests.
Key Usability Issues
1. Employees were difficult to identify
The interface showed names without email addresses, divisions, or other distinguishing information.
For large organizations with employees sharing similar or identical names, bookers could not confidently verify whether they had selected the correct person.
Full-name duplicates were not merely a theoretical edge case. In one organisation of approximately 26,000 employees, around 500 employees shared their name with at least one colleague.
2. Request status lacked context
Bookers could see that a request was pending, expired, or declined, but they could not see:
when it had been sent;
how long it would remain valid;
when it had expired;
whether another request should be sent.
3. Requests could not be resent efficiently
Expired and declined requests had no contextual recovery action.
Bookers often had to locate the employee again and repeat the request process from the beginning.
4. The interface did not scale
Only a limited number of employees were visible in each status group.
Additional employees were hidden behind a “+X more” tag, forcing users to interact with a compressed interface that was unsuitable for managing larger lists.
5. Existing requests were not searchable
Bookers could not search across previously sent requests.
Finding a specific employee required manually scanning several status groups, assuming the employee was visible at all.
6. Sending requests required an unnecessary confirmation step
Selecting an employee did not immediately send the request.
Employees were first added to a temporary “New” state, and the booker had to click Save at the bottom of their profile. This made the action less predictable and increased the risk of users leaving without actually sending the request.
Flow screenshot
Why It Mattered
Authorization is a prerequisite for future ride booking.
Any friction at this stage could prevent bookers from arranging transportation when it was needed, especially in time-sensitive corporate scenarios.
The existing experience also increased the risk of:
requests being sent to the wrong employee due to number of namesakes (in big companies it’s a real issue);
duplicated request attempts;
missed or expired requests;
increased support workload;
delayed corporate bookings;
lower trust in the platform’s permission management.
Baseline Metrics
| Metric | Before |
|---|---|
| Authorization request completion rate | 54% |
| Requests expiring without approval | 12% |
| Median time to locate an existing request | 15 sec |
| Support contacts related to request status | 4% of total |
My Role - Product designer
I was responsible for redesigning the end-to-end experience of managing authorization requests within the B2B web platform.
Responsibilities
audited the existing authorization flow;
mapped request states and available actions;
identified usability and scalability issues;
worked with product and engineering to clarify system constraints;
created interaction flows, interface concepts and prototypes;
defined behavior for pending, expired, and declined requests;
designed search and resend functionality;
prepared production-ready designs and specifications;
supported implementation and design QA.
Collaboration
I worked closely with:
Product Manager
Frontend Engineers
QA Engineers
Out of Scope
The project did not redesign:
the employee-facing approval experience;
the underlying permission and security model;
passenger profile management;
the broader company employee directory;
booking flows that occur after authorization is granted.
Research
Research Inputs
| Observation | Evidence | Implication |
|---|---|---|
| Names alone were not enough. Bookers often worked with large employee directories where several people could have similar or identical names. | The original interface showed requests as small name tags without email addresses, organizational units, or other identifying details. | The redesigned interface needed to provide enough context for bookers to confidently identify each employee. |
| Status labels did not answer operational questions. Knowing that a request was “pending” or “expired” was not enough to decide what to do next. | The interface did not show when a request was sent, how long it remained valid, or whether it could be resent. | The interface needed to surface request timing, validity, and available next actions directly. |
| Compactness was harming scalability. The sidebar worked for a few employees but became difficult to use as request volume grew. | Long lists were collapsed behind “+X more,” making requests hard to scan, search, or manage efficiently. | Authorization management needed dedicated screen space rather than another compressed block inside the booker profile. |
| Sending requests lacked immediate feedback. Selecting an employee and actually sending the request were split into two separate actions. | The employee was first added to a temporary list, and the request was sent only after clicking Save at the bottom of the form. | The request needed to be sent immediately after selection and provide clear confirmation of the action. |
Problem Definition
Problem Statement
Corporate bookers managing authorization requests could not easily identify employees, understand request timing, locate existing requests, or recover from expired and declined states.
The experience was compressed into a profile sidebar that had been designed for small volumes and did not scale to the needs of larger organizations.
As a result, bookers risked sending duplicate or incorrect requests, leaving requests unsent, and losing time manually navigating employee permissions.
How might we
How might we help corporate bookers quickly find, identify, track, and manage authorization requests without compromising employee consent or passenger data security?
Additional supporting questions:
How might we make every request status self-explanatory?
How might we help bookers distinguish between employees with similar names?
How might we make failed requests recoverable?
How might we support large request volumes without overwhelming the user?
How might we remove unnecessary steps from sending a request?
Hypotheses
| # | Hypothesis | Expected Impact | Risk |
|---|---|---|---|
| 1 | If authorization requests are moved into a dedicated workspace, bookers will be able to scan and manage larger request volumes more efficiently. | Extra High | Medium |
| 2 | If email addresses and divisions are displayed, bookers will be less likely to send requests to the wrong employee. | High | Low |
| 3 | If request dates and expiration information are visible, bookers will better understand when intervention is required. | High | Low |
| 4 | If expired and declined requests include a contextual Send again action, more authorization flows will be successfully completed. | High | Low |
| 5 | If selecting an employee sends the request immediately, fewer requests will remain unintentionally unsent. | Medium | Low |
| 6 | If users can search across sent requests, the time required to find and manage a specific employee will decrease. | High | Low |
Exploration
Information Architecture
The original experience combined two different responsibilities inside one profile section:
managing employees the booker was already authorized to book for;
managing authorization requests that had not yet been approved.
I separated these concerns into two tabs:
Employees
Requests to book for
This gave unresolved requests a dedicated workspace while preserving access to approved passengers.
Design Direction
The redesign replaced compact tags inside booker’s profile with structured rows on the separated tab.
Each request could now display:
employee name;
division or department;
email address;
request date;
time remaining before expiration;
current status;
available next action.
This required more space than the original sidebar but substantially improved clarity and scalability.
Trade-off
The primary trade-off was compactness versus operational clarity.
The original interface occupied less space, but it hid information and actions that bookers needed to manage permissions confidently.
The new design deliberately used more screen space to reduce ambiguity, improve scanning, and support larger employee lists.
Solution
1. Dedicated Requests Management
All unresolved authorization requests were moved into a separate Requests to book for tab and grouped by status:
Pending
Expired
Declined
Approved employees remained under the Employees tab.
This separated request management from other profile information and created a scalable structure for handling larger numbers of requests.
2. Clear Request Context
Each request included enough information to understand who it belonged to and what was happening with it:
employee name, division, and email;
request date;
expiration status or remaining time.
This made requests easier to identify and their current state immediately understandable.
3. Search and Contextual Actions
Bookers could search across existing requests and act directly from the relevant row.
Expired and declined requests included a Send again action, removing the need to restart the workflow or search for the employee again.
4. Immediate Request Sending
The redesigned search allowed bookers to find an employee and send a request immediately.
The temporary New state and separate Save step were removed, making the interaction match user expectations: clicking Send request meant the request had actually been sent.
Mobile web version
Validation
Usability Testing Goals
The redesigned concept should be tested against the following tasks:
Find a previously sent request for a specific employee.
Determine whether the request is still valid.
Identify the correct employee among people with similar names.
Resend an expired request.
Send a new authorization request.
Confirm that the request has been sent successfully.
What I Tested on UsabilityHub with clickable Figma prototype
Participants: 50 participants on UsabilityHub
Research Type: Figma prototype flow
| Task | Target |
|---|---|
| Find an existing request | At least 90% task success |
| Identify correct employee | At least 90% accuracy |
| Determine request status | Under 10 seconds |
| Resend an expired request | At least 90% task success |
| Send a new request | At least 95% task success |
| Understand whether saving is required | 100% correctly understand that it is not |
Validation Findings
What Worked
Participants understood the separation between approved employees and unresolved requests, and successfully navigated to the requests tab via the top-right CTA.
Email addresses and divisions were the most useful attributes for distinguishing employees with similar names.
Search significantly reduced the effort required to locate previously sent requests.
Inline Send again actions and removal of the separate Save step made the request flow more predictable and recoverable.
What Didn’t Work
Attempts to keep the entire flow within a narrow sidebar proved too restrictive, reinforcing the need for a dedicated request-management tab.
The attempt to put booker’s requests on the same table with employees (without adding a separate tab for requests). It made all the interface overloaded and messy.
Results
Business Impact
| Metric | Before | After | Change |
|---|---|---|---|
| Authorization request completion rate | 54% | 62-67% | 25-40% |
| Support contacts related to request status | 4% of total support tickets | 1-2% of total support tickets | 50-80% |
| Requests expiring without approval | 12% | 2-4% | 65-85% |
User Impact
| Metric | Before | After | Change |
|---|---|---|---|
| Median time to find and manage an existing request | 15 sec | 3-6 sec | 60-80% |
Learnings
1. Dedicated Space Can Be More Valuable Than Compactness
The original interface optimized for space, but not for the operational task it supported.
Moving the workflow into a dedicated tab increased visual footprint while significantly improving clarity, scalability, and actionability.
2. Status Should Explain the Next Step
A status label alone does not always help users make a decision.
Showing timing, expiration, and contextual actions transformed request statuses from passive information into manageable workflow states.
3. Identity Matters in Enterprise Products
A person’s name is often insufficient in a large organization.
Email addresses, divisions, and contact details were not secondary metadata. They were essential for helping bookers identify the correct employee and avoid costly mistakes.
4. Removing a Step Can Improve Both Usability and Reliability
The separate Save action introduced uncertainty because selecting an employee did not mean the request had been sent.
Making the action immediate aligned the interface with user expectations and reduced the risk of incomplete requests.
5. Enterprise Interfaces Must Scale Beyond the Happy Path
The initial design worked when users managed only a few employees.
The redesign had to account for larger lists, repeated names, expired requests, declined permissions, and users returning to requests long after they were created.
What I Would Do Differently
I would check hypothesis how often bookers need to add passengers by groups/divisions rather them add them one by one manually. For example, a new booker will be responsible for bookings of certain division. Why not just add all the employees from this division by division’s name?
Next Steps
Potential future improvements could include:
bulk request sending;
filtering by request status;
sorting by request date or expiration;
proactive expiration reminders;
request history and audit trail;
bulk resend for expired requests;
clearer employee-side explanation of why access is being requested;
analytics for authorization funnel performance.