Designing the core delivery flow

Problem

Loggi, initially, was an app where you could basically rent a chunk of a driver's time and order him/her to pick up and deliver whatever and wherever. You could be at the airport, having forgotten your passport, and call a driver asking it to pick it up back at your place so they later delivered it to you at the airport.

Internally, we called this product Corp (as in corporative deliveries - the main customers were accounting firms that had documents going back and forth between offices scattered through town) and it was the flagship through most of Loggi's existence. Naturally, over the years, Loggi started to expand the scope of the logistic service it provided and most of Corp's infrastructure was taken and scaled so new business verticals were supported, such as food delivery and e-commerce.

For years, the company operated in a "we're testing things out" mood, which enabled a lot of iteration and a general no-strings-attached vibe to whatever effort. However, 2019 - when I joined - was not like this. It was the most stable year since the company's beginning in 2014. I believe it was the year the company finally understood what it should be and how to focus its resources. Everything narrowed down for Loggi to become a proper logistics company. By proper, I mean having multiple distribution centers, cross-docking, a complex network of transportation partners and a bunch of motoboys turned into delivery partners spread through continental Brazil. That, expectedly so, caused a major re-org which ended up with me moving from the team I initially was assigned for to the one I stayed in throughout most of my time there, which was meant to focus on reshaping the driver experience.

The thing is, the driver experience reshaping was already in course. Different from 2019, 2018 was one of those years with tons of experimentation. With it, came a new product called Loggi Leve which solved a major canonical logistic problem: capillarity. It was solved by being basically a last-mile franchise model, per se. Leve means light and it resonated with the idea that Loggi would enable anyone who would be willing to partner up to quickly set up alightweight logistic operation. In practice, that meant helping partners to find a real state, teach him or her how to receive, triage, and dispatch packages, and how to deal with finances and overall driver relationship.

For Loggi Leve to happen, a new driver app was created from scratch. It needed to be done from 0 because it needed not only to move faster than the somewhat consolidated flagship but also to have the proper freedom to rethink many of the already in place paradigms that ran inside the company's core operation. We called it internally as Flecha (or arrow, in English, if you will).

From the get-go, Flecha was meant to be the future for the driver experience at Loggi. But, as it was created under a mainly experimental project, a lot more care was needed in order to have it become the main product. And that was the major goal of the team: how to make Flecha actually become the primary driver app, such that it works for most types of drivers and supports every possible delivery use case?

Research and development

Well, to get there, we first had to look down the abysm of technical and operational requirements/challenges. Loggi was a company living under a lot of legacy code, which made refactoring anything a very expansive and dangerous thing to do. So, we had to find ways to make it work without provoking any real downtime for the ongoing day-to-day operation.

Initially, the team and I were in charge of the whole Flecha product, from sign-ups to the actual core experience. It ended up being just too much to handle. So we managed to trim the scope down a little bit, dividing the team into two parts, one to take care only of the core delivery experience. If you think about the journey of a package being delivered, there are really two main pieces: the pick-up and the delivery. Flecha basically was just the delivery part - the last and arguably most important one. So we chose to start from there. The delivery model of the Leve product was considerably different from the Corp model. Therefore, we had to study and research for ways to make both the experience and code generalized enough so we could support different types of drivers and delivery models at the same application (drivers from the Leve model and Corp model had significant different requirements).

It was tough work to pull it off since there were so many impacted teams and moving pieces at once. We established a routine of constant touching base with CX, operations, and commercial teams. It was also a process of a lot of trial and error. With an opportunity of a redesign in hand, we were pushing for ways to simplify and remove stuff while being very careful what to add. We couldn't start everything as fresh as we dreamed but there were still some very sneaky opportunities.

Results

I believe the whole process took about 4 months - one of these being entirely dedicated to a very slow and careful rollout. Again, we couldn't cause any downtime. So we had to play above thin ice, like building an airplane while flying.

As we progressed the rollout across cities, the pile of feedback grew exponentially. Definitely good, in one sense, because we had an enormous amount of insight before even finishing the first rollout. But it was also very challenging as we were doing this amidst a newly remote environment, so making sense of feedback coming from everywhere and in different shapes and forms was hard. The app looked considerably different, compared to when we started, by the time we had only one city left to roll out to. It was very encouraging to see how much progress we made in a short span of time. If I recall correctly, Loggi even paid all of us a dinner as celebration!

We had a number of processes simplified, which definitely made it easier for everyone. We tackled long standing problems that bugged everyone out but no one had just the time to work on them. Of the things we optimized: how drivers reported problems during delivery (which helped a lot with data analytics), how drivers updated the status of a delivery, removing geofencing and making the product reliable and workable even without connection, and how drivers got help when in emergencies, which was something brand new I'm proud to have contributed for.

A blog post like this is never enough for cramming months of work. I won't bore you with all the back and forth it took for pulling the first version of Flecha off but I'm glad to share that we managed to do it so nicely that we ended building somewhat of a reputation for how to roll things out smoothly and carefully. Definitely a nice recognition to have.

It solidified ourselves, the team, as the owners of the driver's codebase, which was also humbling - but at times bad - given that anyone interested to learn how things were under the hood would come to us, so we had to learn how to dodge these bullets in order to focus. Regardless, it was mainly a good thing and I'll be always looking forward to see how the team keeps evolving the product.