Improving UX for Tyumen Thermal Resort or a story about how we reduced the number of queues offline
We work with a thermal resort SummerSummerwhich is located in Tyumen (I recommend visiting it). And they needed to optimize the process of buying tickets to the resort. The resort already had a website, the client's team had come a long way in digital. But there were still some difficulties in UX, and they were related to the code: user registration failure, the inability to use accumulated points in the loyalty program to pay for tickets. Errors led to customers abandoning online purchases and coming to offline ticket offices for tickets. Plus, there was a heavy load on support.
We needed to increase the share of online purchases and the number of loyalty program users. And another task was to reduce the time required to get a ticket so that there were no queues at the checkout.
To cope with the difficulties, we optimized the integrations and the system code. We tell you how it was.
What systems are involved in the registration process and how does the interaction take place?
We started with an audit of the check-in and ticketing process and found out which systems are involved in the process and how they interact:
Backend. Implements the internal logic of the web application, ensures interaction with databases and external services.
TNG. Loyalty program management system. Performs operations with the client's bonus account when purchasing tickets: accumulation or write-off of bonuses, balance is shown.
BARS. Ticket sales system. Calculates the final cost of the order and generates requests to the acquiring bank to generate a payment page.
The interaction of three systems: backend, TNG (loyalty system) and BARS (ticket sales system) took place as follows.
When a user registered on the site, the backend sent a request to register such a user to TNG. TNG, in turn, initiated the account creation on the BARS side. If the order was placed by a user who was a member of the loyalty program, BARS sent a request to TNG and received information about the number of points in this account. Then the discount size was calculated, the number of points that could be written off, and the data was sent to the acquirer to create a payment page.
Points accrued after purchase were calculated in the backend system. The backend sent this data to TNG for accounting in the user profile. In this way, the registered client accumulated points, increased the grade, increased the discount on tickets, and so on.
What difficulties were identified and how were they corrected?
The connection between the three systems is built sequentially in real time. Registering a profile in the backend and then creating an account in TNG or BARS does not happen instantly. If an error occurs at any stage during the process of “pulling” the profile through the three systems, an account cannot be created in one of the systems.
It was difficult to figure out the errors: there was no logging at the registration or purchase stage. If a system failure affected a site user, it was only possible to find out about it if the client reported the problem they encountered. And even in this case, finding out the reasons took a lot of time and did not always lead to a result.
We needed not only to eliminate errors, but first to find them. To do this, we agreed with the client to create a sandbox, uploaded test data there, took cases from the client in which errors occurred, and began to search for them empirically.
Error registering new users
The main difficulties were related to the integration of the LetoLeto backend and a third-party loyalty system, in which points were accumulated for purchases. Each new registered client automatically became a participant in the program – points were accumulated, and the person was more willing to return to the resort, knowing that he could spend them on buying tickets.
But users did not always become members of the loyalty program due to errors at the registration stage. It also happened that the participant did not see the accumulated points and could not use them.
The creation of new user accounts was done on the backend system side, which then passed the data to TNG and BARS to create profiles. The implementation was built in such a way that the system itself did not know whether the registration process was completely completed. Failures were not always taken into account. Sometimes the system tried to repeat the procedure of creating and linking profiles when the user tried to log in to the account again.
We analyzed the code and built a series of steps that must be performed for successful registration. We clarified this sequence with the client and received a clear process flow: how registration should work at each step, what difficulties may arise, what consequences they will lead to, what third-party systems will need to be notified in this case. We wrote new code and accompanied it with logs so that at any step of registration we could receive an answer about the reason for the system failure.
We also found a solution for checking registration — it should end with the creation of a user profile not only in TNG, but also in BARS. We created a task to check the current status of the process: if the user account in BARS is not created, the system tries to register with an interval of several milliseconds. The total time of attempts was limited to thirty minutes.
The backend admin panel now includes statuses that show whether accounts have been created and linked in the three systems. If not, the administrator will restart the procedure manually. In this case, the points for the first registration will not be lost – they will automatically appear in the TNG system profile. And the points for the purchase itself can be loaded manually.
Multiple profiles and inability to use points
There were situations when the system did not “recognize” loyalty program participants, which is why they could not use points. When a client tried to log into an account, the site returned an error that such a user was not registered. If a person registered again with the same credentials, he still did not receive access to points. When creating a new entry, the connection with the old account was lost.
In fact, it turned out that the error record was incorrect. The problem was not caused by a missing account — on the contrary, there were too many of them. But previous developers identified two errors — duplication and missing account — as one.
We started to find out whether TNG was responsible for this error or if there was another reason. It turned out that LetoLeto had its own business process, during which employees imported data into TNG directly from the database, and not through the API. This led to duplicate accounts. The client could not change the business process, so it was necessary to solve the problem within the current restrictions.
To do this, we have built in an algorithm for checking multiple profiles and validating them. If an API request from TNG returns several profiles instead of one, we look for a valid one among them. We have created a set of markers by which we distinguish a duplicate profile from a real one: the presence of a bonus account, purchase history, grades, and so on. We find such a profile and invalidate the rest. If there is more than one suitable profile, we use the first one created as valid.
In addition to the check, we added a correct description of the error associated with multiple profiles. Now, if TNG returns such an error, the validation mechanism is launched, as a result of which the user is successfully registered in their account and can spend points.
Prices and final cost calculation
Ticket price data was stored in a third-party API (BARS) and locally — on the LetoLeto website in a special tariff section. Content managers added them there.
When the user went to the site and selected tickets, the prices were pulled from the site. At the last step — clicking on the payment button — information about the selected items was transferred to BARS, which calculated the final cost based on its data. That is, local prices were needed only for display in the UI and for pre-calculation.
It was necessary to control the relevance of information in two systems at once and track the correctness of calculations locally – for example, discount percentages could change.
In order to protect the client from possible risks and optimize the business process, we proposed using only data from the master system, i.e. BARS, for calculating tickets and purchasing.
We developed a new algorithm and prepared a demo version to demonstrate it to LetoLeto. During testing, we encountered a critical limitation that was not in the documentation. After a request for a final cost calculation, a final order object with a final price option was created in BARS. It was impossible to recalculate or return it to its previous state. And we needed intermediate calculations.
For example, a user added tickets to the cart, clicked “Pay”, and then remembered that he had points in the loyalty system. He returned to the order, logged in on the site – the system should take into account the points and recalculate the cost of the tickets. Such an operation could not be performed with the BARS API that existed at that time.
The concept could have been buried, but we did not give up. We arranged a meeting with the customer and BARS developers with the ghostly hope of getting the implementation of a method that could pre-calculate an order without finalizing it. Just in case, we looked for an alternative implementation approach within the existing methods and found such an opportunity. The idea was as follows: create a clone of the order and make calculations with it. At the final step, change the clone to the real order. If the client wants to return to the order and change something in it – apply discounts/points – a new clone is formed for pre-calculation.
We created and tested our implementation option on the full order processing scheme with all possible pre-calculations. Everything worked perfectly. This task was carried out in parallel with the implementation of the new order system interface, so the new approach was integrated painlessly.
What else have we done?
In addition to the points mentioned, we also took two more important steps:
We set up sending purchased tickets to the CMS and to the user's email.
To ensure correct operation of Bitrix24, we optimized the number of client requests. Now they are processed faster and bookings go smoothly.
Due to the correct operation of the services, productivity has increased – the interface loads quickly and it takes just 5 minutes.
What did integration optimization give?
In addition to finding and fixing errors, we took into account previous experience and built a transparent logging system. Now the entire order process is logged: what stage it is at, what is happening now, where the failure occurred and why. The information is written to a separate log. If something goes wrong, you can look at it and find out the reason. What is important and pleasant is that after our integration optimization, such errors have not yet occurred.
During the work process, we took into account the client's limitations in terms of business processes and technical capabilities of the systems and looked for the best technical solution to the problem. As a result, the optimization of integrations did not lead to changes in existing business processes, and some of them even improved.
Technical improvements have directly affected user loyalty: LetoLeto clients successfully accumulate points, do not encounter difficulties when registering and logging into the site. The registration and ticket purchase processes themselves have become more correct from the backend point of view.
