Learnings from Designing a Service Automation Solution at Scale
Recently I’ve had the opportunity to work with a cross-functional team, to design, implement and launch a large-scale service automation project. This rollout will support the Service delivery of over 7 million users annually through modern self-service options, providing customers the flexibility to decide on the customer experience they want. I wanted to note down a few learnings from this project here.
Automation and Your Users
It immediately becomes more important to nail down your touchpoints. When automation is involved you have a much lower margin for error to ensure your touchpoints connect with and serve your customer. Automation inherently means you have reduced ability for a talented human to smooth over your service or system gaps. You will have to work extra hard to deliver what feels like a welcoming personalized experience. Customers want zero friction. We interact with steamless, well-polished technology all day long, If your service is choppy and poorly integrated you will stand out. They will avoid this entire section of your service, or bail on you entirely to find a better experience.
Rigorously Involve users and key stakeholders. Collect as much data as you can, both qual and quant, to take a data-driven approach when understanding the problem you’re solving, and the people you’re solving it for. Take a participatory approach. Remember you are ultimately designing for people, not just problems.
Iteration and continuous improvement.
Be iterative. There are inevitably going to be improvements needed, this is unavoidable. Whether an unanticipated edge case arises, or you receive some fantastic feedback, it’s important to leave room for adaptability and improvement. I’ll go one step further, it’s key to not just react to improvement opportunities, You should utilize an agile project framework that inherently prompts you to seek out this continuous product or service improvement even after initial launch. Plan → Design & analyze → implement → review; repeat.
This isn’t just conjecture. The data backs it up. The Standish Group’s 2020 report noted that large projects using an agile-based methodology were twice as likely to succeed when compared to its waterfall alternatives. This gap tightens a bit when looking at small-scale projects, but Agile still comes out on top at about 1.5x the success rate.
You might not always have the liberty to make quick, direct, changes to your live product. Perhaps with so much riding on the stability and consistency of your system, you need to take a more measured approach. This is common, particularly in the public sector where product and service teams need to prioritize reliability over cutting-edge advancement.
To still see the benefits of this iterative method. Swap the implementation step with prototyping, and re-engage with your customers and stakeholders for feedback before implementation. This will slow down end-user whiplash, but keep your improvement cycle rolling. Every iteration allows the team to incorporate lessons learned, and turn them into direct end-product enhancements.
It’s easy to recognize the importance of evolving your product, but it’s another beast to allocate time and resources to constantly evolve and enhance. The key here is shared ownership. Developing an environment where everyone involved, from customer-facing to leadership and technical teams. All should be encouraged to claim an active stake in the success of your project.
Originally published at https://blog.devhmac.com on December 8, 2022.
