When we started to tell customers about our IVR discovery product, Crawler, a few years ago, I got excited. My excitement wasn’t so much about the IVR discovery capability our development team had put together—it essentially dials into your IVR, reverse engineers it to figure out what it does, and then documents it. Rather, my excitement was for the visual editor we had created that allowed us to see IVRs and call flows for the first time. We were finally able to not only talk about testing, but also about design. This fit in well with our messaging about the benefits of ‘shifting left’—the fact that the earlier you find a defect in the product’s lifecycle, the cheaper it is to fix.
And, this excitement is in fact shared by our customers. Check out this video from [24]7.ai which eloquently describes how our CX Models help them gain precision from their customers, eliminating surprises from UAT.
At the time, I was also doing a lot of research on the Agile and DevOps ways of doing things, an area which I have continued to explore on the Cyara Blog. I understood the need to change an organization’s culture, and how DevOps looked at optimizing the whole end-to-end process the same way that Lean had done for manufacturing.
The Benefits of Shifting Left
I knew all the traditional ways that shifting left reduced costs, such as reducing re-work as there’s no need to re-do the design, code, test, and so on. There is also less context switching because developers aren’t being asked to stop working on that new feature to figure out what they did on the feature they built two months before. When you haven’t shifted left, there is more risk: if you find the defect very late in the lifecycle—for instance, in the user acceptance testing phase—your developers might be cutting corners (adding technical debt) so they don’t have to shift milestones. This can mean things aren’t tested properly, and may actually cause more harm than good, or even cause reputational damage, especially if you end up not being able to deliver on milestones you promised the market, or if you expose your customers to a subpar experience.
Better Experiences by Design
So I knew that the new design collaboration capabilities were going to be good for our customers. But even with all of that, I didn’t understand just how good it would be until recently. Shortly before the holiday season, I read Mik Kersten’s Project to Product book, which I highly recommend for the great insights it provides.
The one insight that really opened my eyes and made me realize the potential is near the end of the book, where Mik explains the biggest difference between Lean for manufacturing and Lean for software development. In manufacturing, the product development—or design process—and the production process are distinct from one another. The former happens once, and the latter happens millions or even billions of times (if you’re lucky). In software development, on the other hand, the design process and the production process are linked and happen the same number of times. This means that any efficiency gains you can bring to the design process are going to have a major impact every single time you create a new, or update an existing, experience.
This year we’re planning a number of new enhancements to the Velocity solution that are really going to boost the efficiency of end-to-end CX development. We’re starting with the addition of decision nodes—adding nodes specifically for the design of natural language understanding steps (for example, for open speech IVRs and chatbots) in the customer journey—and also adding the ability to link interactions in one or more channels together to design, validate, and monitor your customer journeys end-to-end.
I’m really looking forward to this becoming a reality and seeing how customers leverage the solution, as well as the efficiencies it’s going to bring to our whole industry.
To learn more about how Domain Consulting can help you, contact us, or get in touch with your Account Executive.
