1. What this stage is for
Support provides searchable, contextual help and human support at the moment of need. It begins in earnest once a change is adopted and runs for as long as the work does. Training prepares people for the common cases; Support catches everything else: the rare task done twice a year, the exception the procedure didn't anticipate, the software update that moved a button, the new starter who joined after the rollout. #22 · IDE-TEC-05
Support is also the stage most often left unfunded. Budgets cover the build and the launch; the months afterwards, when people are actually using the new way and questions are most frequent, often have no owner and no money. That's when people quietly find their own workarounds, the defined workflow drifts, and the gains measured at launch start to fade. Until the Database's stage audit in 2026, this was also the thinnest stage in its own advice: most practices were written for launch, not for the long life afterwards. #64 · #21 · #57
A useful finish line, which you never quite cross: someone stuck in the middle of a task can find a trustworthy answer in under two minutes, from inside the tools they're using, and the organization learns something from every question that couldn't be answered.
2. The moments of need
Performance-support researchers describe several distinct moments when people need help, and each calls for a different kind of support. Designing for only the first, learning something new, is why so many organizations have a training catalogue and still have people stuck. IDE-TEC-05 · #22
Moments 3 to 5 are the Support stage. They happen during the work, so the help has to live there too. The framework comes from performance-support practice and is mostly case evidence. IDE-TEC-05 · #21 · LSC-MOD-02
The distinction matters because the right format differs. A course is the wrong answer to moment 3: nobody leaves a half-finished model or an open isolation permit to take a module. A one-page aid is the wrong answer to moment 1: people learning something new need examples, practice and feedback. Most support failures are format mismatches, not content gaps. LSC-DES-04 · #22
Train complexity; deliver specificity. The reasoning behind a method belongs in training, because it builds judgment that lasts. The click-by-click steps, the form fields and the settings belong in support, because they change and nobody should memorize them. LSC-DES-04 · #21
3. Help inside the work
Put performance support inside the systems people already use: the common data environment, the maintenance system, the ERP, the CRM, the design tools. For rare or high-consequence tasks, short, findable guidance at the step is far more useful than a library people have to remember to visit. "Learning in the flow of work" is a newer name for this older idea; the principle hasn't changed. IDE-TEC-05 · #22
A few design rules make in-tool help actually used:
- One discovery point. If help lives in four places, people check none. Provide one place to start, and link from it. #30
- Retrieve by context, not just keywords. Good support knows what task, project or asset the person is working on and offers what fits, rather than returning 400 search results for "pump". KIN-FND-02 · KIN-TWN-03
- One owned, current version. Every aid has an owner and a review date, and printed or offline copies carry a version stamp. A wrong answer delivered confidently does more harm than no answer. PRM-CTX-03 · SOP-DIG-03 · SOP-DIG-01
- Short and specific. One task per aid, steps in order, the warning before the step, pictures where they help. SOP-DES-04 · SOP-DES-05
- In the working language, on the devices people use on site, with captions on any video. #24 · FAM-SYS-04 · IDE-MM-07
Govern the content as carefully as you'd govern a procedure. Curation needs an owner, pathways need quality checks, and old material needs retiring. A support library that grows without anyone removing anything becomes the problem it was meant to solve. #57 · KIN-GOV-01 · KIN-GOV-02
Capture knowledge in the flow of work, too. When an experienced technician solves an unusual fault, a two-minute recording or a short note added to the asset's record is worth more than any later documentation project. Let knowledge travel with the asset, so the next person who works on that pump finds what the last one learned. KIN-CAP-02 · KIN-TWN-03 · FAM-SYS-05
4. People who help
Documents answer the questions someone anticipated. People answer the rest. Most organizations already have an informal support network, the colleague everyone asks; Support makes that network deliberate, resourced and visible. LSC-MNT-03 · #33
Each tier should know when to pass a question up, and each question that reaches tier 3 or 4 is a hint that tier 1 is missing something. #64 · #32
Maintain a community of practice for fast-moving tools. Where software and methods change monthly, a regular forum where practitioners share what they've found keeps knowledge moving faster than any formal update. Champions anchor it locally; give them protected time, more than one per site, and evaluate whether they're helping. #33 · #8 · LSC-MNT-05
Equip managers to coach. Supervisors are the support most people actually see. A manager who asks how the new process is going, notices who is struggling and makes time for practice does more for long-term use than any help desk. Training sticks when the workplace backs it. #53 · SOP-TRN-05 · LSC-TRF-04
Mentoring is support with a longer horizon. Its effects are small but real. Informal mentoring has looked stronger than formal schemes, but people who find their own mentors differ in motivation and access, and a purely informal system leaves some people with nobody. Keep a formal route open and give it informal qualities: choice in the match, time in the mentor's workload, and feedback on real work. LSC-MNT-01 · LSC-MNT-02 · FAM-WRK-02
Protect the help desk itself. It's a common target: attackers impersonate staff to get passwords and multi-factor authentication reset. Harden identity checks for resets, and make sure every critical role has a backup so support doesn't stop when one person is away. CYBER-05 · FIN-TAL-07
5. Supporting systems and AI
Support covers the systems, not just the people. Once a new workflow depends on a platform, an analytics feed or an AI tool, someone has to own its behaviour in operation. AIG-01 · DM-AIM-03
- Name a business owner for every AI output, and name someone who can pause the AI today. Ownership that has to be worked out during an incident is ownership that arrives late. AIG-01 · AIG-14
- Ask a person before irreversible actions. AI agents should need human approval before deleting, sending, paying or publishing, and every agent needs a kill switch and logs nobody can edit. AGT-03 · AGT-05
- Expect confabulation, and design for it. Generative AI will sometimes produce confident errors. Support should make checking easy: the source beside the answer, and "no citation, no answer". NIST-AIR-03 · SOP-DIG-05
- Give prompt templates an owner, a version and tests, and keep prompts, sources and outputs as records where the work matters. PRM-BIZ-02 · PRM-GOV-03
- Keep a person on the edge cases. In vision inspection and similar tasks, automation handles the routine; people handle what the model hasn't seen. DM-AIM-03
For operational systems, alert on what users experience, not on every internal cause; an alert nobody acts on trains people to ignore alerts. Analytics only pay when someone acts on the findings. Building fault-detection software that flags a hundred faults a week and changes nothing is a support failure, not an analytics one. SWD-SLO-05 · FAM-NRG-02 · FAM-NRG-01
Plan support capacity for bad days. During incidents and long events, staff around rest and handovers rather than heroics, and set service tiers in advance so everyone knows what stops first when capacity runs short. DQ-RT-08 · HX-09 · SEM-09
6. Listen to the questions
Every support request is data. Collected and read, questions are one of the best diagnostic signals an organization has, because they show exactly where the defined workflow, the training or the tools fall short, in the words of the people doing the work. #32 · KIN-SIG-01
| Signal | What it usually means | Next step |
|---|---|---|
| The same question from many people | A gap in the aid or the training | Fix the aid; add it to the next refresher |
| Searches that return nothing useful | Content missing, or named differently from how people think | Write it; use their words |
| A workaround that keeps appearing | The workflow doesn't fit the work | Send to the procedure owner (Adapt) |
| Low use of the learning on offer | Relevance, access or time, not lack of content | Diagnose before adding more |
| Questions stop entirely | Mastery, or people have given up asking | Check which, before celebrating |
Treat friction as a sensor and measure knowledge flow, not uploads. KIN-SIG-01 · KIN-SIG-02 · #15
Diagnose low participation before adding content. When people don't use the support or learning on offer, the instinct is to produce more of it. The cause is usually elsewhere: it isn't relevant to their work, it's hard to reach from site, or nobody has time. More content solves none of those. #15 · #40 · LSC-ORG-02
Treat deviations the same way. A shortcut that people take routinely is a support signal: either the procedure is wrong, or the help that would make the right way easy is missing. Route those signals to the people who own the workflow, and close the loop so the person who raised it sees something change. SOP-USE-05 · SOP-USE-01 · SOP-GOV-06
Be careful how you collect usage data. Agree its purpose with the people it describes, keep it out of performance appraisal, and tell people what's recorded and why. Support that feels like surveillance stops being asked. IDE-DAT-05 · IDE-DAT-02 · #48
7. By team: what support looks like
The moments of need are universal; what helps at each one depends on the work. IDE-TEC-05 · #22
Technology and software teams
For digital services, support includes the people running them. Alert on what users experience, give incident communication its own owner, and close the learning loop after incidents deliberately rather than hoping someone remembers. Internal platforms should be treated as products, with paths that make the supported way the easy way and someone who listens to the teams using them. SWD-SLO-05 · SWD-INC-04 · SWD-INC-07 · SWD-PLT-01
Design, engineering and BIM teams
For design teams, the most valuable support is usually a person: the information manager who knows why a delivery failed the checks, the senior engineer who will look at a strange analysis result. Keep one authoritative container per type of information, use the common data environment's states as intended, and capture the reasoning behind decisions where the next team will find it. A model holds information; people hold the knowledge around it. BM-CDE-03 · SOP-DIG-02 · KIN-FND-01
Construction and field teams
On site, support has to work offline, on a phone, in a noisy place. Keep version-stamped aids at the point of use, use QR codes that lead to the current version, and give multi-employer sites their own coordination procedure. Supervisors are the support crews see most; give them the one-page guides and the time to use them. SOP-DIG-03 · SOP-USE-07 · SOP-USE-04
Plants and facilities
In plants and buildings, support is tied to assets. Keep one authoritative asset register, let maintenance events update the records automatically, and let knowledge travel with the asset so the next technician sees the last one's notes. Broker vendor remote access through jump hosts with strong authentication, and patch by consequence rather than by calendar. FAM-SYS-02 · FAM-SYS-05 · KIN-TWN-03 · DM-SEC-04 · DM-SEC-05
Privacy and compliance teams
Some support has deadlines in law. Requests from people to see, correct or erase their data must usually be answered within a month, and an access request means all of their data, redacted where necessary rather than refused. Know where personal data lives before the first request arrives, and keep any automated decision with a human route. GDPR-14 · GDPR-15 · GDPR-16 · GDPR-18
An illustrative example
A facilities team introduced a new maintenance system across forty buildings. Training went well; three months later, technicians were still phoning the same senior colleague about the same six tasks. Rather than rerunning the course, the team turned those six calls into six one-page aids attached to the relevant asset types in the system, and gave the senior colleague two hours a week, protected, to answer whatever was left. Calls on those tasks dropped sharply, and the question log started showing new problems instead of old ones, which is what a working support system should do. #32 · #22 · FAM-SYS-05 · KIN-CAP-02
Common mistakes
- Answering every support gap with a course. LSC-DES-04
- Help in four places, maintained in none. #30 · #57
- No owner for AI outputs, and no way to pause the tool. AIG-01 · AIG-14
- Questions answered but never read as data. #32
- Content left unchanged after a release. #21
8. Keep it current, and hand it on
Synchronize content with software releases. In fast-moving tools, a job aid can be wrong within weeks of being written. Tie content updates to the release calendar, review procedures on triggers such as incidents, changes and new regulations, with a calendar date as a backstop, and retire what's out of date rather than leaving it to be found. #21 · SOP-GOV-01 · SOP-GOV-07
Keep the information that support depends on. One authoritative asset register and space hierarchy, maintenance events that update the records automatically, and your own copy of building and system performance data protect support from vendor changes and staff turnover. Treat information continuity as a duty, even where it isn't the law. FAM-SYS-02 · FAM-SYS-05 · FAM-NRG-04 · FAM-DAT-05
Support hands Measure two things. The first is its own data: questions, searches, escalations and response times, which show where the change is working and where it isn't. The second is a set of patterns worth testing: if questions about one task dropped after a new aid went live, Measure can check whether the work improved too. Support and Measure run side by side for the life of the change. #64 · #10
For small organizations, Support can start with three things: a shared folder of one-page aids with an owner, a named go-to person for each system with time set aside, and a running list of questions reviewed once a month. That's a support system, and it beats a help portal nobody maintains. #30 · #33 · #32
The checklist. Design for moments 3 to 5: applying, failing and changing. Put help inside the tools, at the step. One discovery point, one owned version. Build a community of practice with resourced champions. Equip managers to coach. Own every AI output and keep a way to pause it. Log and read the questions; treat friction as a sensor. Diagnose low use before adding content. Sync content with releases. Then go to Measure.