… This is the seventh in a series of posts about how I ended up where I am today.

One of the most hated jobs in Level 2 support is managing the queues. The department is made up of teams who specialise in certain products or areas. I worked in the Application Development support team, but tickets came in for everything.

While on the queue your job is to read every incoming support ticket and figure out where it should go. Which department should handle it. Whether Level 1 (if that’s where it came from) did their due diligence, and if not, follow up. Whether the customer is premium, because only certain people could handle those. Whether the customer has an ongoing relationship with a specific engineer. And then, out of whoever is left, who in that department is the best fit based on workload and specialities.

It was time-consuming, thankless work. When tickets got routed to the wrong group or the wrong person, there were arguments. One person on the team was exceptional at it, could read a ticket and know exactly where it needed to go almost instantly. But for the most part nobody wanted queue duty. People wanted to solve customer problems, not do paperwork.

“You Can’t Automate That”

During a lunchtime conversation about all of this with one of my colleagues, I said why can’t we just automate it. He said it wasn’t possible. You’d need to understand the technology behind each ticket, and simple keyword matching would never be good enough. Too much nuance.

So I wrote out a specification to prove him wrong.

I detailed how we could use NLP trained on existing support tickets to find the best route for incoming ones, combined with an algorithm that could pick the best engineer for the job based on workload, speciality, and past performance.

What I didn’t know when I handed it to him is that he sent it to senior management. They saw merit in what I’d designed and gave me time and a couple of people to help build it out.

93%

Using LanguageWare and the backlog of previous tickets, I created an application to build the NLP dictionary. The team helped test and curate the results. We ran it against real routing decisions to see how it compared.

Your average engineer doing queue duty was about 68% accurate in routing tickets to the right place. The one expert we had, the person everyone wished was on queue permanently, ran at 94%. The routing engine came in at 93%.

Couldn’t beat the expert. But it was close enough to show real promise, and it was consistent. It didn’t have bad days, didn’t get distracted, didn’t resent being on queue duty.

The Side Effects

One of the more interesting things that came out of the engine wasn’t in the original plan. When we took a support ticket and cross-referenced it against the support knowledge base, the system could surface the most relevant help documents. And when we pointed it at source code, it could identify the files most likely to contain the area where a fix should happen.

That was a genuine surprise. We’d built it to route tickets, and it turned out the underlying technology could do something much broader. It could connect a customer’s problem description to the actual knowledge and code that would solve it.

What Came Next

The project didn’t go further. What I didn’t know at the time was that IBM Research were already working on something called Watson, which would be considerably more powerful than anything I could build with LanguageWare and custom algorithms.

But the work wasn’t wasted. Building that system taught me how to think about the gap between what humans do well and what machines can take over. The expert running at 94% wasn’t doing keyword matching. They were drawing on years of context, relationships, and instinct. Getting a machine to 93% meant understanding what they were actually doing and finding a way to approximate it. That’s a problem I’d spend the next decade working on in different forms.

It also caught the attention of the people building Watson. And that’s how I ended up in the conversation that would define the next chapter of my career.

---

This is the seventh in a series of posts about how I ended up where I am today. Next: the pivot from conversational AI to agentic systems, and why everything before this was preparation for what came after.

Next Post | Previous Post

… This is the sixth in a series of posts about how I ended up where I am today.

After a presentation on patents at IBM, I started thinking about what might be patentable. I had this fantastic idea. Spent a couple of days writing up how it would work, built a proof of concept, the whole thing. Went to one of the patent experts with real pride in what I’d done.

They turned around, tapped a couple of words into a search tool, and found a near-identical invention filed a year earlier.

I was crestfallen.

Over the next year and a half I made seven more submissions. Every single one failed to get anywhere close to being valid. Seven ideas I thought were original, seven dead ends.

Rather than keep going solo, I got a mentor. And that changed everything.

What the Mentor Taught Me

The first thing they fixed was my process. I’d been doing it backwards. Building out the whole thing, proof of concept and all, before checking whether the idea had legs. The mentor taught me to flip that around.

Write up the core pieces you believe are novel. Then search. You’re looking for two things: has someone already created this, and does it have value?

A direct hit on an existing patent doesn’t have to be the end. You look at how their idea is implemented and ask how yours improves on it.

One of my earlier rejections was around canary traps. Someone had already filed. So I looked at what they’d done and realised it would never work at enterprise scale. I resubmitted with a method that could handle hundreds of thousands of emails without performance issues.

The important thing is to not do the full work until you know you have something worth building.

The Disclosure Is a Sales Pitch

This was the second shift in thinking. When you write a disclosure, you’re not writing a patent. The lawyer writes the patent. You’re writing a sales pitch to show novelty and value.

Sure, you need an implementation. But if you can’t demonstrate novelty and value, it doesn’t matter how clever the technology is. You need to write in a way that, at minimum, someone in the field can clearly understand what sets your idea apart from everything else. If you can’t do that, you’ve lost your audience before they’ve finished reading.

How to Present

One method I saw from another inventor got their disclosures rated search-1 (the highest value rating) nearly every time. The whole thing took ten to fifteen minutes.

Start by talking about the industry or technology around your disclosure in plain language. Get the panel to understand the narrow area you’re focusing on. Then talk about the limitations of that area, or what’s missing. Then present what’s novel in your proposal.

By the time you reach the third part, they already understand the problem and why it matters. Your solution lands in context rather than in a vacuum. I found that technique useful well beyond patents.

Scaling It Up

Our department had an average of two or three patents a year with not many submissions. I’d gotten a couple by that point, and management asked me to help improve the department’s output.

It became a team effort. The people I worked with brought different strengths to the table. One could speak to upper management and get us the resources we needed, including mentors for the teams. Others were able to organise teams and inspire people to participate, even people who felt they had nothing to contribute. My core role was helping teams flesh out their ideas and present them in a way that showed novelty and value.

Within the first couple of months we had over forty disclosures. Well over half went to search, meaning IBM felt they were worth investing money to investigate further. Many of those went on to publish or file. Even after the initial push, a lot of the people on those teams continued submitting. Some went on to become Master Inventors themselves.

The Title

From that work I got invited to serve on IDT boards, the panels that help people deliver disclosures of value. That combined with meeting the minimum requirements for what a Master Inventor needs, and I finally got awarded the title.

It takes three to five years to achieve. I did it in just under four.

Even with the title, the education gap followed me. Without a PhD, I was often asked to prove my inventions by building them out, or to go beyond the requirements that others with academic credentials didn’t have to meet. It felt unfair at times. But in a strange way, it meant that everything I submitted had been tested. I wasn’t just making stuff up on paper. I’d built the thing.

After the title it turns out the reward is more work. The title is a three-year term that you have to renew with the same level of commitment. I got it renewed for my second term, but after I moved to my new role in Dubai I let it lapse to commit time fully to what I was doing there.

I don’t regret that. The patent work taught me how to think about problems clearly, how to communicate ideas to people who don’t share your context, and how to help other people see the value in what they already know. Those skills followed me into everything I did afterwards.

---

This is the sixth in a series of posts about how I ended up where I am today. Next: how I built a learning system that changed the way our team worked.

Next Post | Previous Post