From Counter to Keybox

Making pickup constraints clear when there is no one at the counter

Digital pickups let customers collect a rental car without meeting a store agent, using a secure keybox when branches are closed. What looked like a logistics improvement turned out to be a trust problem.

Role: Sole Product Designer, in a team of around ten people

Focus: System mapping, cross-functional collaboration and research

Scope: Booking flow for out-of-hours and fully digital pickups, planned for 52 branches at launch

Challenge: Leadership asked us to stop mentioning the keybox, but customers still needed to understand when they could pick up their car.

Outcome: A clear model of the pickup cases, a test plan agreed in 4 days and a label fix that solved the root of the confusion.

A customer holding a key fob up to the scanner on an illuminated self-service keybox terminal

Project Overview

Digital pickups allow customers to collect a rental car without interacting with a store agent, using a secure keybox when branches are closed.

What initially appeared to be a logistical improvement became a system and trust challenge. Branch setup, payment rules and customer verification all changed what a customer could do, but none of this was visible during the booking.

In this case, I show how I mapped these cases, how I challenged the direction we received and how we used testing to move the decision forward.

The Starting Point: Removing the Counter

Traditionally, the rental experience relies on human interaction for identity verification, contract explanation, payment and key handover.

The project was part of a company initiative to grow revenue with mobile check-in and digital branches. Mobile check-in covered verification and payment, and the keybox covered the key handover. Together, they made out-of-hours, unstaffed pickups possible, and in fully digital branches they removed the counter completely.

I was responsible for the booking side, from search to confirmation, starting with a pilot branch. There, 112 of the 168 hours in a week were outside opening hours, so the keybox was the main way to pick up a car.

This shifted responsibility from people to the product.

How might we enable customers to pick up a car without human interaction, while ensuring they feel confident, eligible and supported across branches and markets?

When the branch is closed, the keybox is the only service available, so every question a store agent would answer needs to be answered before the customer arrives.

Designing Confidence Without Humans

The main goal was to answer one user question before the customer arrived at the branch:

"Can I actually pick up my car when I arrive?"

This meant the UI had to:

  • Remove ambiguity
  • Make constraints visible
  • Confirm eligibility clearly
  • Work consistently across branches and countries
At this moment there is no agent to help, so the design needs to work on its own.

Research & Key Insights

Before jumping into the UI, I focused on understanding where trust was failing. The programme was already running when I joined, so part of the evidence came from earlier work:

  • Customer effort feedback showed that users did not know, during booking, if a branch was digital
  • The programme scoping identified document verification as the most critical step, with no fallback
  • A field report from a busy city branch showed customers confusing opening hours with keybox availability
  • In a search prototype test, users saw a "24h return" label and asked how to return a car to a closed branch

My research contribution: I defined the objectives and copy variants for an unmoderated wording test with 30 participants, run by our UX researcher. I also created the journey map to show where trust was breaking.

Satisfaction across the journey, from home to the rental branch. The three ringed points are where trust broke down: search, mobile check-in and the keybox pickup itself.

Designing a System Before Designing UI

Before designing the screens, I mapped the rules behind them: branch type, requested time, payment and verification. Some of them are inputs and others are results, and separating them was a big part of the work.

The request treated the keybox as one single case, but there were three:

  • Fully digital branches, with no opening hours
  • Keybox pickup available 24/7, including closed days
  • Keybox pickup only during a specific time window, a case that was not specified yet

This mapping showed that two different systems decide one pickup. During booking, the system knows the branch setup. At pickup, it knows the status of the keybox and the car. This means a customer could book an unstaffed pickup and still be sent to the counter on the day, without any message. The failures we found were all in this gap.

Two systems decide one pickup Top panel, at booking: the branch setup. Standard branches offer counter pickup in opening hours and are not bookable outside them. Hybrid branches offer counter pickup in hours and keybox pickup outside them. Digital branches have no opening hours, so every pickup is by keybox. A dashed seam labelled "no shared source of truth" separates it from the bottom panel, at pickup: once a keybox pickup is booked, a ready locker and car lead to a PIN and a rented car, while a disabled car, a closed locker or missing directions send the customer to the counter with no message. 1 · AT BOOKING What the branch setup knows In opening hours Outside them Standard Hybrid Digital Counter Not bookable Counter Keybox No hours set Keybox No shared source of truth 2 · AT PICKUP What the locker and the car know Keybox pickup booked Locker and car ready PIN issued, car rented Car disabled, locker closed or no directions Sent to the counter with no message
Booking decides based on the branch, and pickup decides based on the keybox and the car. When they do not match, the customer only finds out at the branch.

Solutions

1. Search and Results: Making Constraints Visible Early

Insight

Scannability

People skim results, they do not read them

A constraint hidden in a long explanation arrives too late. It needs to be in the label itself, before the customer chooses a branch.

UI decision: use badges and short labels to indicate keybox pickup availability, Pay Now only, and return availability.

Trade-off: a badge only fits a few words, so choosing the right words became one of the main discussions in the project.

Visual indicators and short labels in the results list, a badge on the station details and a positive confirmation of 24/7 pickups and returns.

Solutions

2. Separating Concepts That Users Confused

Customers understood the branch opening hours as the times they could pick up a car. A field report and our wording test showed the same problem, and the cause was the label itself: "Operating Hours", placed right above the staffed times.

UI decision: clearly separate staffed hours from keybox pickup availability, label every affected time slot and rename the label to "Office Hours".

What shipped: the new label was added to the product translations and improved the information for every branch, not only keybox branches.

Working hours give context, each out-of-hours slot shows a keybox indication and the map card repeats the information with two short labels.

Solutions

3. Requesting the Driver Licence After Confirmation

The programme had already defined the order: book first and verify after the booking confirmation, with a reminder before pickup. My role was to make this order clear and safe for users.

Principle

Momentum

Ask after the decision is made

Asking for documents after the booking keeps the decision simple, and the reason for the request is easier to understand.

Open risk: if the verification fails, the branch needs to call the customer to rebook or verify them manually.

The full flow after confirmation. Each step explains what is needed and confirms when it is done, so customers always know if they are ready to pick up their car.

Collaboration & Decisions

In the middle of the project, the direction changed.

  1. The request. Leadership asked us to remove all keybox mentions from branch selection and the time picker, because customers could read "keybox" as "no support". Before designing, I asked for a short call.
  2. The counter-proposal. I agreed to stop mentioning the keybox, but not to hide the constraint. I proposed showing all available times, using "24/7 pickup available beyond regular hours" and explaining at checkout why a card is required. Engineering and product leads approved it.
  3. The deadlock. The product manager was not sure customers would understand "digital pickup" versus "self-service", and closed days were still open. A quick check with two people was not enough evidence, so I documented both closed-day options and proposed testing them.
  4. The test changed the problem. The results were mixed, and users struggled with "24/7". I found that the confusion started with the "Operating Hours" label and proposed "Office Hours" instead.

What we could not build: disabled holiday dates in the calendar, because the branch data could not exclude holidays yet.

Outcome

This work gave the team a shared understanding of when a pickup is really possible, and fixed the confusion where it started.

What shipped

  • The "Office Hours" label fix
  • Designs for all four booking steps

What the team kept

  • A model of three pickup cases
  • A test plan to solve a deadlock
  • A reference for the next iteration

By the numbers

  • 52 branches in launch scope
  • 67% of the pilot's week keybox-only
  • 4 days from directive to test plan
  • 10 days from directive to results
  • 30 participants in the wording test

What I Would Do Differently

I still believe in this principle:

"Clear UI that sets expectations early builds more trust than flexible UI that hides constraints."

However, I would change where I focused my effort. The request was based on an assumption that was never tested: that customers understand "keybox" as "no support". Our only research round compared two wordings of a decision that was already made, so it could show us how to phrase it, but not if hiding the keybox was the right choice.

If I started again, I would use that first call to propose testing this assumption. With the results, we could reopen the decision with real evidence, or I would learn that I was wrong. It was the most important question, and it was simple to test.

You made it to the end

If you would like to talk about a project, or just say hi, my inbox is open.

sborges.rafa@gmail.com Back to home