My role and contribution
Over the last few weeks, my team and I had been developing an AI-based prototype for online returns inspection. The goal of our model was to partially automate the returns process for Inditex. In order to select a project idea, each member brainstormed a few concepts of their own and picked one that seemed most promising. My idea made the cut since the prototype seemed the most feasible. The problem scope was well-defined and supported by the professor. My main part in this project consisted of drafting the “Problem”, “Opportunity”, and “Business model” components, and then turning them into slides. This required extensive research on the current scale and costs of online returns, benefits of AI automation, and value potential for Inditex’s main stakeholders. My other roles also included supporting others’ research by suggesting potential sources and datasets, helping design the automated inspection process, and exploring solutions to online returns fraud.
Important decisions and iterations
A big decision for me, regarded representing the scale and uncaptured value of the online returns issue. I wanted to show the reader how many online-bought items end up being returned and how much those returns cost Inditex (something the brand does not officially disclose). It was a challenge to find adequate research regarding fashion retail. Therefore, I used statistics from an industry benchmarking article to come up with a proxy, since I wanted to give a concrete number. I came to the conclusion, that my final estimation was too uncertain, as the observable data ranged significantly (e.g. processing a returned apparel item indicated to cost 20%-65% of item value). My decision and subsequent solution was to let go of calculating a proxy. Instead I used different pieces of data, that when interpreted together signalled the scale of the online returns problem. At first, I wanted to calculate a grounded number to make the problem sound convincing. Then, I realized too many assumptions needed to hold to justify such number and had to abandon my initial idea. This taught me to approach my reasoning with honest scepticism and make use of available resources. Another pivotal decision was to narrow down the scope of economic calculations. My team determined that Inditex’s operational capacity is far too broad and therefore financial feasibility estimates of our project would bring ambiguous results. Therefore, we decided to focus on Inditex’s largest brand – Zara instead. The learning outcome of this roadblock was how important it is to define a manageable scope. A well-defined scope facilitates choosing relevant criteria that affect it.
What surprised or failed
What I think surprised me the most throughout the conception of the project was how impressive the prototype turned out to be. I was very happy to see our idea come to life and I think my teammate did an incredible job coding the model. I have programmed a machine learning model once before, and seeing the working prototype in action gave me a similar feeling of excitement to when I first deployed my own model. One limitation which kind of let me down was that our model moved 12 out of 24 cases for human inspection. This means an escalation rate of 50%, which significantly surpassed my team’s optimistic target of under 30%. This observation was detrimental for our project, since a large part of Inditex returns would still have to be manually checked under this prototype. This in turn would substantially reduce the labour savings proposed by automation. However, I also should acknowledge that the evaluated sample was relatively small (24 cases), and some cases were difficult on purpose. In retrospect, I feel like the results could have been more representative with a more realistic sample, for example a larger, randomly sampled number of cases. All in all, I was pleasantly surprised with the prototype my teammate built, but it should be tested further. I also think that having more accurate results would allow for better estimation of the value created and captured by this change of workflow.
How feedback and evidence changed the workflow
My teammates’ feedback changed my understanding of the online returns automation design. What I had in mind while coming up with the proposed idea was that the inspections would take place within Inditex’s facilities. To prevent return fraud, I visualized a process, where the returns move on a conveyor belt, with a camera taking pictures of each clothing item, and a mechanical arm rotates the clothes for better visibility. My perspective quickly shifted when two of my teammates pointed out that such physical requirements would imply very high operational and fixed costs. They made me realize, that continuing with my suggested process framework would make economic feasibility estimates much more uncertain, and the overall project financially inefficient. This piece of feedback made my team consider a completely different perspective and come up with an idea that the customer takes and uploads the picture of the returning article. Accounting for potential return fraud attempts, my teammate recommended introducing a direct capture feature to the prototype. This would require the user to submit the clothing photos at the same time of them being taken to prevent AI-enhanced or generated uploads. My teammates’ feedback helped me realize logic gaps within my thinking that I previously overlooked. I also understood that solving one problem (reliance on physical assets) could result in others (potential returns fraud).
What I learned from collaboration
My team’s collaboration consisted of weekly online meetings, where we would assign responsibilities and share our ideas, struggles, and solutions. Something that worked very well for us was clear task division. Since everyone had a good understanding of what their role is, all jobs were completed on time. Clear communication and feedback between the teammates helped us quickly discover problems and find reliable solutions together. What unfortunately did not work, was that every team member had multiple other assignments and exams to finish during that period. Because of that, it may seem that certain elements of the slide deck still require more polishing. Looking back, I also wish we reviewed each other’s parts more frequently and with better care. In retrospect, if I had another chance at the project, I would put more emphasis on good coordination. I would try to schedule earlier, more regular deadlines to make sure the team stays on track. I would also encourage my group to be more sceptical on their project reviews.
How the project changed my understanding of AI
I remember, I had one major doubt while undertaking this project. Creating business value with AI can oftentimes surface various ethical questions. I feel like many people nowadays feel threatened and vulnerable about AI taking over their jobs. Unfortunately, the returns automation idea would not reassure this insecurity. To create value for Inditex, this concept would have to involve certain layoffs. If this project were to succeed, I think a very small circle of people would highly benefit, while a much greater group would suffer. Here, I am referring to Inditex’s shareholders as the main beneficiary, and the warehouse inspection staff as the main victim. So, the ethical question I would like to give is whether the overall value for this small group (which I could argue may be already very wealthy) is higher than the existing value for the more vulnerable group touched by this optimizing endeavour.
