Short -Partners On-Request 

From a beneficiary point of view, there is a current frustration with the on-request process because partners response to “On Request” is too slow and this generates anxiety on customers that are waiting for a response but need to plan their holidays. Beneficiaries are forced to try multiple on-request cycles until they get a booking confirmation. Poor delivery rated on request messages and absence of an efficient messaging for handling on-request.

One of the partner pain points is the current system provided to them to accept and manage “On-request”. There is an opportunity presented since as the plan is to deprecate the current system called i-Resa, used to manage and make a booking for our stay partners.

1. Who are the users?

2. Discovery phase

Partner management interviewed 11 on-request partners (June 2018) and the results showed that the factor that drives on-request choice over Instant book are:

  • The fear of overbooking
  • Inflexible, slow systems have forced partners to choose the On-Request route
  • Opportunity to stockpile demand for dates in case they get a cancellation on other channels (this is poor partner behaviour)

From Beneficiary side customer feedback was collected to understand the pain points they are experiencing (1,500+ survey respondents)

Conducted benchmark analysis on the Airbnb and Homestay request flow.

Example of feedback provided in a Focus Group conducted by Beneficiary team with our customers to understand their main pain point related to on-request.


Take the opportunity presented by the i-Resa depreciation to improve our on-request model, designing a flow that:

  • Puts our beneficiary needs at the centre of what we build
  • Our partners find easy to interact with
  • Tackles the issues with the previous on-request version that drove Beneficiary frustrations and subsequent CS call volumes
  • Ultimately, we want to build an on-request flow that facilitates an efficient, simplified on-request booking process for both Beneficiaries and Partners.

3. Constraints and limitations:

i-Resa deprecation is going to happen gradually. On the first version for the On-Request flow, we wanted to bring the main functionality from i-Resa which is to accept and decline on-request to the partner portal. Later we’ll bring the rest of the functionalities which is to stop sell and add stock to the calendar.

  • After partners accept on-request we will reuse the layout used for stay-bookings on the partner portal because we have time constraints on the delivery time of this function.
  • Since this is an MVP we won’t be able to provide two of the functions partner use which is to stop sell and add stock.

4. Conception

The initial requirements for an MVP are:

  • Decline/ Accept on-request
  • Decrease the time of response from 48h to 24h
  • Reminders to partner to response On-request
  • Change email provider to Cheetah and improve emails both for Partner and Beneficiaries.

5. Competitive Analysis 

I started my process by investigating what other systems that manage On-Request do. One of the best examples and easy to research was Airbnb.

How Airbnb On-Request flow works

I wanted to test the whole process on Airbnb when a partner receive an On-Request but wanted to see both scenarios how it looks like, so for that I created a Listing on airbnb with my real account there and then published it and for the person who is going to make the booking I created a “fake” account, so I was doing both flows, the partner who receives the request and the user who sends it. 

User Flow

I started my design process by thinking on a flow that will allow partners to focus on manage the request and answer quickly. Having into consideration two entry points, one entering from the email an the other one when partners are going to perform another task but they are presented with the on-request they currently have. The product owner was also involved on the design process as we worked together at the beginning of the conception.

Initial longer term user flow

Final MVP solution

Initial sketches

Sketches to explore different design alternatives.

Design and Prototype


  1. In the left side on the image below is where one of the entry points starts: The partner receive an on-request email and then enters to manage their booking. In the screen beside is where they can see information about their booking, what they have to offer to the client and the time remaining they have to answer this request. 

2. If partners choose to decline they asked again because the action can not be undone. The other entry point partner have is when they enter directly into their account and were they will be presented with on request bookings. 

3. If partners missed an on request and did not answer they will be presented with a warning about the on-request they have missed. 

One of the challenges presented on the design was, how to communicate a negative feedback, after they decline an on request, how is going to look when declined if is a feedback/confirmation after an action but is not positive. The solution was to use the info feedback msg to let them know about their action taken. 

Putting this solution in front of our Partners


  • Learn what works and what doesn’t work well for partners and why, with this design solution
  • Watch how people use the design
  • Tweak designs based on actual partners feedback

Questions we wanted to get answers:

  • Can our user's decline/ accept without confusion?
  • This solution allows them to answer faster?
  • When entering to PMP to do another task, partners will realise about the “On request” they have?
  • Partners will know about the time remaining on the request? Is this information important for them?
  • Why is slow the response for partners? (To ask this to partners on the interview)

Test process


Partners have been recruited by our Account Manager by phone. 

Remote Moderated Usability

The test have been conducted by myself and so far I’ve tested with 3 partners, using Gotomeeting to record the session and a mobile phone to record the audio. An email previous to the call was sent to them were they can find a link for the meeting and a link for the prototype on Invision

Screen of the partner sharing his screen

Observation Sheet:

Repeated observations are highlighted in different colours.

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

So far we have tested this solution with three partners (On going). The main findings so far have been:

  • Partners find the solution clearer than the current one, but one important factor is that they will prefer to be login in at the time of clicking on the email to manage the request, they find another extra step and a complication to login into the system which is currently a pain point.
  • 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”
  • Partners are fine with the optional input field for then to enter declining reason.
  • They can easily see their On-Request list below the booking function when entering to perform another task on PMP.


1 product owner and different teams involved in initial workshops. 

My role

Interaction design, UI Design, prototyping, testing.

Conclusion / Next Steps

At the beginning of the project one of the assumptions was that partners don’t use the current function to stop or add stock to their availability. We don’t have a clear number yet of how many people use these function because we are not able to track the use on iResa because is an external provider, we have been learning the “why” but we don’t have numbers just yet, could be interesting to do a research to know how many people use it 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. After this solution is on production we will be tracking the use on Google Analytics and Mouseflow.