1. Starting point and outputs
Who benefits
- Service owners, operations directors, and service-user centers
- Organizational development, quality, and digital transformation teams
- Procedure, data, and interdepartmental coordination specialists
What you will produce
- A documented map of the current journey, delays, and rework
- An improved procedure design with responsibilities, controls, and exceptions
- A limited pilot comparing performance before and after the change
- An operations manual, monitoring dashboard, and continuous improvement plan
Inputs to prepare
- The service definition, its start and end points, user groups, and access channels
- Dated transaction samples covering completed, pending, and withdrawn cases
- Approved procedures and the reasons for document and approval requirements
- Complaints, interviews, and observations from frontline and back-office staff
- A service owner and a team including operations, technology, and legal affairs where needed
2. Working methodology
See the whole journey
The journey starts when a user tries to achieve their purpose; it may begin before submitting a request and continue after receiving the output. Examine what they do beyond the organization's screen: obtaining a document, visiting another organization, or contacting the service again. The UK government service manual emphasizes understanding the problem and its context and testing assumptions. It is used here as a general principle; the implementation procedures and templates below are an approach proposed by the Union.
Value, control, and accessibility
Classify each step: it serves a user purpose, provides a necessary control, or has no apparent justified purpose. Do not automatically remove controls to reduce time; examine whether they can be combined, performed once, or targeted at cases requiring them, within authorized limits. Compare solutions across channels, because improving the digital channel may shift the burden to the telephone, an employee, or a user who needs assistance.
Verifiable improvement
Every change needs a testable hypothesis, an improvement indicator, and a safeguard indicator. For example, clarifying the document checklist may reduce requests for missing information, while the incorrect rejection rate is monitored so speed is not presented as success at the expense of fairness. Durations and volumes below are planning examples, rather than binding service limits or guaranteed results.
This is an adaptable practical approach developed by the Union with reference to the sources below. Adjust steps, timeframes and measures to the organization and its data. It is not a certificate of compliance or accreditation by the referenced organizations.
3. Implementation steps
1 Choose a service and define success
Start with a service that has a clear problem, a tangible impact, and an owner able to make decisions. State whom it serves, its final outcome, where it starts and ends, and which channels and exceptions are in scope. Define success through a combination of time, quality, effort, and fairness. Record project exclusions and constraints requiring another authority's approval so the initiative does not expand beyond delivery capacity.
- Suggested owner
- Development sponsor and service owner
- Required output
- A short improvement charter
- Progression check
- The team agrees on one definition of a complete request and its outcome
2 Build a reliable baseline
Extract transactions from a period representing normal demand, then review timestamp completeness and transaction status definitions. Separate simple from complex cases, and do not automatically exclude overdue cases. Measure time from the agreed start point to the outcome, stating whether calendar or working days are used. Record demand volume, resources, and concurrent changes, and show missing and pending cases to avoid a misleading view of performance.
- Suggested owner
- Performance analyst and operations manager
- Required output
- A baseline and data quality statement
- Progression check
- Figures can be recalculated from the sample records
3 Document the journey and actual procedure
Follow a number of transactions from the user's perspective and observe actual work with employees. For every step, map the input, output, person performing it, system, waiting time, and handoff to the next party. Record unclear messages, data re-entry, and points where people with different needs get stuck. Compare practice with the written manual; the gap between them may explain the problem better than the form's design itself.
- Suggested owner
- Procedure analyst and service-user representative
- Required output
- A journey map and current procedure map
- Progression check
- Those responsible for the steps reviewed the map and confirmed that it reflects actual practice
4 Analyze causes and prioritize improvement opportunities
Classify causes of delay and rework by frequency and impact, then test likely causes against records and observations. If a transaction is waiting for approval, ask why approval is required, when it is requested, and what delegation limits apply. Assess opportunities by user benefit, implementation effort, risk, and dependencies on other parties. Separate facts from assumptions and identify the data needed to resolve each material assumption before adopting a solution.
- Suggested owner
- Improvement team and process owner
- Required output
- A list of documented causes and prioritized opportunities
- Progression check
- Each opportunity targets a cause and has supporting evidence, rather than an impression alone
5 Design the improved procedure
Start with the simplest change that addresses the cause: standardized instructions, removing duplication, early verification, or moving a decision to the authorized level. Write the normal path, exceptions, authority limits, and escalation route. For each required document, record its purpose and the authority permitted to change the requirement. Then identify what can be automated after simplification. Review the design's effects on records, privacy, service accessibility, and operational continuity.
- Suggested owner
- Service owner, operations, and specialists
- Required output
- An improved procedure, forms, and defined authorities
- Progression check
- No necessary control disappears without an approved alternative
6 Test the solution with users and employees
Test the form or instructions with people representing target groups, asking them to perform a realistically worded task without explanations that lead them to the answer. Record difficulties, questions, and time. Run a limited operational pilot with a defined scope and a rollback route if a material problem emerges. Compare similar cases and monitor quality and backlogs in downstream departments so the bottleneck does not move beyond the part being measured.
- Suggested owner
- Pilot lead and quality officer
- Required output
- A pilot report and a decision to adjust or scale up
- Progression check
- Continuation and stopping criteria are agreed before the pilot
7 Approve the procedure and prepare operations
Update the service manual, staff instructions, forms, messages, and published timeframe if its revision is approved. Specify the version's effective date and how transactions started earlier will be handled. Train staff on routine and exceptional cases, and check every channel for consistent information. Archive the previous version for authorized reference and stop using its operational copies so teams do not work under different rules.
- Suggested owner
- Procedure owner and operations management
- Required output
- An approved operational version and transition plan
- Progression check
- Website, front-desk, telephone, and manual instructions are consistent
8 Monitor performance and close the improvement cycle
Review indicators alongside user complaints and samples of decision quality. If the average improves while one group remains delayed, analyze the distribution before declaring success. Link every deviation to an owner, action, and deadline, then verify the action's effect at the next review. Reassess the design when legislation, demand volume, or the system changes. Keep a decision log so the organization knows why a step was added or removed.
- Suggested owner
- Service owner and performance analyst
- Required output
- A monitoring dashboard and improvement decision log
- Progression check
- Review decisions are based on data and user feedback
Guide and editable templates: https://uhrda.net/en/organizations/guides/service-improvement/
4. Working templates
Review the illustrative row, then complete a copy of the blank row using your organization’s information. Download each template as CSV or print it within the guide.
Procedure step review register
One hypothetical worked row and one blank row. The team requires evidence of a step's purpose before proposing its removal and assigns the decision to the person with the relevant authority.
| Step | Problem and evidence | Purpose of the step | Proposed change | Approval condition |
|---|---|---|---|---|
| Check document completeness | Repeated requests for missing information in the request sample | Prevent missing essential data | A clear checklist before submission | Service owner review and user testing |
Improvement pilot brief
Use before the pilot begins so success criteria are not selected after results appear. The team separates the improvement sought from an indicator that protects decision quality.
| Hypothesis | Scope | Improvement indicator | Safeguard indicator | Scaling decision |
|---|---|---|---|---|
| A clear checklist reduces repeated requests for missing information | One service and a specified branch | Rate of requests for missing information | Incorrect rejections in a review sample | Review improvement, quality, and workload before approval |
5. Hypothetical example: simplifying a municipal service request
A hypothetical team found that 80 of 200 requests required missing information during the baseline period. Sample review showed that instructions did not explain the alternative document for a common situation and that staff across channels gave different answers.
- The team standardized the instructions, wrote an example of the exceptional case, and reviewed it with specialists.
- It tested users' understanding, then implemented the instructions in one branch while monitoring rejections and complaints.
- It compared a subsequent batch of similar size and composition and recorded changes in staffing and demand volume.
Interpreting the result
In the hypothetical figures, 40 of the next 200 requests required missing information; the rate fell from 40% to 20%, a decrease of 20 percentage points and a relative reduction of 50%. This describes the observed change in the example and does not, by itself, prove that the instructions caused the entire difference.
Learning from the case
Explaining improvement requires comparing similar cases and monitoring decision quality and concurrent changes.
6. Measures and follow-up
Agree each definition, data source, baseline, target and accountable owner before measurement. Targets require organizational approval. A zero denominator makes a ratio not calculable rather than zero.
| Measure | Calculation | Source | Review frequency |
|---|---|---|---|
| Median service completion time | The middle value of completed transaction durations after sorting; time runs from a defined start point to delivery of the outcome, with pending cases shown separately | Transaction register and timestamps | Weekly or monthly, depending on volume |
| Rate of requests for missing information | Number of requests for which missing information was requested at least once ÷ total requests received in the specified batch × 100 | Transaction statuses and missing-information request register | For each consistently defined follow-up batch |
| Completion within the published timeframe | Number of transactions completed within the approved timeframe ÷ total transactions completed during the period × 100; show the ages of pending cases alongside it | Service register and approved deadline definition | Monthly |
| Decision soundness in the sample | Number of decisions passing quality review ÷ number of decisions reviewed × 100; document the sampling method | Independent review of a completed-case sample | With each pilot, then periodically |
7. Indicative implementation plan
The periods below are adaptable planning stages, not guaranteed delivery times.
| Period | Action | Deliverable |
|---|---|---|
| Phase one: a suggested two weeks | Define the scope, collect the baseline, and document the journey | A current-state map, causes, and improvement opportunities |
| Phase two: a suggested two to four weeks | Design and pilot the solution and review its effect | A comparison report and a decision to approve or adjust |
| Phase three: an appropriate operating cycle | Update the procedure, train, and monitor according to transaction volume | A current version and monitoring dashboard; durations are estimates |
8. Common pitfalls
Digitizing a complex procedure unchanged
Address duplication and unclear decisions before building automation.
Measuring the easy part of the journey
Define start and end points that reflect what the user needs.
Improving speed at the expense of quality
Pair time measures with a sample of decision soundness and complaints.
Removing a control step without authority
Identify the control's purpose and obtain approval for a suitable alternative.
Leaving pending transactions out of the picture
Show their number, ages, and causes alongside completion indicators.
9. Review checklist
- □ The service is defined from the user's perspective.
- □ Baseline data quality has been checked.
- □ The map includes waiting and exceptions.
- □ The competent functions have reviewed the changes.
- □ The solution has been tested with appropriate groups and channels.
- □ The version owner, follow-up plan, and rollback plan are defined.
Use this checklist at the final review. Record observations, the decision owner, approval date and document version.
10. Further reading
Original practical material prepared for the Arab Union for Human Resources Development. Sources support the concepts and further reading; the illustrative models and cases belong to this guide. Reviewed: 16 October 2026.
- GOV.UK — Understand users and their needs
A general reference for understanding users' context, researching their needs, and testing assumptions.
- GOV.UK — Measuring the success of your service
A reference for distinguishing transaction measurement from the whole journey and combining data with user research.
- GOV.UK — Define what success looks like and publish performance data
A reference for defining success and using performance indicators to improve services; it is not a local legal requirement.