Owner runbook
The project owner is responsible for knowing whether the Knowspread space is ready to launch and whether the running setup still matches the client’s process. This page is intentionally practical: it lists what to decide, check, and escalate.
Launch checklist
Section titled “Launch checklist”| Area | Owner check | Evidence |
|---|---|---|
| Space ownership | There is at least one active owner and a deputy. | Owner and admin list is reviewed. |
| User source | The authoritative source for users is known. | Manual process, import file, or API integration is documented. |
| Identifiers | The stable user identifier is selected. | personal_id, e-mail, or external ID is agreed. |
| Groups | Groups have one clear meaning. | Group list maps to departments, courses, projects, or access rules. |
| Content | Launch content is approved and versioned. | Content owner confirms the active version. |
| Assignments | Required assignments have owners and deadlines. | Assignment matrix is reviewed before launch. |
| Reporting | Completion report answers the launch success question. | Test export or dashboard screenshot is available. |
| Support | Escalation route is known. | Owner knows who handles data, content, and technical issues. |
First-week checks
Section titled “First-week checks”During the first operational week, check these signals daily:
- newly invited users are becoming active,
- group membership matches the expected rollout population,
- assigned learning appears for a sample of users,
- completion counts move in the expected direction,
- no unexpected license shortage blocks assigned users,
- webhook or export consumers receive completion data if integration is enabled.
Routine governance
Section titled “Routine governance”| Rhythm | What to check | Why |
|---|---|---|
| Weekly | New users, revoked users, overdue learning, failed imports. | Prevents silent data drift. |
| Monthly | Content versions, group structure, license usage, reporting exports. | Keeps the space aligned with the process. |
| Before major rollout | QA scenarios, screenshot map, owner checklist, integration dry run. | Reduces operational surprises. |
| After product change | Re-run affected QA scenarios and update screenshots. | Keeps documentation and client communication current. |
Escalation inputs
Section titled “Escalation inputs”When asking the internal team to investigate an issue, include:
- company space name or ID,
- affected user identifier,
- affected group, content, or assignment,
- expected behavior and actual behavior,
- approximate time of the action,
- screenshot or export row if the issue is visible in UI or reporting,
- whether an API call, import, or manual UI action caused the change.
Owner risks
Section titled “Owner risks”| Risk | Symptom | Prevention |
|---|---|---|
| No deputy owner | One person becomes a launch bottleneck. | Keep at least two active owners or senior admins. |
| Mixed group meaning | Reports and assignments are hard to explain. | Use separate groups for departments, courses, and permissions. |
| Unstable identifier | Users duplicate or history becomes hard to reconcile. | Prefer a stable HR identifier when available. |
| Hidden content version change | Learners see different versions than expected. | Record active versions before and after release. |
| Integration without rollback | External system sends wrong group data repeatedly. | Agree how to stop, replay, and correct synchronization. |