MGF5690 Chap.3 New Service Development
New Service Development
New service development joins innovation with process design. Complexity describes how many steps the service contains, while divergence describes how much discretion a server has to customise it. Customer co-production, automation and operational transparency can reduce effort or improve trust, but they can also shift work, expose sensitive processes or remove valuable judgement.
Good design assigns routine rules and uncertain decisions to the right actors.
What this chapter covers
- 01
Radical and incremental service innovation
- 02
Process complexity and handoffs
- 03
Divergence and employee discretion
- 04
Customer co-production and effort
- 05
Operational transparency and trust
- 06
Automation boundaries and human escalation
Worked example · free
Redesign a permit process
- +2Remove repeated data entry and use one verified record across stages.
- +2Show validation, technical review and decision status while preserving expert discretion in unusual cases.
- +2Measure rework, incomplete applications, elapsed time and customer effort, noting integration constraints.
Key terms
- Service complexity
- The number of activities, stages or handoffs in the service process.
- Service divergence
- The freedom available to vary or customise delivery for a customer.
- Operational transparency
- Designed visibility into otherwise hidden service work, progress or effort.
New Service Development FAQ
What is the difference between complexity and divergence?
Complexity counts process steps and handoffs, while divergence concerns discretion within those steps. A service can have many scripted stages or a small number of highly customised interactions, so the two dimensions must be diagnosed separately.
When does transparency improve a service?
Transparency helps when visible progress, timing or effort reduces uncertainty and supports customer action. It can hurt when it exposes sensitive work, creates anxiety or reveals information that the customer cannot interpret or use.
Should every routine service be automated?
Automation fits stable rules with observable errors and manageable consequences. Ambiguous, high-consequence or emotionally sensitive decisions often need a human route, and the handoff must carry information and clear case ownership.
Assessment move
Create a two-axis matrix with complexity and divergence, then place unfamiliar services in it and propose one justified movement. Practise distinguishing a customer-effort problem from a discretion problem and a transparency problem. For reports, describe the current process before recommending technology.
State which step disappears, which judgement remains, how an exception escalates and what evidence would show that the redesign improved completion, effort or reliability rather than only adoption. Start a redesign exercise with the customer's job and the evidence needed for a valid outcome. Map every action, handoff, decision, wait and repeated request in the current process.
Complexity is about the number and arrangement of activities; divergence concerns how much judgement or variation occurs within them. Label both separately so that removing a step is not confused with restricting discretion. Classify each activity as value-creating, necessary support, avoidable work or recovery from an earlier failure. This makes the proposed change traceable.
Removing duplicate data entry addresses complexity; creating a standard rule addresses divergence; showing progress addresses transparency. A technology proposal should name one of those mechanisms rather than using digital adoption as its own justification. Examine where standardisation is appropriate.
Stable, frequent and observable decisions may benefit from a consistent rule, whereas incomplete evidence, high consequence or genuinely varied customer needs may require supported judgement. Preserve an escalation path with case context and ownership whenever the routine design cannot handle an exception. Otherwise simplification can merely hide difficult work until it becomes an urgent failure.
Transparency also requires selection. Decide what customers need to see, when the information becomes useful and what they can do with it. Raw internal detail may increase anxiety, while an honest stage, expected next event and request for action can reduce uncertainty. Compare a minimum useful disclosure with an excessive one and explain the operational cost of maintaining accurate information.
Use the innovation categories to describe scale, not to rank merit. A radical concept can fail through weak operational fit, while an incremental process improvement can remove significant customer effort. Evaluate novelty alongside feasibility, capability, integration, employee adoption and effect on the service promise. When writing the assessment, support the chosen design boundary with research and organisation evidence.
State an assumption explicitly if the case does not reveal process volume, error rates or user capability. Recommend a pilot that can test completion, error, elapsed time, customer effort and exception quality. Add a balancing indicator so faster processing cannot conceal more rework or exclusion.
Finally, rehearse a counterfactual: if demand doubled, a key system failed or a customer could not use the preferred channel, would the redesigned process still reach a valid outcome? Revising the proposal against that scenario produces a more defensible service design.
Working through New Service Development in MGF5690? Sia is AskSia’s AI Management tutor — ask any MGF5690 New Service Development question and get a clear, step-by-step explanation grounded in how MGF5690 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
