Partners On-Request 


Happy Scenario. Just approx 20% of our bookings on Smartbox can be done straight away.

85% of our bookings on Smartbox are On-Request

Beneficiary pain points

Partner pain points

Partner team


PMP (Partner Marketplace)

  • Redeem vouchers
  • Make bookings
  • Check their invoices
  • See the experiences they have contracted with Smartbox and so on.


Managed by an external provider.

  • Hotel can make booking
  • Manage their availability
  • Accept or decline booking request.
  • As the first phase of the Iresa deprecation, remove the OR feature from Iresa and build it into a more user-friendly format in PMP
  • MVP without availability calendar (Limitation)
  • Breaking this complex project into small iterations and “phases”
  • What minimum can we do now that solve at least one of the pain points users has?

Analysis i-Resa On-Request flow

Analysis Airbnb On-Request flow

  • Emails
  • Education 
  • Airbnb learning
  • Rewarding
  • Sanctions

User flows, site maps, wireframes 

User flow including Jarvis Booking and the email provider.

MVP flow. Two entry points. 

Initial sketches

Sketches to explore different design alternatives with the team.

And interviewing partners.

Learning what works and what doesn’t work well for partners and why, with this design solution.


  • Can our user’s decline/ accept without confusion?
  • This solution allows them to answer faster?
  • Partners doesn’t need to Stop sell/Add availability (Assumption)
  • Partners don’t use the notes to communicate with clients (Assumption)
  • Why would be useful to keep their history of declined request?
  • Is easy to see the On-Request they have to answer having into account the time they spend on the homepage before going into iResa?
  • Why is slow the response for partners? (To ask this to partners on the interview)


Observation Sheet:

Repeated observations are highlighted in different colours.

This is an exercise suggested by Tomer Sharon (Writer of “Validating product ideas”)


After testing with 5 partners. The main findings so far have been:

  • Be already login into the system to answer On-Request
  • Stop/Add availability: We had the assumption that partners don’t use the function to stop their sells or to add one additional room, the reason for them to use it is because if they receive a request and they have availability they will prefer the next request to be an “instant booking”
  • We realise partners behaviour about “On request” it depends of the size of the hotel. 
  • Add availability for big hotels after accepting request. These partners are mixed, “On request” then go to “Instant availability”.
  • For rural places they prefer to keep “On Request” because it’s easier to manage than having “Instant availability”.
  • After accepting they would like to check their upcoming bookings.
  • Some reasons of slow response: They receive the On-Request during the weekend. Not in front of a computer all the time.
  • There is a need for communication between PAR&BEN. Make the “notes” a better messaging system between. 
  • “Template” for notes (Finding from i-Resa analysis) and from interview with partners. 
  • From feedback they expect to see their upcoming bookings and on request in the same place.

How are our users? (After doing interviews)

Big hotels: busy, usually booking managed by more than person, working with many companies like, Wonderbox, etc and prefer to have the On-Request, but when receiving a request will prefer to add availability so the next booking will be instant and they don’t have to enter to PMP to accept/decline.

Rural places: also very busy, bookings manage by 1 person. Working with many companies like, Wonderbox, etc, prefer to have On-Request but not interested on adding availability because for then it’s easy to manage, they just have to accept and decline, with Instant availability can lose a little bit of control.

How are we going to measure impact

  • For the phase 1: Partner response times to requests
  • Average time taken to respond to on Request booking
  • Number of On-Requests auto rejected (i.e. Expired)
  • Numbers of requests received per partner
  • Number of requests Accepted or Rejected
  • PRM contacts relating to specific On Request issues
  • Acceptance rates across 1st attempt / 2nd attempt
  • On Beneficiary side: CS contact volumes based on the existing case reasons that come from the on-request flow

My role

Research, interaction design, UI Design, prototyping, testing.

Conclusion / Next Steps

After interviewing partners and showing them the solution I could take lots of learnings and understand better for “who we are doing this and how they are going to use it” From the interviews we can also take some learnings about more open questions we had and even make more quantitative research. 

Could be interesting to do a research to know how many people use it “Add availability” “stop sell” to see if the lack of this functionality is going to affect an important amount of users so our number of calls will be incrementally affected and most important if that is going to affect the ability for partners to add stock and in consequence affect more one of our pain paint which is the lack of availability.

After findings collected from partners changes or improvement will be made to be ready to collect a second round of feedback. After testing is finished we will be ready to have a design ready for development which was validated/invalidated with partners.