Inquiry management — improving on KPIs

Zina Szőgyényi
Rozina’s Portfolio
7 min readJan 9, 2019

Background

Tripaneer sells theme vacations instead of destinations. The platform brings together numerous organizers and travellers across the globe who can find each other easily via themed websites, like bookyogaretreats.com.

Currently, only 10–15% of reservations happen instantly, the rest still requires communication between the parties to agree on availability and terms. I started working on improving the experience and business results of the organizer side in June 2017, this is the case of how I improved the usability and the results of the inquiry management.

Defining the problem

I used multiple resources to try to find the biggest pain points. From our operations team I heard that editing the offers was difficult, and the organizers often didn’t use the correct tab for their response.

With a simple look, it was clear that the mobile version was even more difficult to use, it was responsive, but not optimized to small screens at all, just a long page with a lot of options.

Research and finding signals

We know that mobile experience is important. But how important is it for our business?. I sought for the answer in our database. I compared thousands of inquiries from the last few months and grouped by their status and categorized by the time it took for the organizers to send the first response. The result was self-explanatory:

Statuses of inquiries grouped by the first response time from organizer

The conversion rate from inquiry to finalized booking dropped with every hour delay in the first response. I calculated the probable impact we could make there: if we moved every organizer to the previous category we could have improved the finalized bookings by 10%.

How to make this happen? Make it a lot easier for them to respond on mobile. So they don’t have to open the computer at all when they’re not at their desks.

The lowest hanging fruit

To make it bulletproof on mobile there were quite a lot of infrastructural changes necessary, as the template was overly complicated and very difficult to make meaningful changes. Many nested conditions, many different cases forked into one long big code.

Before we decide to redo all the logic and make a lot simpler structure, we had to get some signal that our ideas make sense and they actually improve the usability.

Having to pick a tab before responding is not an intuitive way to decide whether a retreat is available on certain dates or not.

The main entry point to the page is the notification email, why don’t we test the new actions in the email first? It’s easy, quick and it would take a lot less time to develop and start getting the feedback.

Old email with single action vs new email with quick actions and inquiry summary

It included changes like:

  • clear call to action (please respond) in the header
  • highlighting the customer’s message that required response
  • summarizing the selected package details above the calls to action so the reader doesn’t have to scroll back and forth
  • clear action oriented buttons instead of “click here to reply”

The result and the learning

The number of clicks was about the same in both variants, however, where we had multiple actions the click share were similarly distributed as the overall actions taken on each inquiry. The average response time decreased by 15% and the granted availability went up by 5%, both results were significant.

This experiment showed the usefulness of easy actions and backed up the research results of the importance of first response times.

Improving the mobile view

Even before we jump into code clean up and structural changes — which eventually would be inevitable — we can still do some optimization for mobile devices — making it a lot intuitive and delightful to use.

I decided to give guidance on how to process a request instead of just putting a long and complicated form in the front of our organizers.

Initial view, package editing view and message view of the inquiry approval process.

  • I reduced the unnecessary padding from the sides and made the page full width — those extra 40 pixels worth a lot on mobile
  • I took the request summary and put it on the top of the page for easier overview, and put the customer’s message right underneath, which used to be on the bottom of the page, below all the forms
  • I added a big button to “edit the package” instead of a small link, so it’s easier to notice and use
  • Created a title for the forms which instructs the organizer to take action
  • adjusted the copy and the visual representation of the tabs to look more obvious which one needs to be selected
  • I reflected the exact email content to be sent to the customers when composing a response for transparency.

The result and the learning

This view is still not perfect since it’s still giving too many options to the organizer, which makes the decision more difficult. But at least it’s a step closer towards our vision and gives us chance to get more feedback of our changes.

The experiment was a great success, we got a lot of positive feedback from our organizers. The variant was liked 100% times more than the old one while the experiment was running and got 70% less “bad” or “fair” usability rating compared to the old version.

The effectiveness of the page increased: we got the same amount of finalized bookings from fewer conversations. The correct “tabs” were used correctly and there was less need for our customer service to interfere with problematic inquiries.

The usability increased, the next step is to have it reflected in the business results too.

The feature overhaul — a seamless experience

Throughout time this page got a lot of new states and features (managing availability, messaging with customer, managing booking conditions, dealing with payments, adjusting packages to the customer’s needs), none of these extensions were properly well thought out. It was more important to have the feature somewhere on the page than making it available for whom it is relevant and when it’s relevant. This resulted with a very complex code, which is very difficult to experiment with.

As we have started rebuilding the templates as a part of the rebranding (you can read more about that project here) it was time to move the inquiry management into the new templates, and with that, finally clean up the logic and make the page useful.

I took a mobile-first approach, as we’d like to encourage the organizers to quickly deal with the inquiries.

Defining the stages

To avoid the confusions and difficult conditions in the templates I defined stages of the page, the actions organizer need to take at that point, and the information they need to make decisions.

[Pending status]

  1. Customer wants response as soon as possible

2. Organizer wants approve request and customize package based on requests

3. Organizer needs:

  • overview of request
  • customer’s message
  • be able to create custom offer easily
  • ask and answer questions quickly
  • accept or decline request

[Accept request]

  1. Customer wants answer to their questions and payment information
  2. Organizer wants to make sure that data is correct and send a welcoming message
  3. Organizer needs:
  • overview of request
  • be able to create custom offer easily
  • set payments and booking conditions
  • write a personal message

As a result of this exercise, I wasn’t just able to clearly separate the necessary features on the page but also customize the copy to fit the context, which is key to create a delightful experience. When the user feels the human touch, not only the computer-generated forms.

On bigger screens now we can display the conversation above the fold for an easier overview, and on mobile, we make sure that only the most relevant items are on the screen at a certain point.

The next steps

As now we are confident that our inquiry management is a lot easier on mobile we can start working on stories that will shift the inquiry management from desktop to mobile — sending notifications on mobile channels, such as texts, Messenger, WhatsApp, WeChat etc., serve saved responses and previous attachments, and eventually, work on the instant reservations, which eventually will make all this effort redundant. Life of a designer :)

--

--

Zina Szőgyényi
Rozina’s Portfolio

A Digital Product Designer, traveler with addiction to fitness, based in Ottawa, discovering new places, foods and craft beers