Hypothetical: A new application is live. The team needs to make it part of the work.

Go-live has left two ways of working

In this example, a business introduces an application for assigning and tracking service work. Team members enter basic details into it, then manage the rest in spreadsheets. Supervisors ask for emailed updates before meetings because they do not trust the application’s current position.

Another introductory demonstration would cover screens the team already recognises. The unresolved questions are more specific: what happens when an assignment is returned, a deadline changes or somebody updates the wrong record?

Observe the tasks that break down

The engagement would examine a small selection of everyday tasks with the people doing them. Each difficulty would be classified before choosing a response.

Training would address the gaps that practice and instruction can resolve. Configuration defects and unsuitable requirements would be passed to the appropriate owner instead of being treated as user resistance.

Build practice around each role

The proposed learning sessions would use sample records and complete tasks. A coordinator would create and reassign work. A team member would update progress and return an incomplete assignment. A supervisor would review exceptions and interpret the queue.

Each role would receive a short task guide covering the decisions people actually need to make. The guides would use the same terminology as the application and show where to ask for help.

Retire parallel records deliberately

The business would agree which record is authoritative, how existing discrepancies will be resolved and when the old trackers stop accepting new work. Some spreadsheets might remain useful for a separate purpose; that purpose would be explicit.

An early review would examine a sample of completed tasks, unanswered questions and recurring workarounds. It would distinguish a need for further practice from a change the application itself requires. Login counts alone would not establish that the work is being carried out correctly.

Questions that used to circulate in private messages need a route that stays after the engagement. Our briefing on who owns support after an application goes live sets out how to assign it.

What the engagement would leave behind

Proposed outputs would include a task-based adoption plan, role-specific guides, facilitated practice, a register of application issues and a named owner for future instructions. Review measures would be agreed around the work, such as completeness of required records and successful handling of exceptions.

Capabilities involved

Corporate Training would lead the learning work. Technology & Automation would address configuration and technical issues. Business Consultancy would help resolve conflicts between the application and the operating routine. Workforce support could help clarify duties where those have changed.

Is the old tracker still running alongside the new application?

Bring an example of the work people are recording twice. In a first discussion we can work out what needs to change: the application, the instructions or the daily routine.

Book a discussion →

Related capability:Corporate Training →