# Stop trying to digitalize everything **Author:** Ivan Misic **Published:** 2026-01-16 **URL:** https://ivanmisic.net/blog/digital-transformation/stop-trying-to-digitalize-everything **TL;DR** Do not delay a clean common journey while reproducing every legacy exception. Use real demand, completion, support, harm, and regulatory evidence to decide the first boundary, then add another case only when it earns its place. Keep an accessible assisted route for people who cannot finish digitally, carry their known information into the handoff, and measure successful completion rather than only channel reduction. The often-used 80% is a prioritization question, not a target every service must meet. Do not delay a clean common journey while trying to reproduce every legacy exception. In one transformation program I worked on, the team tried to map almost every service request into one self-service release. Everything. That was the mistake. The result became difficult to navigate and expensive to maintain. The next version focused on a small group of common requests, and both adoption and customer feedback improved. Edge cases still mattered, but they needed a different route. ## Completeness is not the goal Legacy processes collect exceptions over years. A person in a branch or contact centre can listen, ask another question, and adapt. A digital form needs every condition expressed in advance. When a team copies every exception into the first release, the common path becomes harder to find and test. The new product starts carrying the same complexity as the old process. I would start with the requests that have high demand and a short, stable path. Use real contact reasons, completion rates, support demand, and exception frequency to choose the boundary. The 80% rule is useful as a prioritisation question, not as a required distribution. Your data may say 65%, 82%, or something else. The point is to avoid holding the common journey hostage to a low-volume case. ## Keep a human handoff A customer who cannot finish the digital path should not have to start again. Carry the known information into the assisted channel. Tell the agent where the customer stopped and what failed. Make the handoff visible before the user reaches a dead end. Some cases should remain assisted. A disputed claim, a complex life event, or a request that needs judgment may be better handled by a person. Keeping that case assisted can be the right product decision. Make the digital route faster and easier, but keep an accessible assisted route for customers who cannot complete it. Measure whether people finish successfully, not only whether calls or branch visits decline. Before adding fees or removing a channel, check the accessibility, consumer-protection, and sector rules that apply in each market. Saving operating cost does not justify trapping a customer in a route they cannot use. ## Use the employee-training test One test has stayed useful for me: if employees need training to complete a process in the internal system, customers will probably struggle to complete the same logic without help. That does not mean the journey can never become self-service. It means the team should first remove steps, clarify decisions, or narrow the request. Putting the same complexity behind a nicer screen changes little. Ask someone who handles the case today: - Which step needs judgment rather than information? - Which exceptions appear often enough to design for? - What information is usually missing? - When does the person need another team or system? The answers tell you which steps can stay digital and where a person needs to take over. ## Put the trade-off in the room Every exception has an owner who can explain why it matters. They may be right. The problem is that adding it still consumes time and adds another path to test and maintain. Do not argue with a stakeholder using a standard 80/20 ratio. Put the real trade-off in the room: - How much would this exception delay the common journey? - How many customers are waiting for the common journey? - How often does the exception occur? - What harm appears if it is handled by a person for now? - When will we review the decision again? Use measured numbers from the product. If the request has high customer harm, regulatory importance, or operating cost, low volume may not matter. If nobody can show the demand or risk, it should not automatically block the release. The strongest response I have found is to make the opportunity cost visible. “Which agreed outcome should we deprioritize to include this?” changes the conversation from whether the stakeholder matters to which result matters more now. ## Compare the transition costs Keeping an assisted route often means integrating a new journey with an old system. Customer state needs to carry across channels, and the handoff itself needs testing. Compare that work with the cost of building, testing, and maintaining each low-volume flow. In some systems the handoff is cheaper. In others the integration or compliance work can change the decision. Do the comparison instead of assuming that one complete replacement is simpler. The temporary setup still needs an owner and a clear point when it will be removed. ## Add the next case when it earns its place Launch the common journeys, then watch where people stop, call, or ask for help. Review the cases outside the digital path using volume, customer harm, operating cost, and legal obligations. Build the next one when that evidence justifies it. Improve the handoff for the rest.