Every customer journey begins with a prediction: someone will arrive with a particular need, supply the expected information and follow a sequence we have designed. The prediction becomes expensive when real circumstances refuse to fit.
Journey design has an important role. It can expose confusing handoffs and make common tasks easier. But treating every possible interaction as something to configure in advance creates a growing maintenance obligation. The question is whether the journey must remain the primary unit of implementation.
A form describes a path, not the whole job
A programme transfer form might ask for a child’s name, current programme and preferred replacement. The actual job is larger: determine who may request the change, confirm eligibility, check capacity, calculate any financial effect and communicate the result.
Now vary the circumstances. The preferred programme is full. The parent has two children. A discount applies to the existing booking. The transfer falls outside the normal window. Each variation can require a new branch, an extra screen or a manual exception. The customer’s intention has barely changed, but the implementation keeps expanding.
Decision trees are useful until they become the policy
A controlled sequence is appropriate when a process must occur in a particular order. The difficulty arises when business policy is scattered across screen logic, validation rules and staff instructions. Changing the policy then means finding every place where it was encoded.
A team may believe it has one rule about transfers while maintaining several interpretations across different channels. More configuration does not necessarily produce more control. A clear policy with an accountable owner is a stronger foundation than an increasingly elaborate collection of paths.
Start with the job and its boundaries
A useful job definition describes the intended result and the conditions under which it is allowed. For the transfer example: move an eligible child to an available programme, with the authorised parent’s confirmation of any fee change, and refer exceptions to staff.
That definition separates four concerns: the customer’s outcome, the information needed to decide, the policy that constrains the decision and the actions the systems can execute. It gives a team something concrete to evaluate without assuming that every customer must navigate the same screens.
Adaptability still needs governance
An intelligent service interprets a request, asks for missing information and selects among authorised actions. This does not make system controls optional. Identity, record access, validation, confirmation and approval must be enforced independently of how persuasively someone describes their request.
Nor should uncertainty be hidden behind a confident answer. If policy is ambiguous, the service should seek clarification or involve an authorised person. If a connected system cannot perform the action, a different conversational path cannot manufacture that capability.
Keep the journeys that earn their place
Some experiences benefit from a structured interface: comparing many options visually, reviewing a long record or completing a tightly regulated sequence. An adaptive approach need not remove these. It should help the organisation decide where a predefined interface adds value and where it merely exposes internal complexity to the customer.
For a pilot, choose a job with meaningful variations and agreed boundaries. Test an ordinary case, a missing-information case, an unauthorised request and an exception. Check whether the outcome remains reliable as the circumstances change, rather than judging only the smoothest demonstration.
Avelyndo’s operating model starts with capabilities and policies instead of an exhaustive catalogue of customer paths. The test of that model is practical: can it complete the agreed jobs with less ongoing journey maintenance, while preserving control?