Customer Request to Delivery - Closing the CX Loop
One of the most common projects we work on here at Staircase is how to pull a clear signal from the noise of customer feedback. We work with our clients to define the end-to-end process of how requests from customers become new features. We start with an idea proposed by a customer, track it through vetting, development, and release, and then close the loop with the customer who generated the idea by alerting them that their request has been finished. This work ties in closely with the renewed emphasis for product companies to be human-centered and focused on the customer experience (CX).
In this post I’ll describe what a model process looks like and how to get your company there.
Systems and Process
Let’s use an example to illustrate the model process. Imagine you are RideShare, an Uber & Lyft competitor, and a customer requests a new feature. They would like to split the cost of a ride with a friend, just like they would split the cost of dinner at a restaurant.
In order to process this request, RideShare needs a couple of systems in place.
A public facing roadmap - many customers want to track the product development process so they know when new features are release. The roadmap needs to be written in a customer-readable way and should mirror the team’s development backlog. The roadmap should be tagged so it is clear which features are in the backlog, discovery, development, testing, or production. Here's an example from Microsoft.
A method of taking in and storing feedback - feedback comes in from many sources (social, in-app, website, phone calls) and it all should be tagged at entry and stored in one database. For example, Dovetail and Aha Ideas or a custom AirTable.
A public repository for feature requests with a function for voting - understanding how a certain customer requests fits in with the broader array of customer feedback is essential for focusing on high priority and high value requests. Consider ProductBoard or UserVoice.
A process for the product team to investigate and validate features - this process needs to follow the design thinking framework of user research, iterative concept testing, and cross-functional development cycles. This is IBM's Enterprise Design Thinking.
Staircase specializes in helping our clients implement and test these systems during the normal course of business. We can lead the workstream, or partner with an internal lead, to cross-functionally define the vision and mission of the project. Then we choose a vendor, set up a functional prototype, and solicit feedback on the process. Ultimately an internal champion for the products and process to be used is selected and the client takes over the day-to-day operations of the CX loop.
An example of how the process works
Once the system outlined above is implemented, we can see how RideShare would approach working on the cost-split feature request.
First, the request is filtered into the public repository from whichever channel is first appeared in. If this is the first time the request was made, a new and discrete item for this request should be created in the tool. If it isn’t the first time, the request should be added to the existing item. Either way, the person who requested the feature should be notified in the same channel (such as social) that their request is being publicly tracked and reported on.
Second, the product team needs to review the feature request repository to find items they wish to work on. When they choose the Split Ride Payment feature for discovery, the public facing roadmap should indicate that the feature is now being investigated.
Third, the investigation/discovery process should follow a standard design thinking framework. That means before the feature is considered for development, it should go through cycles of user research and concept testing. The good news is that there is a ready-made panel of participants who care about the feature through their interaction with the public repository with whom concepts can be tested.
Fourth, once discovery is complete and the feature is defined, it can be developed and then put into testing. This is when the product team should go back to the feature request repository, find the people who were interested in the feature, and involve them in the testing process.
Fifth, once the feature is cleared for production, the release notes should be updated and sent to anyone following release notes in general for the product, as well as anyone specifically following the feature request.
Staircase is here for your CX journey
The real world workflow to implement this way of working will likely take 1-2 years of building, testing, and learning. At Staircase we lean on a ship-to-learn method of implementation so progress can be seen at every step along the way. We understand that the CX imperative isn’t something that can wait on a multi-year project. That’s why every part of the CX system we are building yields immediate dividends in terms of more closely knit teams and the clear signal that the company is focused on delivering for the customer.
The end goal of closing the CX loop so the company focuses on delivering the most customer value from their product development cycle is a powerful way of keeping both your users and your product teams engaged and happy.