← Back to portfolio Case study Sukuto · 2026

Beep beep… booked.

Designing a self-serve rental experience for Sukuto's car and bike booking platform.

◆ (01) Context © 2026
Context

A user needed a bike. Or a car. Sometimes more than one.

They came to Sukuto with a simple job: pick a location, choose dates, select a vehicle, and book.  But the booking had conditions.

Vehicles changed by location. Prices changed by duration. Vendors changed the rules. Availability changed with dates.

So the user paused.  Then called.

Support checked the vehicle, explained the price, confirmed the date, helped finish the booking.

The product had the inventory. The user had the intent. But the booking still needed someone in between.

The problem wasn’t that people didn’t want to book online. It was that the product didn’t make them confident enough to do it alone.

◆ (02) Problem statement © 2026
Situation

Plans were instant. Bookings were not.

Customers

Users wanted to rent a vehicle but struggled to understand the booking flow. Uncertainty led them to pause and call support.

What they needed

A booking flow that made every step clear and built confidence to book independently.

Support Team

Support spent time explaining availability, pricing, and booking steps instead of handling complex issues.

What they needed

A product that answered routine questions before users reached out for help.

Business

Online bookings depended heavily on manual assistance, increasing operational effort and slowing conversions.

What they needed

A self-serve experience that increased direct bookings while reducing support dependency.

◆ (03) Research © 2026
The research

What I asked?

Product discovery · Booking flow audit · Ops inputs

Where exactly does a user stop while trying to book?

What does support check before confirming a vehicle?

Which details change when a user selects a different location?

1

How often is vendor inventory different from what the user sees?

2

What happens when a selected vehicle is not available anymore?

3

How does pricing change by date range, pickup location, and vendor?

4

What does a user need to know before feeling safe enough to pay?

5

What does the admin team need to update after every booking?

◆ (04) Findings © 2026
The research

What I found out

Product discovery · Booking flow audit · Ops inputs

Pricing changed before users understood why it changed.

Drop-offs did not end the journey.
They turned into support calls.

Availability was only clear after checking location, dates, vendor, and vehicle status together.

1

Users were not stuck at the start.
They were stuck when the booking needed confirmation.

2

Checkout needed more trust.
Vehicle details, partner terms, updated price, and partial payment had to appear before the user felt ready to book.

◆ (05) Takeaways © 2026
The research

From insight to decision

Users were ready to rent. The flow made them call.

  • Users came with clear intent, but the booking flow made them slow down.
  • They had to process location, dates, vehicle choice, pricing, duration, terms, and payment before completing the booking.
  • When the flow felt unclear, calling support felt easier than continuing alone.
The decision

Location + Dates → Vehicle selection → Price clarity → Trust-led checkout

The booking flow had to start with the two details that shaped everything after it: where the user wanted the vehicle, and for how long.

Once that was clear, the product could show the right vehicles, update pricing by duration, explain partner terms, and let users reserve with partial payment.

The goal was not to add more information. It was to sequence the information better.

◆ (06) Principles © 2026
What guided the redesign

Three rules for a self-serve booking.

01

Answer it before they ask

Every question that used to trigger a call — availability, price, terms — had to be visible on the screen, at the moment it comes up.

02

Compare without digging

Every duration priced side by side. No changing dates just to find out what a week or a month would cost.

03

Let them see before they commit

Booking shouldn't mean paying in full, sight unseen. Reserve for a fraction, inspect the vehicle, pay the rest.

◆ (07) The flow © 2026
The flow

Where, how long, which one.

STAGE 01

Location + dates first

The two answers that shape every price and every available vehicle — asked before anything else loads.

Asks the two questions that used to start a phone call.

STAGE 02

Search, compare, add to cart

Every vehicle with duration pricing, real availability, and pickup options — no call needed to compare.

Compare every duration without changing dates.
◆ (08) In the detail © 2026
In the detail

One card, every decision a rider needs.

Sukuto booking card

Riders lived on WhatsApp and calls. A card that answered price, trust, and location at a glance meant they never had to ask.

Duration pricing, side by side

Daily to monthly in one view, "best value" flagged — the answer to "why did the price change?"

Trip count as social proof

"186 trips" signals a real, rented vehicle — trust without a testimonial.

Price per pickup location

Switch pickup point and the price updates inline — no new search.

Zero deposit · partial payment

The two trust badges that used to need a phone call, stated on the card.

↺ Changed my mind First hid duration pricing behind a flip card. Learned riders pick a price first, then a plan — so it came to the front.
◆ (09) Across the flow © 2026
Across the flow

More of the system.

Filter with intent.Area, transmission, fuel, brand — each with a live count.

Pick your pickup.Same vehicle, every nearby location and price in one place.

Answers the pickup question support used to field.

Book more than one.Multiple vehicles, one running total.

Book several vehicles yourself, no coordination call.
↺ Cut my own idea Wanted the filter panel always open. Stakeholders wanted more vehicles visible, and it broke mobile parity — so it folds away.
◆ (10) Designed under a constraint © 2026
Designed under a constraint

Terms you can't miss, without a wall of text.

Partner terms had to be impossible to miss — the business needed them visible to prevent disputes — but a cart that buried them, or hid them behind a tap, failed that test.

Terms sit beside the payment

Vehicle details and partner conditions on one side, the amount on the other — read together, not discovered later.

Sticky amount bar on mobile

The payable amount stays pinned; tapping it jumps straight to payment, so the terms are never skipped but never block either.

↺ Reworked twice Tried it like a shopping cart. Business needed terms always visible — so payment sits one side, vehicle + terms scroll-read the other, with a sticky amount bar on mobile.
◆ (11) The trust move © 2026
The trust move

Pay a little now. See the vehicle. Pay the rest.

The biggest reason riders called instead of booking: they wanted to see the vehicle before committing the full amount. Partial payment let them reserve for a fraction upfront and pay the rest at pickup — the confidence of a phone call, without the phone call.

Sukuto partial payment checkout
◆ (12) Impact © 2026
Impact

The calls reduced. The bookings moved online.

Half of all bookings used to need a call. That dropped to one in ten — and riders trusted the flow enough to reserve on their own.

50%10%
Support-assisted bookings

Bookings needing a call to complete, before → after.

90%
Chose partial payment

Riders who reserved upfront and paid the rest at pickup.

35%
Booking growth

Overall bookings after launch, from admin panel data.

thank you.

Sukuto · self-serve rental booking · 2026