Oferteo

The background

Payments are a crucial part of Oferteo's operation. Businesses pay for finding potential clients, revealing clients' contact data and promoting their services on industry listings.

In 2021 Oferteo decided to change the payment operator and fit payments directly in the PWA. Until then, all payments had been handled externally. When making a payment, user would be redirected to external payment operator, go through the process there, and get back to Oferteo app after that.

The task

The new approach required finding a new checkout process structure for mobile and desktop PWA, designed to:

• enable users to buy services and pay in a single process,
  
• meet the habits users have already established,
  
• be as short and easy as possible,
• comply with the operator's technical requirements,
• fit into common online payment patterns,
• ensure clients of safety of their money and data.

The solution

The new operator provided over 50 payment methods. It was essential to clearly present all available options, but also to allow users to quickly find their desired one.

To address this, I created four payment method groups. They were ordered by popularity, based on data collected by Oferteo:

• BLIK (express code-base payments popular in Poland),
• Card payments,
• Banks,
• E-wallets.

Apart from that grouping, I introduced an even deeper level when a bank enables more than one payment method. This way I minimised the cognitive load that user faces when looking for their payment option and shortened this step of the checkout process.

To ensure users don't feel lost or uncertain when seeing a major change in the payment process, I added a short explanatory label for users opening the new view for the first time. The label was presented until the user has completed a whole process or closed intentionally closed it with a button.

The background

There are three ways a business can use Oferteo to reach new clients:

1. It can browse the queries list in the app, manually select a client and pay for showing their contact data. That’s called a manual contact reveal and it’s the primary way of using Oferteo.
   
2. Business can define a profile of their perfect client and set a budget for Automatic Recommendation (AR). It is a subscription feature that automatically presents this firm to a prospective client looking for this kind of service. If the client wants to initiate contact, the firm pays for the contact data.
3. Business can promote their services on industry listings. Oferteo positions high in Google search, so clients can easily find the firm and contact it.

Additional features (2 and 3) allow clients to get better results. Although research showed that users often aren't aware of the profits they get from paying for these features. Therefore they may be less likely to prolong them or set up more.

The solution

Faced with this problem, together with Oferteo Product Team, we came up with the idea of creating a space that would:

• clearly show the benefits of using paid features,
• present the current and historical performance of these features,
• enable to create new, edit or cancel paid features.

This space is called the Statistics Centre (SC). I designed the Statistics Centre to answer the most basic question users have in mind when assessing the effectiveness of Oferteo – “how many contacts do I get?”.

The view is divided into three tabs. While the first tab focuses on contacts in general, the second tab represents the Automatic Recommendation details. How many services have this feature on? What is the current budget usage? What are the exact contact numbers for AR? These are the questions the user can find answers for.

The third tab shows the details for the promotion on Industry Lists, on which services of that business is the other. The data is presented for the last four weeks by default, but users can filter the data by selected period.

Recognising trends in the whole mass is one thing. Knowing what features are on for which services that user provides is the other.

At Oferteo every business defines its services and locations. For example, a contractor would set up all of the services they offer (like painting walls, renovating floors, repairing roofs etc.) and where they provide them (e.g. Paris, Berlin and Warsaw).

Then they can turn on paid features for every service in every location or decide just for specific services and locations. For example – only turn on AR for painting walls in Berlin and fixing roofs in Warsaw.

To effectively manage paid features, users need insight into their individual results. That’s where service filters come into action. Below the main chart, there is the services table. It presents all services with the current state of promotion services for each one of them. From the table level, the user can use the selected category as a filter. The filters are also accessible by a button.

I decided to use services as the rows in the table, not the locations, because the existing process of defining a new paid feature requires the user to select the service category first, and then set the location where it's offered. This way users have the same mental model when searching for the effectiveness of a paid feature, as they had when setting up the service. Apart from that, there are usually fewer services than locations, which makes the table shorter and easier to read for most users.

Right from the table users can open a popup with service details to see the locations, and current state of the paid features, as well as edit the service or the paid features.