Hi, Habr! My name is Alexei Shikhov, I lead the CarPrice development team in Kirov. Carprice now ranks second in Russia in car sales in the secondary market, and almost all cars purchased in Moscow go through one huge central hub, from which buyers (dealers) pick them up or send them to car transporters. There are always at least 700 cars in stock that do not stay there for more than five days. In this article I will tell you how our team of friendly developers and caring testers fought with the inevitable chaos for such an anthill and defeated it.

The central hub of CarPrice is not just a guarded area where we dump cars waiting for someone to come after them. All cars arriving at the warehouse undergo a technical inspection, documents are prepared for them and they are put in order by themselves - they charge batteries, add fuel, wash the liquid, etc. And before the sale will arrange additional inspections for dealers.
Dealers come unpredictably - the flow was very fickle. Employees of the warehouse then ran, sticking their tongues out of the car to the car, then “smoking bamboo”, not knowing what to do. It happened that one dealer took away a dozen cars at once - it took a whole day, from early morning to late night.
')
Booking system
To streamline the work, we have created a simple universal service record for services (he is also booking, he is an electronic queue). In it, getting a car is divided into two steps - inspection and issuance. The first one includes preparation for inspection and car inspection by a dealer in the presence of a warehouse manager. Then the dealer pays the car and proceeds to the issuance step, at which documents are signed and the keys are transferred. Inspection and issuance may take place on different days, some dealers sign up immediately for issuance without inspection, and some inspect one car several times.
At first, the recording service did not represent a complex system; it solved simple and understandable tasks - it calculated free slots depending on the type and duration of the service (stage), taking into account the work schedule of the warehouse staff.
The dealer enters the personal account, selects one of the cars won at the auction from the final warehouse, the type of service (inspection or issue) and is recorded on a free slot.


This can be done both from the desktop and through the mobile application. If for some reason the dealer cannot register independently, a personal manager or a warehouse employee may record it.
Such schemes successfully work in many companies, and we hoped that as soon as we integrate the service, all problems would disappear.
Problems do not disappear
After some time, we understand that the system does not work in practice. The reason is that most dealers are not very punctual: they come without an appointment, much later or earlier than the appointed time, and sometimes even on another day. When this is recorded on the issue, and come for a visit. Indicated the inspection of one car, and require you to show another five others. Some dealers only want to work with a specific warehouse manager. However, many dealers are very emotional and are not able to put up with inconsistencies. With such unpredictability, warehouse staff do not understand which of the crowd of angry dealers need to be taken into work, which cars to prepare for inspection. We thought, thought and decided to introduce a new solution.
Electronic queue
The idea was promising. Managers do not need to think about whom to take to work, - pressed the button "next", and forward. Dealers understand how the warehouse is loaded, see their position in the queue and know how long to wait. By monitoring the maintenance time, you can dynamically adjust the slots, and in case of SLA violation, you can notify the management. And for inspection / issue, you can sign up directly from the terminal in stock.
On the backend, all the logic of the applications should be implemented, including the distribution of tasks between operators. Front components:
- A terminal with authorization by phone number, recording for services, viewing available cars, connecting paid services and issuing coupons for recording
- Dashboards with visualization of the queue and current coupons at work
- Operator (warehouse manager) console
From a technical point of view, the dealer, signing up for an auto inspection in his personal account, makes a request to the booking service on the backend, in response to receiving a list of possible machines for recording, free days and time. In addition to the main, the system had to handle other, "vital" cases:
- Dealer enrolled, arrived / not arrived
- The dealer signed up, arrived on time, went into the slot 30 minutes
- The dealer signed up, arrived later / earlier at 15, 40, 100 minutes
- Dealer is recorded / arrived at the VIP-issue
- The dealer signed up for a slot in 30 minutes - in fact, it turned out 10 minutes / 2 hours
- The dealer signed up for inspection, arrived, examined, went to pay, after 40 minutes returned to pick up the car
There were several additional requirements:
- Flexible configuration of the warehouse staff with the services that each can provide. And all this in the conditions of overlapping work schedules of employees - we have two shifts, from 9 to 18 and from 13 to 22
- Quick connection to the new warehouse system
- Integration with other services - current booking, dealer authorization, etc.
- Easy vertical and horizontal scaling
- Realtime interfaces
The requirements did not seem exorbitant, so I didn’t want to dive into it with my head and stuff cones. We thought that the electronic queue is already a well-developed topic, and decided to find a contractor with a ready-made box solution, who knows how to approach the specified business cases.
We develop ourselves
Search contractor gave nothing. Most ready-made solutions have a very primitive algorithm. Coupons are added to one common queue or broken down by category, and then the operators alternately take the coupons out of the queue. Everything. There is no flexible configuration, there is no logic for the distribution of coupons between operators, and the system usually works only in Windows. I will not even talk about easy integration with internal services. In this case, all the price tags space. We still started working with one contractor, but he had about ten percent of the necessary functions, and everything else would have to be cut for a long time. So we broke up and decided to write an electronic queue on our own.
At this point, we already clearly understood our needs with all the nuances and immediately began to implement. Backends were made on the basis of a previously created booking service - using Laravel, PHP 7, RabbitMQ, Percona, Websocket, and everything in Docker. The whole front was implemented on the web-socket, which made it possible to create real-time interfaces.
The terminal was assembled from a metal case, in which the iPad is hiding. The case protects the tablet from theft and fixes it in the desired position.

Guide-access is activated on the tablet and a third-party application on Vue.js (SPA) is running in a full-screen browser without controls. First, the dealer is authorized in the terminal by SMS (JWT). After authorization, he can look at his inspection / issue records and get coupons for them. VIP-services are available to dealers with the blocking of funds in their personal wallet.

Each record for inspection and issue is pre-attached to a specific warehouse manager and, if possible, is automatically grouped with other records of the same dealer. When assigning a manager, the schedule and workload of employees, the presence of other scheduled entries by the dealer and other factors are taken into account.

When you make an appointment for a dealer account, money is blocked, and when you receive a coupon, it is returned. Entries for which a coupon was not received in time are automatically canceled, and the money for a false entry is written off from the dealer's account. From the received coupons, a queue is formed, which is distributed among the working managers, taking into account the recording time and the dealer's waiting time, such as recording, etc.
For VIP, a separate queue is allocated - the dealer can take a ticket for "right now" and immediately go to a meeting with the manager if there is no queue from the same VIP. The service, though paid, is in great demand among dealers who arrived without an appointment or were late and do not want to wait.

Another component of the system - dashboards - shows which ticket is served by which operator. In addition, it displays the current queue and by voice invites the dealer to proceed to the operator. In fact, this is a regular TV with a connected nettop, which runs a full-screen browser and opens the Vue.js (SPA) application with the parameters of a specific warehouse.

The operator for work has a remote - a laptop in the workplace.

An operator interface is open on a laptop in which, after authorization, it can create, modify and cancel entries, record the result of the service, transfer customers and postpone work with them. Using this interface, if you have certain rights, you can customize the work schedule of managers and their possible services.


Through the same interface, each SLA can be configured in detail for each warehouse. This makes it easy to scale our electronic queue for any number of new warehouses.

There are many different settings for SLA, we monitor the work of warehouses in many ways.


The new system of electronic queue helps to solve various difficult cases. Here are some examples:
- The dealer signed up for several cars, very late and half of them became expired. It turns out that the record is partially overdue, so the dealer still sees it in the terminal and can get a ticket for it. The manager in the operator’s console sees that some of the services are overdue, can complete work with the coupon without them, or delete some of the active services and add overdue services instead.
- The dealer came to inspect and issue a car, but the car showed defects. Now the dealer does not need to issue, and the formation of a claim for a refund. In the operator’s console, the manager can do it with one button - change the type of service from issue to claim.
- The dealer came to inspect one car, and wants to inspect another. The manager in the operator’s console can replace the car for inspection in the ticket.
SLA monitoring via Telegram
If you carefully looked at the screenshots of the SLA settings above, then you saw there lines related to the messenger. It used to happen that warehouse employees instead of working left to smoke for an hour, and their colleagues had to switch to emergency mode. Now, if an employee has gone to work and does not take dealers for a long time, the management receives a notification of this type:

Or here are such warnings about dealers:

In addition to managers working with dealers, there are technicians in the warehouse who prepare the car for the scheduled inspection time: they dig it out of a snowdrift, fill it with fuel, wash the car, charge the battery, warm up the engine and distill the car from the closed parking lot. A separate channel helps them to learn about the features of the engine start and complete the training faster. Here are some interesting posts:



But this option is perhaps the most original:

Results
With the help of a new electronic queue, we won the chaos in the warehouse, simplified the lives of dealers and gave them a number of additional services. If you list the business indicators, the dealers' waiting time has decreased threefold, the number of negative feedback has quadrupled, and the warehouse with the same number of employees can now skip not 700, but 3000 cars per day. While we are watching the system and in the plans except to put a printer that will print coupons on paper.
Now we are looking for a QA-specialist and backend developer in our Moscow office. We welcome your feedback!