October 14, 2025 – Duration 00:18:22

S5. Ep.5 The Power of Community-Driven CX Innovation

When OVO Energy set out to scale conversational experiences without sacrificing reliability or empathy, Senior Software Engineer Lucas Woodward brought developer-grade rigor to CX, building front- and back-end chatbots, automated testing pipelines, and real-time observability, then sharing those tools with the community. In this episode of Level Up CX Tech, we sit down with Lucas to explore how platform APIs and CX as Code accelerate safe, repeatable deployments. Why shortening feedback loops with dashboards and sentiment signals matters, and how bringing developers closer to customers creates more human, resilient digital journeys.

Transcript

Marissa: Welcome to Level Up CX Tech. I’m Marisa Gbenro.

Michael: And I’m Michael Logan. In each episode, we delve into the most pressing issues, opportunities, and challenges in customer experience right now, and how you can use CX technology to see real business value. And to discuss some of those real business values, we’re joined today by Lucas Woodward of OVO Energy. Lucas, welcome to the podcast. Welcome.

Lucas: Thank you for having me.

Michael: Can you tell us a little bit about what you do and a little bit about OVO Energy?

Lucas: Yeah, of course. So, OVO Energy is a leading energy provider in the UK. And my role within it is, I have been creating chatbots, not just the front-end chatbots that you might do within Architect and Genesys Cloud, but also the back-end services. So, they can get quite complicated because you’re able to create the back-end services that the front-end chatbot is actually going to use. As part of that, I also kind of build out the processes and pipelines I think you’re going to talk more about.

Marissa: Awesome. And Lucas, can you tell us more about OVO Energy and how your role as a senior software engineer has evolved into this unique position where you’re not just building CX solutions, but you’re also actively sharing your knowledge and tools that you build with the broader CX community?

Lucas: Yeah, of course.

Lucas: So, my involvement with Genesys Cloud started when we first started using it. And I was asked to, as part of the team, create some chatbots. And that’s, as I’ve said, the back-end service as well. But being a software developer, when I started building these chatbots, there are certain things a software developer looks for when building any service. Automated testing, infrastructures as Code, so the ability to redeploy different components across environments.

Lucas: So, as soon as we started building, I started looking for these and started building these pipelines, which I then started sharing with the community.

Lucas: So, these these pipelines, automated pipelines can be often — include, I know when you make a change to a chatbot, you want to test that you’ve correctly made a change. It adheres to the features that you’re expecting. And then, when you’re ready to deploy it, that it’s properly deployed to the correct environments.

Lucas: Within the software development world, you have tooling for this at your disposal. So, it was about learning all of these tools that are available.

Lucas: And in some cases, where they weren’t, where as a software developer, you expect or you’re so used to seeing open-source tooling.

Lucas: Where that wasn’t available, I set about trying to make it myself and then sharing it with the community.

Lucas: And it all started from there.

Lucas: As soon as I started building these things, I was writing blog articles about them.

Lucas: And by the end of it, I managed to get a full kind of end-to-end development process. Like you’d have with any software development project, which they develop in chatbots so much easier. And it’s also provided a vehicle to be able to engage with the wider community.

Michael: So, you’re constantly experimenting and building new solutions from real-time dashboards to automated testing tools. What motivates you to keep experimenting with the new solutions?

Lucas: I think it’s the enjoyment of it.

Lucas: My wife, I’ve agreed with my wife that I have Tuesdays and Thursday evenings, where I can just kind of tinker on the laptop and do my thing.

Lucas: And I have to spend those times kind of writing articles about this.

Lucas: Or kind of create a note that’s stored in it.

Lucas: Or getting proof of concepts that I can then share with the community. And I sat there the other day thinking, why am I doing this? I could just be sat playing a computer game or doing some sketching or something like that. And I realized what’s nice about Genesys Cloud is you have the platform API. And it seems like it’s an API first kind of setup. Like anything I see happening in the UI or by chatbot, there are APIs for that. So it’s like a box of Lego that you can play with. You can make stuff and throw a software developer.

Lucas: That’s really fun.

Lucas: But then there’s another side, you can only go so far with that until you might want to move on to something completely different. On the other side, you have the empathy.

Lucas: What you’re building does affect people’s lives.

Lucas: Within Genesys Cloud, there are tools, there are transcripts, there are sentiment analysis, the voice recordings. All of this allows you to see how what you’re doing impacts the customer. So you have this assignment, being able to build these things, experiment.

Lucas: But that’s coupled with real-world customer or agent experience, and knowing that what you’re building has this empathetic relationship to these people. I think that’s what’s so compelling. So when I create something, often I’ll share it with the community, but if I can take it further, kind of create an open-source tool out of it, or write down details of how other people could have a go at implementing themselves, bring it closer to production, that’s when I get really rewarding.

Marissa: Lucas, to expand on this idea of the empathetic impact and the empathetic thread that you often talk about, which I really appreciate and enjoy so much from the developer perspective, you know, you face challenges like customers submitting meter readings as photos instead of numbers. And when a system isn’t built for something like this, you know, that can be challenging.

Marissa: So what are some of the tools and methods you use to detect issues such as these that customers make, continue to run into, or you on the back end continue to run into when customers are kind of using the technology outside of the parameters? And how do you improve these solutions quickly?

Lucas: It’s trying to make yourself aware as much as possible of how the customer is using the software. This goes for any piece of software that’s being written. And I include chatbots within that. I once looked inside a chatbot just to see how many evaluations there are.

Lucas: And there’s, I came across over 500. And that’s the type of complexity you’d expect in software as well.

Lucas: And in both of these, it’s understanding, like constantly monitoring how the customers are actually using it to check that your assumptions are correct.

Lucas: I mean, as a software developer, you always start with tests upfront.

Lucas: You have an assumption of how the customer is going to use your software, then on this case, chatbot, and you write tests to that, but that will only take you so far. You then need to engage with the customer as much as possible or with the agent to make sure that your expectations as you’re writing it often removed from the customer match what’s actually happening in the real world.

Lucas: I think it’s just ensuring that you’re conscious of that all the time. At a past company, I had a scrum master.

Lucas: And with every ticket we brought in, this was a backend service.

Lucas: It wasn’t obvious how it affected the customer, but with every ticket brought in, he always articulated that, no matter how abstract it seems, it impacts the customer.

Lucas: Every ticket you’re working on affects the customer, and it’s realizing how it would affect the customer. And then understanding whether you’ve had a negative impact, like how can you reduce this feedback loop, or kind of bring yourself closer to the customer to understand that. So with every change, it’s just understanding, how can I understand if this is affecting a customer positively or negatively and improve for that? I think that’s part of the development process, but also the latter stages of kind of observability of a platform.

Lucas: You mentioned, I created a little kind of observability kind of tooling, these chatbots.

Lucas: And it’s that type of thing, kind of direct as many direct interactions as you can with the customer to understand how to find it.

Lucas: But if you can infer that from other sources, like this observability platform is able to understand how customers are going through the bot, or where there are the holdups, where there’s increased latency in service and how that might have detrimental impact on the actual CX flow that the customer is going through. So I think the short answer is, I try to bake it into the entire process as much as possible, even at the start when you start thinking about what you’re going to implement.

Michael: Just to follow up on that, so how have some of the debugging tools like GitHub integrations or even your own framework, testing frameworks, helped you develop more of these tools? What are some of the things you’re doing?

Lucas: It’s what’s been nice about Genesys Cloud and like the CX as Code that John’s team have produced, is that they allow you to put together a pipeline that you’d expect in a software development

Lucas: product as well. And that’s all geared towards ensuring that you can deploy to different environments, you can release your change reliably, and that you have feedback as quickly as possible. So these tools that I’ve helped build and released, or that the community built, or Genesys themselves, when you put them all together, they create this pipeline that allows you to take a simple change, like a feature request in a chatbot, all the way to deploying it to the customer, and checking that they’re using it.

Lucas: And in the very early days, I set about, I mentioned this in the first question, trying to create that pipeline. And it feels like that’s so important, that pipeline. Because what it means is, if you make a simple change, we often start with, software developers often start with tests first. We call it test-driven development. We start by thinking about what we want this new piece of functionality to do, what are the requirements, so we write tests around that. And this open-source testing tool I’ve used is what we’re able to do that in.

Lucas: I’ve just added the ability to use the latest AI models, like Gemini Flash to try and kind of exercise the as Code as much as possible, exercise the change as much as possible, so you have assertions of what you’re expecting to do. So as you’re building, you can test it. Every change you make, you can test that you’re adding functionality and you’re not regressing functionality. With the CX as Code that Genesys created, you can put your chatbot within a file. And what’s good about that is you can store that file in source control.

Lucas: So you’re able to audit every change you make. So as part of this process, you’ve got the testing that you’re doing as you’re working on the chatbot. You then commit it to a source control. And this means that other team members have exposure to it. They can see the changes that you’re making, and they can review it for you, and they pick up on anything you might have overlooked. And then the next stage may be that they agree with the change. We can see all the tests have passed.

Lucas: So you deploy that to a non-product environment, the environment just before production. And because you’re defining it in a file, and then you’re using infrastructures code, which is possible via Genesys’s CX as Code, it’s able to deploy your artifacts. maybe your chatbot, your change to chatbot encompasses a change to a data action and a data table and numerous other components. All of that can be defined in files. And that means that you can deploy all of that to one environment, exactly the same as you would to the other environment.

Lucas: So you have this reproducibility. So once team members are happy with what you’ve done, you can deploy it to the non-product environment. Then you can have testers look at that and try and break it. And then you know, once you’ve made the change, you might have to refine things to change again, have a test again. But with all these tools in place, you can then eventually deploy to your live organization. But you know that what you’re deploying is what has been deployed to non-product, what has been tested elsewhere.

Lucas: So you can reliably deploy these changes across environments, and you have a suite of automated tests. Every time you make the smallest changes to ensure that you’re only improving on things, and then eventually it releases to the customer. And that’s where you have observability, like real-time observability in place. So you can start to check how they’re using it. You can have sessions where you look into how they’re actually using it.

Lucas: You can have these real-time alerts that are telling you I know we’re seeing an increase in flow disconnect errors, a thing they call, where I might just drop a call or route straight to a queue because there’s been a failure. And you can pick up on those, and then you can ensure the stability of the tool, because production can be a very hostile environment. So just being aware of all of that means that, and having that entire pipeline, means that you can have as much assurance as you can build in the process to know that it’s working.

Lucas: It’s working in production.

Marissa: That’s where the developers and customers are now getting closer together because of the tooling such as the ones you just described being built. Can you elaborate on this connection and why you think it’s so important for the future of CX that developers are a lot closer to their end users now?

Lucas: So I’m completely biased as a software engineer. I’ve been one for

Lucas: 15 years. So I my viewpoint comes from that of a software developer and it feels like if you have someone who is on the ground building the thing that the customers use, it can only improve things if they’re as close to the customers possible, if you build up that empathy between the software developer and the customer. When a software engineer is asked to make a change, the software developer has many ways they can implement a change.

Lucas: So having that empathy with the customer means that they’ll try their best to either articulate higher up as to why they might disagree with the change or why they think there’s a better way of doing it to ensure that what is produced is the best that can be produced for the customer. And if there’s an empathetic link, like you feel customers pain. If you’re, if you’re testing something as a software engineer, when you’re manually testing, it’s very easy to test the same way in a very kind of narrow way.

Lucas: You just you’re adding feature, you’re testing that. It’s that one thing you’re testing. And you start to develop these biases, just unconscious biases, about how you’re testing, and it’s usually just for speed, like you want to quickly kind of test something. They change any. This might be that the tenth test you’ve done just for a small change, but have that empathy with the customer – being brought close to the customer, realizing that the change you’re making does have an impact.

Lucas: It might be as simple as how you ask for a piece of information that makes you start thinking of other ways of testing it, other ways of baking in the tests – and I had the. You could expand your test suite to encompass the different ways.

Lucas: But yeah, it’s just thinking more like the customer and realizing that what you’re building has an impact on the customer and it only feels I can improve things if the people on the ground to kind of write the code or in Genesys Cloud Architect tweaking that flow I want the flow file if they can empathize with how it’s going to impact the customer.

Marissa: I would have to agree and I know in previous conversations that we’ve had tools like sentiment analysis also make it a lot easier for you to identify when customers are happy or frustrated or you know things that they’re actually, you know, struggling with in real time.

Lucas: I’ve always had this dream. I’ve not yet said I built it, so how cool would it be if you could link the sentiment of what you build and say you’ve been doing a small feature to implement and then you deploy that like: how cool would it be if you just have a graph where you could see the sentiment, like any change in sentiment as you release the thing. You add in an extra loop within a chat box to ask the customer again or you increase the strictness of some validation rule.

Lucas: That’ll be cool if you had that direct feedback, you could see the sentiment change through sentiment analysis and that you could use that as a way to guide what you’re developing and kind of add it to your observability suite, as well as, of course, looking at how the customers use it and talking to customers about it. It’s just that, all these metrics out there, I just feel like so many opportunities to kind of merge them all together to have a better view, more kind of real-time view awesome what customers are going through.

Michael: For those who want to level up their digital CX experience, whether they’re developers or just getting started in your, in the communities, what’s your best advice for someone that’s diving in now? There’s so much out there. If you can find something that enthuses you, however, you want to learn it, learn about it or share it to find what’s right for you and engage with the community as such. There’s some really clever people out there who are learning this with you. It’s a it’s a huge field and it’s changing all the time term.

Lucas: There’s no lack of opportunity to find something that you find interest within it.

Marissa: Well, Lucas, thank you so much for joining us today. I know that myself, Michael and our audience are eternally grateful – and for listeners. If you like this episode, please subscribe so you’ll get the next one in your feed. Also, be sure to visit Genesys.com to learn more about how you can level up your CX. And until next time, thanks for listening to Level Up CX