Technology can expand what a business is capable of doing. It can make shared information available sooner, enforce a rule consistently, or enable a service that was previously impractical. Transformation occurs when people and processes use those capabilities to deliver a different, dependable outcome. Buying the capability and changing the service are related but separate achievements.
For an executive designing a new digital customer experience, the decision is which service promise the organization can support and how technology, customer participation, and employee judgment must work together. The title should not be read as dismissing engineering. A poor technical design can constrain the service just as an unclear operating process can undermine a good platform.
The practical approach is to prototype the complete service before committing to its full software implementation. This article uses a hypothetical exhibition organizer introducing exhibitor self-service. The focus is joint design of a new service promise, rather than simply automating an existing broken sequence.
Describe the changed service in the customer’s language
Start with what the customer will be able to accomplish. “Launch a portal” describes a delivery activity. “Let an exhibitor select an eligible booth package, submit usable artwork, and see which decisions remain open” describes a service the customer can understand.
State the boundaries of the promise. Which choices are standard? Which need specialist review? What deadlines or dependencies affect completion? A digital interface can make options appear immediately available even when the organization cannot supply them under the requested conditions.
Identify what the customer must contribute. Self-service may require dimensions, artwork, delivery information, or an authorized contact. If customers do not understand those inputs, the business needs guidance, validation, or an assisted route. Moving entry to the customer does not eliminate the work of establishing correct information.
Define completion from both sides. An exhibitor may think submitting a file completes the task, while the organizer needs a production-ready asset that passes specified checks. Use clear states and explanations so the service promise does not rest on incompatible interpretations.
Map the visible experience and the supporting work
Draw a service map with customer actions, employee actions, system behavior, and external dependencies. Connect each visible step to the work that makes it possible. This reveals where a simple interface depends on specialist capacity, approved rules, or information from another party.
For each step, ask what technology does well and where human judgment remains useful. A system can check a supported file type or identify a missing field. A specialist may need to assess whether an unusual design can be delivered within the event’s constraints. Treat those responsibilities deliberately.
Include the work before and after the main interaction. Customers may need to prepare information before opening the portal, and employees may need to reconcile changes after submission. A service map that begins at login and ends at Submit can miss much of the real effort.
GAO’s process-reengineering guidance connects customer needs and performance problems with process design and organizational implementation. Used here, it supports considering the complete service rather than treating a technology selection as the design itself. GAO, Business Process Reengineering Assessment Guide, 1997
A hypothetical exhibitor service
Imagine a hypothetical exhibition organizer offering standard booth packages through a digital service. Exhibitors can choose an eligible package, provide branding assets, identify a delivery contact, and review the status of outstanding decisions. Custom requests remain available through a specialist route.
The initial software proposal presents every package as a selectable option and accepts uploaded artwork immediately. During a service prototype, the team discovers that some combinations are unavailable at particular venue locations and that many exhibitors interpret upload success as artwork approval.
The redesigned service changes more than the screen. Operations maintains an approved set of location-specific options. The creative team defines what makes artwork usable and provides examples. Customer support owns an assisted path for exhibitors who cannot prepare the required material. The platform displays received, needs correction, approved, and superseded states with their meanings.
A late artwork change illustrates the joint design. The exhibitor can request a replacement, but the service first establishes whether production has begun and which consequences apply under the approved process. A specialist resolves cases outside the standard rule. The system preserves the approved version so a later upload cannot silently replace material already released to production.
The new service also changes employee work. Staff spend less time answering where a file is and more time resolving unusual requests. That shift needs training, queue ownership, and capacity. The business cannot assume that the remaining exceptions are as quick to handle as routine status questions.
The pilot succeeds only if exhibitors reach a usable outcome and the receiving teams can deliver it. A higher upload count would not establish that the experience improved. The organizer must inspect correction cycles, unresolved choices, production misunderstandings, and the effort required from customers and employees.
Prototype responsibilities before building every feature
Use a low-cost representation of the service to test the difficult decisions. This might combine a simple form, sample status messages, and a manually operated receiving process. The aim is to learn whether the proposed roles and rules make sense before encoding them deeply.
Choose scenarios that expose the service boundary: a standard request, an unsupported combination, missing information, a late change, and a customer needing assistance. Ask both customers and employees to explain what they believe happens next.
Record the support effort required to make the prototype work. If a project specialist quietly fixes every submission, that labor is part of the service being tested. Decide whether it will remain, be reduced through better design, or require a narrower promise.
Do not confuse a manual prototype with proof of technical scalability. Once the service logic is coherent, test performance, integration, access, and reliability in the intended environment. Organizational and technical evidence complement one another.
Give people usable responsibility
A role description should identify decisions, information, authority, and the point of handoff. “Support the portal” is insufficient. A creative reviewer needs to know what they can approve, what requires clarification, and how their decision reaches production.
Make expertise accessible without turning specialists into a universal queue. Clear examples and rules can help routine cases proceed, while unusual cases receive focused judgment. The service should capture enough context that specialists do not have to restart discovery.
Train around complete tasks and exceptions. Employees need to understand why a status changes, how to correct an error, and what a customer sees. A feature tour does not establish that people can coordinate a late change across several teams.
Review whether the new service alters relationships. Customers may lose an informal contact they relied on, and employees may lose discretion that previously helped solve unusual problems. Preserve the useful function through an explicit assisted route rather than assuming every informal interaction was waste.
Let technical constraints influence the design honestly
Some service ideas depend on information that cannot yet be obtained reliably. An immediate availability promise may require current venue options or production capacity. If those sources are incomplete, the business may need a provisional request rather than instant confirmation.
A platform’s limitations can also change the sensible scope. If version control cannot reliably distinguish approved artwork from a new upload, the organization should resolve that design before promising self-service late changes. Training users to remember which file counts is a fragile substitute.
Evaluate alternatives rather than forcing every requirement into one tool. A standard package flow may fit a simple portal, while a complex custom design may need a collaborative review workspace. Consistency of the service does not require identical interaction for every case.
Make tradeoffs visible to the sponsor. A narrower first service may deliver value sooner with less risk. A broader design may justify additional integration or specialist capacity. Choose based on the complete operating cost and customer outcome, not on the desire to display the most features at launch.
Measure whether the new service works
Track successful completion, correction cycles, unresolved exceptions, and the effort imposed on both customer and staff. Use definitions that distinguish received information from accepted work. Segment standard and custom requests so their different demands remain visible.
Compare the new journey with a credible baseline. If the pilot receives simpler requests or extra support, report that limitation. An improvement under those conditions may still be useful, but it does not establish the same result across the entire event portfolio.
Inspect failures qualitatively as well as numerically. A small number of late misunderstandings may reveal a major weakness in the promise or version handoff. Counts alone may not show why the service failed or which change would help.
Assign an owner to maintain the service after launch. Package rules, examples, support routes, and production dependencies will change. A service that worked during the project can deteriorate if nobody owns those adjustments once implementation staff leave.
Fund the service rather than the interface alone
The executive should ask for a coherent proposal covering the customer promise, supporting roles, maintained rules, technical capabilities, assisted routes, and outcome measures. Each element should have an owner and enough capacity to operate.
Begin with one meaningful customer journey and test it from preparation to accepted outcome. Use the findings to decide what people must do differently, what process must change, and what technology must reliably support. Transformation follows when those elements create a better service together. The platform is valuable because of the work it enables the organization and its customers to complete.
