The Accidental Telephony Engineer

I've always been something of a jack of all trades. Telephony, however, wasn't one I ever expected to add to the list. Yet here I am — debugging SIP traces, fielding questions from partners who've been in the industry for decades, and somehow becoming the first port of call when a Voice AI implementation needs a steady hand to take it to the finish line.

In the Beginning

I joined Talkative back in April 2019 — nearly seven years ago now. The company was smaller then, the team tight-knit, and customer support was very much an all-hands affair. The CEO and CTO were in the trenches alongside everyone else, and if something needed doing, you did it.

My route into the software world wasn't exactly conventional. I'd dropped out of college when the Co-op offered me a place on their management programme — real world progression felt far more appealing than the classroom, and I've always been someone who learns by doing rather than being taught. Even then, the pull towards technology was hard to ignore. I'd built tools in VB6 to automate management functions and make my day-to-day life easier — enough that my area manager took notice, and I was seconded to head office for three months as a QA on their new back office system, built in the wake of the Co-op's acquisition of Somerfield. That led to a data management role, which felt like a step in the right direction. Eventually I found myself back in retail, but freelancing on the side — building up a portfolio, developing my skills, quietly working towards something bigger.

Talkative was that something bigger — though it didn't come easily. I'd actually applied the year before and failed at the first hurdle, a telephone interview with the CEO. Rather than walk away, I asked what skills and technologies they were looking for, spent the next year teaching myself the stack, and applied again. They took a leap of faith on me, and I've never forgotten it.

My father always gave me one piece of advice about work: do the jobs nobody else wants to do. If redundancies are coming, he'd say, it's never the people who chip in that go first. So when deployments needed support and customers needed help, it was a no-brainer to get involved. The company's success was my success — this was still a young startup, and every contribution made a real difference.

That instinct to show up and help — even when it wasn't strictly my job — started early, and it never really stopped.

The Calling

I'd been at Talkative for several years by this point, and in that time I'd had my hands in almost every corner of the business — building, reviewing, repairing and debugging product, writing documentation, adding automated test coverage, supporting onboarding, untangling complex integrations. If something needed doing, I was usually already involved.

Customers and partners knew me by name. Not because it was my job to be their go-to person, but because I'd been there long enough, and gone deep enough into the product, that I was often the most useful person to have in the room when things got complicated. Talkative had grown significantly — the platform had expanded to meet demand, supporting an ever wider range of integrations and use cases, and with that growth came complexity. I found myself spending a lot of time supporting the CS team as a product expert — complex tickets, tricky implementations, the kind of problems that needed someone who understood the platform from the inside out.

At the same time, something else was happening. Voice AI was taking off — faster than any of us had anticipated. And with it came a new and growing challenge: telephony. Suddenly we weren't just dealing with chat and digital — we were operating in a world of SIP trunks, PBX configurations and audio routing. The gap was real, and it was growing.

So I made the case. I walked into a conversation with our CEO and CTO and said — look, I'm already the person people come to. I know this product inside out, I know our customers, I know our partners. Let me do this properly. Let me be the enabler — internally and externally — while we get serious about understanding this new telephony world we've found ourselves in.

They said yes. And with that, the role of VP of Customer and Product Enablement was born — a title that finally put a name to something I'd already been doing for years.

The Signalling on the Mount

The title was new. The reality, however, arrived faster than any job description could have prepared me for.

Those early days were a whirlwind. The solution was proven in our own environments, but the next challenge was bigger — making sure it could work anywhere, for anyone, across any SIP capable platform. Partners were eager to get ahead of it, to build their own labs, validate their use cases and get in front of their customers with something genuinely exciting. I was the person helping them do that.

That meant getting deep into platforms fast. Joining calls with partners to help them set up labs, working through configurations, and building the kind of hands-on knowledge that only comes from doing. I was meeting with Mitel pre-sales engineers to understand MBG, MiVB and MCX configuration inside out, reaching out across the Mitel ecosystem to make sure we could support every variation a partner might bring to us.

Building out the lab infrastructure to support this came with its own lessons. Getting the architecture right for a robust, repeatable testing environment took iteration — cloud infrastructure costs have a way of focusing the mind when you're moving fast. But the investment was worth it — what came out the other side was a lab setup that could reliably replicate partner environments, recreate edge cases, and document resolutions in a way that made every subsequent engagement smoother than the last.

The docs got written. Then rewritten. Then rewritten again. And then came the packet captures — and with them, a whole new language to learn.

Early on, we were deliberate about building the right knowledge foundations. Our CEO and CTO brought in a trusted friend — someone who'd spent years deep in the Mitel ecosystem — to work through some of the more complex configurations with us. I sat in on those sessions and what followed was one of the most valuable crash courses of my career. I remember him reaching for a pen and paper, jotting down IPs — the MBG, the MiVB — seemingly the most analogue thing in the world in the middle of a complex technical debug. And yet it made complete sense. Suddenly SIP traces started to make sense too. I began to understand what an SBC and MBG actually did, how they sat in the call flow, and the difference between a SIP REFER and a SIP dial. Things that had been a blur of acronyms started to have shape and meaning.

I still reach for a pen and paper every time I debug now. Every single time.

Word spread quickly. Partners who'd heard about the solution wanted to get ahead of it — building their own labs, validating their use cases, getting ready to take it to market. My inbox filled up with partners and engineers eager to get moving, some introduced by Felix or Steve, others who'd heard about the work through the Mitel ecosystem and reached out directly. It was a strong signal that the appetite was real and the timing was right.

The calls kept coming, but something had changed. Where I'd once been working through configurations methodically, cross referencing documentation and building knowledge with each session, I started knowing the answers instinctively. Not referencing — knowing. The Mitel Messiah imagery came later, a running joke born from a string of successful calls where the problems got solved and the answers came without hesitation. A grand exaggeration, naturally — I knew enough to solve the problems in front of me, and that was the honest truth of it. But the joke stuck. Felix started showing the image around at conferences, getting laughs from people I'd never met, and somehow that became part of the story too.

As a UK company operating in a global market, transcending timezones was always going to be part of the story as we grew. The US market took to the solution quickly and enthusiastically — American partners saw the opportunity early and moved fast. As our US presence grew, the timezone challenge naturally became easier to manage. But even then, I'd often find myself joining calls outside of my own working hours — not because it was expected, but because the variety of configurations, the different use cases partners were bringing to the table, and the pace of what we were building together made it somewhere I genuinely wanted to be. When every call has the potential to surface something new, the timezone becomes a detail rather than an obstacle.

The appetite from partners, particularly across the US, meant the work didn't follow a traditional nine to five. At one point, during a working holiday, I found myself joining calls from a caravan in a field — not because I had to, but because each new partner configuration brought something different, something interesting, and frankly I'd have dialled in from a thousand miles away just to see how it unfolded. I even invested in a Starlink to make sure connectivity was never the thing that slowed us down. There's something quietly satisfying about a successful SIP handshake confirmed from the middle of the countryside — and something telling about the fact that I wouldn't have had it any other way.

And then there was the email. A few days ago, our head of sales Steve forwarded me a message from a partner. Some five months earlier they'd been setting up a lab and had reached out for some guidance — their questions were answered quickly, their problem resolved, and they were on their way. The interaction had been brief and efficient. But five months later, the impression had clearly lasted. They wanted to find out who they'd spoken to and get back in touch.

That one felt good.

Let There Be Voice

Voice AI didn't arrive out of nowhere. Senior leadership could see the market opening up, AI was emerging fast, and the last thing anyone wanted was to miss the train. So we started investigating it as a solution — and the moment we demoed the initial version, the response was immediate. Partners wanted it. All of them.

Our existing ties with Mitel only amplified that demand. In November 2024, Mitel and Talkative announced an expanded partnership, bringing Talkative's generative AI tools directly into Mitel's contact centre portfolio — you can read more about that here. The ecosystem was ready, the partnership was strong, and suddenly there was a very clear direction of travel. We had the solution, the partners wanted to sell it, and the train was leaving. We had to deliver.

Crucially though, this was never going to be a Mitel-only story. We built the Voice AI solution to be telephony agnostic — if your platform is SIP capable, it can work with Talkative. That opened the door to something much bigger than a single ecosystem.

We've started using a tagline internally that I think captures it perfectly: IVR is dead, long live Voice AI. The days of "press 1 for sales, press 2 for support" are numbered. What replaces it is something far more capable, far more flexible, and frankly far more human.

What makes Voice AI both exciting and complex in equal measure is that it's essentially limitless. It's powered by the tools you give it — so it's only as capable as what you connect to it. The adoption has been wildly varied. Some customers want a smart auto attendant. Others want it to handle everything a human agent can, and then some. No two deployments have looked the same, and we don't expect that to change.

That variety is what makes it fascinating — and what makes it challenging. Because every new deployment brings new requirements, new integrations, and new telephony infrastructure to navigate. The product had found its market. Now someone had to figure out how to deliver it, at scale, across a growing number of platforms and configurations.

That someone, it turned out, was me.

The Trials

If the Mitel world sounds straightforward, it isn't. Within that ecosystem alone sits a colourful array of platforms — MBG, MiVB, MCX, MX-ONE, MiCC-E, MV-5000, and OpenScape4K, to name a few. Each with its own quirks, its own configuration, its own way of doing things. It's a world we're still working through, still perfecting the story on. But it was the world that built the foundation.

The next step was deliberate. One of my OKRs was simple in concept and ambitious in scope — unlock the world. Prove that the Voice AI solution wasn't tied to a single ecosystem, that it could work with any SIP capable platform, that the story we were telling wasn't just a Mitel story. I needed a testbed.

3CX was the first. And rather amusingly, after the investment in the Mitel lab infrastructure, it turned out to be the cheapest testbed I could have chosen. Within a few hours I had a proof of concept working. A few hours. After everything that had gone into the Mitel setup, the complexity, the configurations, the documentation — here was a completely different platform, and the knowledge transferred. It worked.

That moment was glorious. It wasn't just a technical win — it was confirmation that what I'd learned wasn't platform specific. It was transferable. The sales team now had something new to show prospects, and I documented the whole thing end to end so it was easily reproducible. A new door had opened. In fact, 3CX never really left my setup — to this day, the number in my email signature routes through a Voice AI bot running on 3CX, which eventually finds its way back to me. The bot goes by the name of Clem Fandango — a nod to the comedy show Toast of London — and is prompted to randomly announce "This is Clem Fandango" before getting down to business. It felt only right to use what I'd built, and to have a little fun with it in the process.

AudioCodes and Microsoft Teams came next, and if I'm honest, I expected it to feel like foreign territory. The complexity of the system is real — Direct Routing, SBC configuration, Teams as a telephony platform — it's a different world on the surface. But something interesting happened as I worked through it. I started drawing parallels. The flow started to feel familiar. Knowledge that had surfaced from conversations with partners — bespoke PBXs, forks of similar technology, the importance of SIP headers, the need for E.164 number formatting — started connecting in ways I hadn't anticipated.

A small decision made a big difference too — I added a second PSTN number to simplify the mapping for the PoC deployment, and it brought everything closer to a finished, demonstrable product faster than expected.

By the end of it, I didn't feel like I was in a foreign land at all. I felt like someone who'd done this before. Because in the ways that mattered, I had.

The Gospels

If there's one thing this journey has taught me above everything else, it's that the fastest way to learn something is to find yourself responsible for it before you're ready.

No course could have prepared me for this. No certification, no classroom, no structured curriculum. What actually moved the needle was a willingness to find out — to try things, break things, and then figure out why they broke. Those who know, know. The investment in lab infrastructure wasn't a cost, it was a curriculum. The configurations that didn't work first time, the packet captures that needed a second and third pass — every single one of them taught me something that a working setup never could have.

But here's the thing about becoming the person who knows — the goal was never to be the only person who knew. From early on, every time I figured something out, I wrote it down. Not just for myself, but so the next person didn't have to start from scratch. The documentation wasn't an afterthought, it was part of the job. Every resolved ticket, every working configuration, every hard won debug session became a reference point that the wider team could learn from and build on. Critically, being able to bring that domain knowledge back into the engineering team meant we could shape the product with real world context — building tools that actually mattered to the people using them, prioritising sprints around the problems customers were genuinely hitting, and making product decisions grounded in the reality of how Voice AI gets implemented in the field rather than how we imagined it might be. The VP of Customer and Product Enablement title wasn't just about Andrew being the expert — it was about making that expertise available, scalable, and feeding directly back into what we build and how we build it.

The lab was transformative in that regard too. Having a safe environment to deliberately recreate problems, break things with intention and document the resolution changed everything. It's the difference between knowing something works and understanding why it works. I'd strongly encourage anyone navigating a steep learning curve to invest in their own testbed, however scrappy — the return on investment is enormous.

Each platform I worked through made the next one faster. The Mitel foundation informed the 3CX setup. The 3CX experience surfaced patterns that reappeared in AudioCodes and Teams. Things I'd learned in passing conversations — SIP headers, E.164 formatting, the behaviour of an SBC in a call flow — kept resurfacing in new contexts and clicking into place. Curiosity compounds, if you let it.

And then just when you think you have a handle on it, the landscape gets more colourful. Firewalls. SIP helpers. Fortigate with SIP ALG doing things you didn't ask it to do. Secure connections adding new layers of complexity to configurations that were already delicate. The territory keeps expanding — and honestly, that's part of what keeps it interesting.

Perhaps the most human lesson of all though is this — show up for the hard problems, and then name what you're doing. Don't quietly absorb expanding responsibility and hope someone notices. I spent years being the person people called, the unofficial unblocker, the one who'd stay on the problem until it was solved. The moment I walked into that conversation with our CEO and CTO and put a name to it, everything changed. The VP of Customer and Product Enablement role didn't come from a restructure or a vacancy. It came from recognising what was already happening and having the confidence to formalise it.

If you're somewhere in the middle of your own accidental expertise — knee deep in something you never planned to learn, working through it methodically while projecting quiet confidence — know that it's supposed to feel like that. That's not imposter syndrome. That's just learning at speed.

And on the Seventh Day...

So where does this go from here?

The platform question, in many ways, has been answered. If it speaks SIP, Talkative's Voice AI can work with it — and the work to prove that, document it, and make it reproducible is largely done. The next chapter is less about unlocking new territory and more about showing the world what's possible now that the door is open.

That means building tools. Perfecting prompts. Creating demos that don't just tell people what Voice AI can do, but show them — viscerally, memorably, in a way that makes the possibilities impossible to ignore. It means more labs, more documentation, more integrations. The strength now isn't in the breadth of what we can connect to — it's in the depth of what we can do once we're connected. IVR is dead. What replaces it is only as limited as your imagination and the tools you give it.

I'm excited about that. Genuinely.

And to anyone reading this who finds themselves in the middle of their own accidental expertise — in over your head, learning in real time, working through problems you never expected to face — I want you to know that's not a sign you're in the wrong place. It's a sign you're being stretched, and being stretched is where growth happens. But pick your battles wisely. Learn to triage. Not everything needs solving today, and not every problem needs to be yours alone to carry. The knowledge accumulates if you give it the space to — and the rest, with time and patience, has a habit of falling into place.

Oh — and keep a notepad handy. You'll want somewhere to jot down that PBX IP.