Why do peer teams resist new software?
Resistance often signals a real mismatch: the product adds burden, uses the wrong language, hides purpose, threatens trust, performs poorly in the field, lacks accessibility, or was imposed without peer input.
Peer work depends on relationship, mutuality, person-centered practice, and role clarity. Adoption improves when the technology supports those values and when staff can see that feedback changes the product, configuration, training, or policy.[1][2]
Which adoption foundations matter most?
Treat adoption as an operating outcome shared by product, leadership, workflow, policy, training, support, and local conditions. A training session cannot compensate for a broken or mistrusted process.
| Criterion | How to evaluate it |
|---|---|
| Co-design | Peers, supervisors, participants when appropriate, and affected operational roles shape requirements and test decisions. |
| Purpose | Users understand what problem the workflow solves, what information is used for, and which decisions remain human. |
| Workflow fit | The product works on real devices, locations, connectivity, service types, language, accessibility needs, and exception paths. |
| Practice | Training uses role-specific fictional scenarios, spaced repetition, supported practice, and observable task completion. |
| Support | Help is timely, respectful, easy to reach, tracked to resolution, and fed into product and process improvement. |
| Trust | Access, monitoring, AI assistance, reporting, performance use, corrections, and consequences are explained honestly. |
How should adoption be measured?
Measure whether people can complete important work correctly and sustainably. Login counts can rise while staff still use shadow systems or struggle with the core task.
| Workflow moment | What good looks like | Evidence to request |
|---|---|---|
| Task success | Percent completing priority workflows accurately without rescue | Observed scenario by exact role |
| Time and effort | Completion time, interruptions, duplicate entry, corrections, and help needed | Baseline and post-change sample |
| Coverage | Expected services, notes, reviews, follow-ups, and reports completed in the approved workflow | Stable denominator and exception states |
| Experience | Confidence, usefulness, accessibility, trust, and open feedback themes | Anonymous option and qualitative review |
| Shadow systems | Spreadsheets, paper, messages, and personal notes still needed | Named reason and retirement or integration plan |
| Sustainability | Performance after turnover, new sites, changes, and reduced launch support | Repeated measurement over time |
What should leaders ask users?
Ask about the moment work becomes harder, then observe the task. Avoid treating disagreement as a motivation problem before checking product, policy, workload, device, accessibility, and trust.
- Which task takes longer or feels less accurate now, and what exactly causes the friction?
- What information are you asked to enter twice, find elsewhere, or record in language that does not fit peer work?
- What do you believe managers, funders, or the software can see or infer from your activity?
- Which device, location, connection, language, or accessibility condition makes the workflow fail?
- What single change would make the next shift easier, and how will we report back on the decision?
What should happen when adoption is low?
Diagnose the failing task with users, remove unnecessary friction, clarify policy and purpose, improve training or support, retest, and escalate product gaps instead of increasing pressure blindly.
Do not reward fast completion that creates copied, incomplete, or inaccurate records. Do not hide monitoring or performance uses. Leaders should model the workflow, protect time for learning, publish decisions about feedback, and define what will happen when technology is unavailable.
Frequently asked questions
Is a high login rate good adoption?
It is one signal, not proof. People may log in but fail core tasks, use shadow systems, or create low-quality records. Pair usage with task success, quality, experience, and workflow coverage.
Should supervisors require software use?
Organizations can establish approved workflows, but leaders should first ensure the tool is usable, accessible, supported, accurately configured, and appropriate for the role. Exceptions and downtime need clear processes.
How long should training last?
Use enough initial and follow-up practice for each role to complete real tasks and exceptions accurately. Training should continue through workflow changes, new releases, and staff onboarding.
Should participants help evaluate the technology?
Yes when the product affects their access, communication, consent, privacy, records, or experience. Participation should be meaningful, accessible, compensated when appropriate, and free from service pressure.
Sources and product pages
Government sources establish the legal and program requirements covered here. Official vendor pages document the product capabilities and positioning used in this guide.
- Core Competencies for Peer Workers in Behavioral Health Services: Substance Abuse and Mental Health Services Administration. Federal framework for recovery-oriented peer work, role clarity, and person-centered practice.
- Peerakeet Platform: Peerakeet. Peerakeet's five connected product pillars and human-guided approach.
- The HIPAA Security Rule: U.S. Department of Health and Human Services. Official federal overview of safeguards for electronic protected health information.