Invoice Automation: Remessa Online

The Remessa Online is a digital product of international transactions, the flow where this experience is inserted is in the receipt of values ​​from the Legal Entity platform, within this process the user needs to send the Invoice.

An invoice is a document where you have the data of the company that will make this payment together with the values ​​and currencies, and description of the reason for receipt, it could be said that it is like an invoice, because the user needs to send it to the receiving company.

In the Remessa Online receipt flow, the user can send the bank details for the company's delivery, and the user can initiate the amounts after receiving the operation, and receiving their amounts.

The shipment has a website where the user can enter their data and download their Invoice, but this website does not store the information about it.

There is a lot of information about the users' lack of understanding about the invoice document, data coming directly from the commercial and customer service, even with new explanations about it in a doubt center, as it is a document that is somewhat complex.

Our goals within the OKR's in the third quarter (Q3) were:

1. Automate and reduce the number of documents sent in the receiving flow;

2. Increase sharing of shipping transactions by optimizing the user experience;

These objectives and the vision of the script, it was noted the need to automate an Invoice within the receipt flow. We delve deeper into the subject through information collected in qualitative research already carried out at other times, along with information about the service and the creation of a board in Miro where all existing data on the subject were inserted, as well as measurements, and insertion of the flow to have a broad view and observe the possible characteristics.

Within this compilation of data, we saw points such as:

• Increased user cognitive load;

• The user leaves in the middle of the flow to perform another task;

• Difficulty uploading the Invoice document via the mobile version;

• Psychological frustration of not performing the task suggested by the obligation to send the Invoice;

• New users have doubts about what an Invoice is and what it generates;

• We are aware of the need to send the Invoice to the user of services provided as a result of receipts;

• Possibility of facilitating the process, and reducing the time of completion of receipt;

We started a search on Hotjar to validate if the user already had an invoice at the time of sending the documents, and if he prefers to upload the invoice or just confirm the data on the platform.

Question 1: Did you already have an invoice?

Question 2: How do you prefer to send your invoice?

The result within this note is that new users did not have an invoice when sending documents and that a part of users who already had the invoice preferred to just confirm the data on the platform.

We defined the performance of a usability test with the experience of confirming the data, and better understanding about the user and their questions with the invoice in an interview.

In the Usability Test results, we redesigned the screens to facilitate this process with less information and confirmation in the flow and we noticed that the user did not notice the options in the upload flow, so we decided to do an A/B test, one as a question before starting the flow if he would like to upload the Invoice, or generate an Invoice, and the other with tabs above to select the action, where 20% of the base each flow was released.

Afterwards, we analyzed all the data that we could pull from the existing operation without the user having to insert it, and with that we saw that the only data needed was the description of the service for those who wanted to generate the Invoice. Which resulted in the decrease of the data and screens of the flow.

Which resulted in the screen below.

As this feature has not yet been implemented on the platform by the development team, so far we do not have metrics and data on its result.

Learnings:

• With the quick search made in Hotjar, it was analyzed the fact that the user already had the document in the stage of sending documents of the experience, and in the interview with the usability test it was noticed that the user already had the Invoice document because it was a mandatory document for collection of receipt, with this we understand the reason for the results of the research done previously;

• There is the anticipation of receipt functionality, where the receipt flow begins the process of sending documents, which generated the opportunity to automate the Invoice in this other functionality, so the user can generate his Invoice and use it for the company that will carry out the transaction;