
Behind the scenes
From Lego to iPhones, here’s what our customers search for most
by Manuel Wenk
Named after a superhero, Team KickAss has set out to optimise the returns process. They work behind the scenes in a field of tension that has the potential to explode.
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 is involved in. Daniel used to be 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 completing his studies, because the first task awaiting the junior software engineer in Zurich after graduating was a fight he couldn't win: Returns.
Daniel is a member of the KickAss team.
"It's not glorious, but we do it with pride," says Daniel. He sits in an armchair, leaning back comfortably, 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#.
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 for an online retailer. "Back-end processing of returns and warranty cases" or "after sales" is the technical term for this. A topic where retailers try to keep the ball as low as possible. In an ideal world, everyone should be satisfied with the goods they have ordered.
"Think it through from digitec's point of view," he says and begins.
You as a customer buy something on digitec or Galaxus. Then it's broken. For whatever reason. So it has to be returned. You either go to one of the nine stores or send the parcel back. Even then, a process has to intercept two variables if you consider the damage case as a "damage case" and not as a split case such as "mobile: screen broken" and "mobile: camera broken". Because then two variables should be able to react to two variables.
From then on, things get a little simpler: the returned device goes back to After Sales Handling. From the shop by lorry, otherwise from the post office. Then it gets more complex again. The damage must be assessed. Can the appliance still be salvaged? Then to one of the more than 2000 suppliers with whom Digitec Galaxus works. Postal routes, delivery times, delivery conditions, paperwork requirements for a return delivery and so on determine the daily routine of the after-sales department.
Somewhere in the system, all of this has to be intercepted, taken into account and processed. Traceable, efficient and automated as far as possible.
"We are delivering more and more goods, so more and more is coming back," says Daniel.
That's why the battle seems like one that he and KickAss can't win. Because no matter how simple the process becomes, how much more efficient and faster: there is no less work to be done in the company's offices and warehouses. And nobody is happy with anything.
"A lot of things were still solved manually," says Daniel and sighs when 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. As part of a team of seven software engineers and a product owner, he is trying to make returns processing as painless as possible.
The battle begins by analysing the existing processes. KickAss does not believe in cutting jobs. Because if Digitec Galaxus AG is to continue to grow, returns will also increase. All heads will be needed.
"The amount of manual labour involved in the returns processes was shockingly high," says Daniel.
Daniel and KickAss are going over the books. Because optimising processes based on a few small mishaps doesn't work. The problem has to be systemic for process optimisation to make sense. An in-depth analysis is required. Is an issue anecdotal - i.e. does it only happen once, but spectacularly - or is it systemic and happens every time the process is run?
"More generally, we first had to work out what exactly which part of the process wanted."
The requirements analyses have to be right. Just like the evaluation of new technologies. Simply integrating a script here or throwing in a few lines there because it seems fun at the time doesn't work. Because in the end, everyone's satisfaction depends on the team's work. Customers should have as little to do with returns as possible. So should the company's employees. Suppliers and repair centres should receive all the data they need and nothing more. All in a format that suits them, and in the end it all has to be compatible with the backends of both Digitec Galaxus and third parties.
In between, superfluous process steps and elements need to be eliminated. The less busywork there is, i.e. pointless process steps, the better.
A draft architecture is created from all of this. This then goes through a review. Does everything work? Where are the stumbling blocks? What could be a disaster later on? Do we need all this? Do we need more?
Take a deep breath
Practical implementation. New technologies? Perhaps? Do they deliver what they promise? Are they compatible with us? With others?
Questions are piling up. Daniel and KickAss plough through them story by story, sprint by sprint. One after the other.
"As lame as it sounds, it was actually really exciting and fun."
The research, the digging and searching, the discussion about solutions and the idea that KickAss are the first and only ones to dedicate themselves to this topic alone: these are the elements that Daniel refers to when he talks about fun.
Get to work. Code here, a mask in the company's own backend there, Daniel and KickAss automate everything they can. The process becomes more streamlined, faster and more powerful. KickAss continues to develop the in-house workflow engine in .NET. It adapts it where necessary and integrates it into the returns process, which it then dominates. Busywork is gradually being abolished. All of this is tested. Events are sent to the Azure Service Bus at each process step so that the data can be analysed later. Each individual step is tested automatically using unit tests based on NUnit. All the processes and diagrams are documented in LucidChart.
At the end, KickAss can sit back. 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 optimise. KickAss continues to fight.
Team KickAss, just like the rest of Engineering at Digitec Galaxus AG, is looking for reinforcements. You can find open positions at digitec.ch/JobOffer.