← Portfolio

Sitel / PlayStationBuilding a contextual knowledge tool from nothing, before knowing what product management was

1. The Situation

In 2008, I got a job as second-line support at Sitel, a large outsourced call centre, working on Sony PlayStation campaigns. Customers called when their consoles were broken and needed repair or a re-manufactured replacement (Sony’s term for refurbished). Calls covered everything from hardware error codes to publisher contact details to delivery tracking for units in transit.

Each call required finding the right piece of information quickly while a customer was on the line. The challenge was that the information existed, but there was no good way to get to it.

2. The Problem

The knowledge-sharing process at the time was built around Outlook Express inboxes. Reference information for handling different call types was distributed as emails. If you needed to find the contact number for a specific publisher, or the resolution steps for a particular error code, you searched through your inbox.

The inboxes had a file size limit of around 5 megabytes, which meant you could not even retain all of the reference material you needed. Information was scattered, hard to search, and easy to miss. Everyone had the same problem, but it was just how things worked at the time.

I did not want to get used to that process. During my initial training period, I started looking for a way to replace it rather than adapt to it.

3. What I Built

The only tools available to me were Microsoft Excel and VBA. Nothing else was accessible or unblocked. So I built a fully self-contained application within Excel.

It had a single input field. You typed freely, and the system worked out what you meant based on what you entered:

The input field did not require the user to know what category their query fell into. It inferred intent from the format and content of whatever was typed, then routed to the right information. One field, any query, immediate answer.

4. How It Spread

I built the first version during my initial training period and shared it with the people in my training group because they had the same problem I did. They gave me feedback. I iterated. They gave more feedback. I iterated again.

It spread beyond the training group to the wider team. Nobody was told to use it. Nobody mandated it. People used it because it was faster and more reliable than searching through an Outlook inbox mid-call.

I had no idea what product management was at this point. I was just someone who did not like the existing process and knew enough code to do something about it.

5. What Followed

The team at Sitel saw that I could do things they wanted to improve the operations at the site. After three months, they formally asked me to join a newly created special projects team. My title never changed (I was still a “Network Gaming Agent”). I would come in, set my phone status to “white time” (notes and admin), and spend the day solving problems they needed help with rather than taking calls.

At the end of 2008, I was nominated by my colleagues for Agent of the Year and Best Newcomer of the Year.

That led to other work: contributing to an internal intranet, building reports, and creating an offline call logging system so that when the main systems went down, the team had a local backup instead of reverting to handwritten printouts. But all of that came after. The knowledge tool was what opened the door.

6. Looking Back

This was a small thing, built early, with primitive tools.

I saw a process that was not working well, built something with whatever was available, shared it with colleagues, and kept improving it. Adoption was voluntary and it spread because the tool was genuinely useful, not because anyone was told to use it.

The tools were limited (Excel and VBA, nothing else). The single input field was designed so I could type while on a call and get the right answer without having to think about where to look.

An early lesson in building products: solve your own problem, share it, listen, and iterate.