Team KickAss: Work where it hurts
9.2.2022
Translation: machine translated
Named after a superhero, Team KickAss set out to optimize the returns process. They work behind the scenes in a field of tension that has high explosion potential.
When Daniel Gnägi steps onto the mat at the Brazilian Jiu Jitsu Dojo in Zurich, it's not the only fight the 24-year-old has. Because Daniel was actually once an amateur boxer with a lot of potential. Until his shoulder was so injured that he had to hang up his gloves. For good.
But that's not all: Daniel turned his back on his home in eastern Switzerland after graduating, because the first task awaiting the junior software engineer in Zurich after completing his studies is a fight he can't win: Returns.
Daniel is a member of Team KickAss.
"Glorious it is not, but we do it with pride," Daniel says. He sits in an armchair, comfortably reclined, speaking neither loudly nor carelessly. When he's not giving interviews, he's typing away on a keyboard. His language is not German, but C#.
The problem child of every online retailer
When Daniel talks about his work, two things are important to him: He is not the boss of the team. And you have to understand that returns are one of the biggest problems of an online retailer. "Backend processing of returns and warranty cases" or "after sales" is what it's called in the jargon. A topic where retailers try to keep the ball as flat as possible. In an ideal world, everyone should be satisfied with the goods ordered.
"Think about it from digitec's point of view," he says, and begins.
You as a customer buy something on Galaxus. Then it's broken. For some reason. So it has to go back. You either go to one of the nine stores or send the package back. Even then, a process has to catch two variables, if you consider the case of damage as a "case of damage" and not as a split thing like "cell phone: screen broken" and "cell phone: camera broken". Because then two variables should be able to react to two variables.
From there, it gets simpler for a moment: the returned device goes back to After Sales Handling. From the store by truck, otherwise from the post office. Then it gets more complex again. The damage must be assessed. Is the device still salvageable? Then to one of the more than 2000 suppliers with whom Digitec Galaxus works. Postal routes, delivery deadlines, delivery conditions, paperwork requirements for a returned delivery and so on determine the day-to-day work of the after-sales department.
Somewhere in the system, all this has to be intercepted, taken into account and processed. Traceable, efficient and automated as much as possible.
"We're delivering more and more goods, so more and more is coming back," says Daniel.
That's why the battle seems like one he and KickAss can't win. Because no matter how simple the process becomes, how much more efficient and faster: less work doesn't happen in the company's offices and warehouses. And no one is happy with anything.
KickAss takes up the work
"A lot of things were still solved manually," says Daniel, sighing as he thinks back to the beginnings of his team, which were also the beginnings of his professional life and his work at Digitec Galaxus.
Daniel signs up as a solution architect. Voluntarily. And gets the job. Or rather, the role. Daniel Gnägi starts work. It's Kickass' first initiative.
"Working Class Hero" is written on the man's shirt. In a team of seven software engineers and a product owner, he tries to make returns processing as painless as possible.
The battle begins in analyzing the processes already in place. Cutting jobs is not something KickAss believes in. Because if Galaxus is to continue growing, returns will also increase. That's where all the brains will be needed.
"The amount of manual labor that went into the returns processes was shockingly high after all," says Daniel.
Daniel and KickAss are going over the books. Because optimizing processes based on a few minor mishaps doesn't work. The problem has to be systemic for process optimization to make sense. It requires in-depth analysis. Is an issue anecdotal - meaning it happens only once, but spectacularly - or is it systemic and happens every time the process is run?
"Even more generally, first we had to work out what exactly which part of the process wants."
Questions come. And questions. And questions.
The requirements analyses have to sit. Just like the evaluation of new technologies. Simply including a script here or muddling in a few lines there because it seems funny at the time doesn't work. After all, everyone's satisfaction ultimately depends on the work of the team. Customers should have to deal with returns for as short a time as possible. So should the company's employees. Suppliers and repair stations should get all the data they need, and nothing more. The whole thing in a format that suits them, and in the end it all has to be compatible with both Digitec Galaxus and third-party backends.
In between, superfluous process steps and elements have to be eliminated. The less busywork there is, i.e. pointless process steps, the better.
From all this, a draft architecture is created. This then goes through a review. Does everything work? Where are the stumbling blocks? What could be the downfall later? Do we need all of this? Do we need more?
Breathe deeply.
Practical implementation. New technologies? Maybe? Do they deliver what they promise? Are they compatible with us? With others?
Questions pile up. Daniel and KickAss plow through them story by story, sprint by sprint. One after another.
"As lame as it sounds, this was actually highly exciting and fun."
The research, the digging and searching, the discussion about solutions, and the thought that KickAss are the first and only ones to tackle this topic alone: these are the elements Daniel addresses when he talks about having fun.
Let's get to work. Code here, a mask in the proprietary backend there, Daniel and KickAss are automating what they can. The process becomes more streamlined, faster and more impactful. KickAss continues to develop the in-house workflow engine in .NET. Adapts it where necessary, integrates it into the returns process, which it then dominates. Busywork is gradually being eliminated. All of this is tested. Events are sent to the Azure Service Bus at each step of the process so that the data can be analyzed later. Each individual step is tested automatically using unit tests based on NUnit. The entire processes and diagrams are documented in LucidChart.
At the end, KickAss can sit back and relax. Or take the department's own drift go-kart for a spin around the office. Because the process is in place, tested, scalable and ready for rollout.
There is always something to optimize. KickAss fights on.
Journalist. Author. Hacker. A storyteller searching for boundaries, secrets and taboos – putting the world to paper. Not because I can but because I can’t not.