Professional background

I saw the problem by watching how sellers actually worked, and saw that the tag already on the garment could identify it. A dedicated barcode scanner would have meant upfront hardware cost and one more thing to carry and charge, but sellers already had cameras in their phones. I found an app that turned a phone into a barcode reader and filled in the search field, and we demoed it. Sellers loved it, but setup (installing an app, pairing over Bluetooth) meant only the tech-savvy would use it. So I pushed for a proper version: scanned items now go straight into the basket, and the seller only adds sizes and quantities. When I then watched it in use, I saw that the scanning engine struggled with real showroom conditions: worn tags, glare, strong lighting and awkward angles. Adoption was slower than it should have been. I pushed to find a better engine and led the switch.

I tracked down the original requester and asked how they actually used the system. They were checking the rack in the showroom: removing items no longer in stock and adding ones that were. To do it, they started a selling flow just to get at the scanner, put every item on the rack in the basket and submitted the order. Then they intercepted that order in their internal system, exported it to a spreadsheet and compared it by hand to stock numbers, to work out how to change the rack. I knew there had to be a better way, so I built a prototype on the building blocks of the scanner: a separate tool where users scan the items on a rack, get a list, set comparison rules (for example, more than 10 in stock, or discounted by at least a given percentage) and run an automatic check against stock. Users didn't yet trust the system not to make mistakes, and wanted a spreadsheet to check by hand. So I added a spreadsheet export, which I thought might be useful in contexts I couldn't yet foresee. I also let them upload stock details as a spreadsheet and see the automatic comparison in our system. That gave them a way to verify the system for themselves. I stayed with them through testing, took in their feedback, adjusted, and built the final version.

I made it my mission to let people focus on solving problems instead of juggling documents and emails. I started by talking to our contact in the customer's IT department, and together we defined the kinds of requests they send us: bugs, chores and feature requests. Then I talked to the people handling the requests at the time. We found that steps to reproduce, where exactly it happened, which users and workspaces were involved, and screenshots or screen recordings would cut triage time. I added two things: what the user is actually trying to do, and the outcome they want (especially for feature requests), and the name of the original requester, because triage had become a game of telephone up and down the support chain. I set up an online form for each type of case. The spreadsheet it produced quickly became our main issue tracker, and when it had proven itself and started to grow, I asked for help moving to a better tool. We prefer lightweight, self-hosted solutions, so we landed on a NocoDB instance that we still use.

Along the way we learned two things. A requester may see something as a bug while we internally see it as a feature or a chore. Often "the system doesn't work" is actually the software working as intended. So correcting the type of request became an integral step of triage. And a priority or severity scale didn't work: requesters only used the top two levels. After several attempts to tweak it, I realised a quantitative scale wasn't what we needed, and we added a qualitative field asking about the impact on the business. That helped us prioritise.