Customer self service applications come in many shapes and sizes. But they all enable the customer to do more of the sales work themselves which leads to increased customer engagement and should free up considerable time and resources for the internal sales team.
Taking the step from internal sales applications to public ones can however be challenging since it requires a new perspective (the customers) on pretty much everything in an app compared to what previous solutions have been optimized for (the experts). There are lots to be learned along the way when releasing the first customer self service application.
To minimize the risk of a huge development project that costs a fortune, takes forever to complete and is used by nobody afterwards, we have collected some general principles below that can help smooth the ride when developing your first customer self service application. Use the principles below together with our project plan template for implementing a CPQ.
- Limit the scope and set the goal to cover max 80% of cases – never 100%
Even when the customers start using self service applications to drive sales themselves, there will always be internal sales staff in the background. Therefore you don’t need to aim for 100% coverage of sales cases for the customer self service application. Max 80% is a good rule of thumb, but you can go even lower. The last 20% tends to drive a lot of unnecessary complexity for the customers (more buttons, inputs and menus) and development costs. Internal sales should always pick up where public sales applications end. - Release a basic version of the app as early as possible to real users
This is often referred to as releasing a Minimum Viable Product (MVP). Before the first version of an app is released and used by anyone it’s a potential revolution to the company. The reality however is that it usually takes time to get both customers and internal sales to change their behavior. Due to this it’s a common mistake to postpone the release and keep adding new features just to get that revolution on first release. Making an early release to real users also helps with early feedback that can help correct the development road map. - Encourage feedback, but beware of scope creep
Feedback and suggestions for improvement is very important to collect if an app is to be used frequently. But it’s very important to separate what’s important in the near future from what can be nice to add in the future. Creating a list sorted in prioritized order helps prevent scope creep for the developers and keeps the focus on what’s most value-adding. - Ensure internal sales also has reason to use customer self service apps
Developing applications that should be used by others and not by the company itself tend to function poorly over time. Using the customer’s app internally is usually a good way of adding improvements, handling product changes and finding errors. - Don’t be afraid of manual processes in the beginning
The goal with a customer self service app is very high automation but that does not mean that you have to wait until everything is automated before it’s put into use. As soon as the customer is done and presses a button for “Quote Request” or “Buy” you don’t have to have the entire customer portal or cart ready. An automated email to the internal sales team could be enough in the first release to start taking orders and quote requests through the new sales application. It also results in very hands-on feedback for the sales team about what customers are looking for in the beginning. Then you have plenty of time to set up that customer portal or checkout service that handles everything automatically one day. - Save the polish for later
You can spend endless time and effort on appearance and style. Therefore it’s a bad idea to focus too much on polish and finish in the earlier stages of a development project. It’s often more important to get functionality and processes working so that an app can start delivering value. There are many ways of ensuring that the customer understands that what the application shows is not the final product (pictures, explanation texts, sketch-like appearance, etc). - Skip the release party – celebrate on results
When spending time and money on developing new solutions it is natural that people want to celebrate the release. This is often dangerous on first release since it tends to increase the focus on polish and many features instead of a quick release for early feedback. It’s usually better to release it internally, or towards a limited group of customers, without the parade so that it gets to run for a while before announcing it to everyone else. Celebrating the 100th self service order is then a much more safe announcement to the world without having to worry about early bugs and flaws in the application. - Set a recurring budget, not just a one time sum
Getting the first version of an application out should be possible to cost estimate and create a budget for. But automation is addictive and tools that are frequently used will require maintenance due to upgrades and errors due to feedback and feature requests. Therefore every modern sales team should set aside an IT budget that can be used throughout the year to implement feedback or adjustments that can improve the tools and processes even further.
We hope that these principles can be useful and help you to lay out your project in a tactical way. Do you have any questions? Feel free to contact us and we can discuss your needs.