What is behind the cleanliness in your apartment, or Qlean preparation

Hi, Habr. Many have heard about our service, someone used it, and now we are ripe to tell you about our internal IT-kitchen. In 2014, we started with an office apartment on Arbat (with a meeting in the kitchen), 300 clients and organizing everything with our own hands. All information was recorded in Excel, and the development did not smell. Over time, the number of customers increased, automation was required, and today Qlean is a mature company in which the development department has more than 25 people. Today, through our service, an average of about 1,000 cleanings per day is done by the forces of 3,000 connected performers. We are third in the world after Handy and Helpling abroad in terms of harvesting, and we work in Moscow, St. Petersburg and Yekaterinburg. In this post we will conduct an excursion on the systems of our service and will announce further blog topics.

Technologies and how we implement them

We do not dwell on some programming language, but historically it was that the service was built on Ruby on Rails with coffeescript and other wonders. Now all that remains is api, and from the rails, ActiveRecord and a set of standard gems. We do not really care about fashionable now TrailBlazer and so on, as we try to write simple and clear code that is easy to maintain. In addition to the main application, we have microservices on pure Ruby, for example, for CRM, and a system for hiring artists, several services on Go and a couple on Clojure. We try to divide services according to DDD principles, that is, each service is responsible for some business process: hiring, paying for an order, appointing a contractor, etc. We choose the language based on the specific task and requirements. We have all the frontend on React + Redux, and mobile applications have recently been completely rewritten on React.Native, which allows us to write less code and makes it possible to implement the same functionality on different platforms (both the website and mobile applications) by the same developers. We will tell you about the profit and difficulties of translating native applications to React.Native.
')
In total, we have about 30 different services that live on more than 70 virtual machines, so the code layout is not the most trivial: we use Ansible, Docker and Nomad as an orchestrator. When laying out, a huge number of tests are run (both unit and integration tests), plus we check everything with QA engineers, use canary deploy for complex tasks, so we are not afraid to lay out a lot and often. We have an average of 15 releases a week.

And more?

The system consists of 3 large functional parts: work with clients, performers and distribution of orders among performers.

Customer service

To communicate with customers, we have a website and a mobile application. Here, in principle, everything is approximately standard: marketing, marketing, and again marketing. Behind one big nuance: we are turned on analytics, therefore we trace and we analyze all actions that the user makes. From all devices, events are sent to microservice on Go, which processes and adds the information to the database. Since we love to measure everything, we have a strongly developed culture of experiments and A / B tests. We first check any hypothesis, and the mechanics of the same functionality can simultaneously have up to 5 different implementations, starting from some small things like a credit card data entry form and ending with penalties and subscriptions models. Each experiment has its own dashboards in the analytics system (we use Periscope) and the metrics by which we compare. There is always a control group and we make sure that the experiment is “clean”, that is, the user groups are as identical as possible. We will tell about analytics and A / B tests separately.

Work with klinerami

Any service is based on the performers. In our case, performers come to the apartments of clients, so their quality and professionalism are very important. Before becoming our clinic, a person must undergo several procedures: an interview, a security check, a briefing and a test of knowledge of regulations, and an inventory issue. Until recently, all these procedures took place completely offline, which imposed its limitations on the launch of the service in other regions: we need a warehouse, we need an office, we need a separate call center. Now we are experimenting with a fully automated system of hiring and supplying the contractor. And if there were no problems with hiring, then there is still a long way to go with the supply: we are not yet able to automatically control the inventory of the clinoer. In any case, our main fears have not yet been justified: the system of remote hiring does not affect the quality of performers and service. Therefore, we will develop in this direction further.

Even after the clinic completes our ranks, all orders are not immediately available to him. We carefully conduct it on orders, help and control the quality of work, and over time all orders become available to him. To do this, we have an order visibility matrix, which essentially creates an individual list of available orders.

Distribution of orders

In general, with the distribution of orders is our main challenge. The main motivations of the cliner to work through the system are stable earnings and a guaranteed flow of orders. It seems that everything is simple: I appointed wipers to order and forward, let them wave a mop. In fact, it turns out that someone is ready to clean only on Wednesdays after lunch, someone does not like cats and balconies, and someone wants to clean only the three of them in Butovo. There are also preferences on the part of clients, but of a different nature: we should minimize the number of different wines, ideally for 10 orders a customer should have 2-3 wipers, as few people like that his bedding touches 50 strangers a year. It turns out that the system must take into account all these preferences and select orders for the best match. It would seem that the classical assignment problem, but since the executor can refuse the assigned order, which he did not like, the task becomes nontrivial. And if we consider that the client may suddenly transfer or cancel the order altogether, then we get very strict requirements for the speed of the algorithm. We use complex models that predict the likelihood of cancellation of the order, the likelihood of the client’s exit to a specific order and automatically select the order for the client for which she will most likely agree on the history of her previous orders. Our next article just sheds light on this topic.

In any case, after the appointment remains a number of unsorted orders, they are disassembled by the klinirami through the application. Now we are testing a model with an auction and a dynamic price depending on the number of refusals from a particular order. After a manual fence there is already a small amount of unsorted orders. The day before the order, our call center manually calls the most suitable performers so that clients are not left without a cliner. Sometimes it happens that we can’t pick a performer at all (mainly due to late transfers), but we are working on minimizing this parameter (now up to 5 orders per day are left without performers).

In fact, there are many more details of the system: its own CRM, work with the warehouse, but for a short review article there is already so much information.

We will be happy to answer your questions.

---

Promo code for the first cleaning for users of the habr: habr
Github