Team leads and operations
Goal: Write a small handover manual that a teammate can follow without asking you to explain the same rules again.
Before you start: Complete your first workspace and select a workspace where you are an editor or owner. This exercise uses the theme Operations practice; creating another workspace is optional. You can complete all core steps without an AI connection.
The content below is an invented exercise, not real research findings, customer interviews, approved business policies, or student records. Check rights and sharing scope when you replace it with real material.
Start with the question that interrupts every shift
A new teammate asks whom to contact for unexpected product behavior. The procedure is in a chat message, the current owner is unclear, and yesterday’s exception has become an unofficial rule. You explain the same decision criteria again, but the next shift still has no reliable starting point.
This guide builds a small operational manual: a response rule, an escalation route, and a handover checklist. Keep live tickets in your usual support system; use dtxWiki to explain the standards and reasons that help people handle them consistently.
Separate the manual from the live work queue
| Material | Put it in | Record and check |
|---|---|---|
| Approved policy file or permitted procedure export | Library | Effective date, owner, source version; remove customer details |
| Standard operating procedure (SOP) | Support rules in Context | Entry conditions, ordered steps, limits, and approval owner |
| Decision criteria and escalation route | Escalation guide in Context | Situation, safe next step, responsible role, and stop conditions |
| Shift or onboarding starting point | Handover checklist in Context | Links to current rules and what a person must check elsewhere |
| Ticket state and assignment | Your normal support system | Keep its actual status there; record a permitted reference only when useful |
Choose a manageable first procedure, such as handling an unfamiliar product question. Do not try to rewrite the entire operations handbook before testing one useful page.
Page links in this example
Handover checklist links to Support rules and Escalation guide using wikilinks. The arrows show page relationships to create, not an automatic workflow or a product screen.
Create the three practice pages
- Open Context → New Context page. Use the first two copyable templates below, entering each page title in the title field and its Markdown in the body.
- For each page, choose Save draft, wait for saving, then Publish. This publishes for workspace readers; Publish to web is separate.
- Create Handover checklist last, using the third template. Its
[[Page title]]links must match existing page titles in this workspace. - Open both links. If one does not resolve, check its title and workspace and select the existing target with the editor’s Wikilink command.
Markdown is ordinary text with headings and lists; these templates are notes, not software code. See Context pages and images and links for editing controls.
Use the manual during a real working day
Start of shift: establish the current rule
Open Search, select Scope → Context, and search for Handover checklist. Read its published version, open Support rules, and confirm the owner and review date you recorded. Then check open requests and their actual assignments in the usual support system.
Before using an operational rule, ask: Does it apply to this kind of request? Is the responsible role named? Is there a condition that tells me to stop and escalate? If any answer is missing, contact the responsible person through your normal channel rather than guessing from the checklist.
During a request: follow the decision criteria
Open Escalation guide and use the appropriate row. For example, the practice rule for possible data loss is to stop changes and contact the operator; it is not permission to attempt a repair. Add the following detail table to your own manual once the responsible team verifies it:
| Situation | What to establish | Who decides the next action |
|---|---|---|
| Routine how-to question | The approved guide applies to the current product version | Support person within the defined rule |
| Unknown product behavior | Reproduction steps without private customer data | Assigned product owner |
| Possible data loss | Stop condition and known safe state | Responsible operator |
Use role names first, then add your team’s current contact route as ordinary text or a permitted link. dtxWiki does not contact the named person when someone reads the row or checks a box.
End of shift: leave actionable background
Record outstanding questions in the appropriate permitted note, and leave live request status in the support system. In Handover checklist, explain where the next teammate should look and which owner is responsible. Save draft while checking the text; Publish the version ready for workspace readers.
Onboarding: test the manual with a person
An Owner can add a new teammate as a Viewer for reading or an Editor for maintenance. Give them the workspace link to Handover checklist. Ask them to walk through a fictional unfamiliar issue and explain the stop condition in their own words. If they need an unwritten rule, add it to the relevant page and repeat the exercise.
Copy the page content
Create the pages in this order. Put each heading’s page title in the title field and paste the block below it into the body.
Support rules
# Support rules
## First reply
Acknowledge the request and record the issue.
## Before promising a date
Confirm ownership and current capacity.
## Do not include
Passwords, access keys, or customer personal information.
Escalation guide
# Escalation guide
| Situation | Next step |
| --- | --- |
| General question | Check the approved guide |
| Unknown product behavior | Ask the assigned product owner |
| Possible data loss | Stop changes and contact the operator |
## After resolving
Record what was learned without exposing private data.
Handover checklist
# Handover checklist
## Start of shift
- [ ] Read [[Support rules]]
- [ ] Check open requests in the normal support system
- [ ] Confirm who owns each unresolved request
## When uncertain
Use [[Escalation guide]].
## End of shift
- [ ] Record outstanding questions
- [ ] Leave an explanation for the next teammate
## Last reviewed
Practice example; replace with your review date.
Correct the rule and keep its owner visible
At a weekly check, the procedure owner searches for the three pages and checks links, responsible roles, review dates, and applicability. These dates and owners are fields you write in the content; this guide does not configure reminders or automatic escalation.
For a corrected policy, use Upload new version on the Library item. Compare the affected section, then edit Support rules and any dependent instructions. Add a short reason, such as “the approval role changed,” and update the effective or review date. Uploading the corrected source does not rewrite the Context manual.
Have an authorized colleague check a material change before use. Browser Save draft remains private editing; it does not itself create a review request. When an explicit proposal is in Review queue, an authorized Editor or Owner can inspect View changes, Request changes with a reason, or approve an eligible Context publication. Human Editors may also publish directly under your team’s agreed process.
After publication, open History and check Readers see v…. Verify the handover links still open the intended pages. Readers receive the published version while a separate private edit remains unfinished; a link alone does not grant workspace access.
Check the result
A teammate can find the response rule, the handover checklist, and the escalation path from one place. Private draft edits remain separate from the version readers receive.
Use Search to find Handover checklist again. Check the published content and open both links; a successful draft save alone does not confirm that readers have the new version.
Have a new teammate demonstrate the outcome with a fictional request:
- They find Handover checklist, open both rule pages, and state which rule applies.
- They know who can decide an unknown product issue and when to stop changing a system.
- They can locate the latest published instruction and explain the most recent correction from its recorded reason.
If they rely on an oral explanation for a safety-critical step, the manual needs another correction before you call the exercise complete.
Common mistakes to avoid
| Mistake | Better approach |
|---|---|
| Writing “ask someone” | Name the responsible role and a verified contact route |
| Recording every customer request in the shared manual | Keep private ticket details in the support system; document reusable lessons safely |
| Changing the policy source but leaving old instructions | Review each dependent Context page and publish its corrected version |
| Checking a box and assuming a task was executed | Check the real support or operating system for the action and result |
For repeated questions, improve the relevant rule after the case is resolved. Keep exceptions labeled with their conditions so one unusual incident does not silently become the default procedure.
Related guides: Library, review and history, and sharing.
Optional: ask a connected AI tool
Complete MCP connections and grant only the required workspace and reading access. Credential grants and workspace permissions enforce access. Material returned to an external AI app may be processed by its provider; use approved, non-sensitive practice data.
Read Handover checklist, Support rules, and Escalation guide in my selected workspace. Walk through three fictional cases: a routine question, unknown product behavior, and possible data loss. For each, identify the applicable rule, next step, responsible role, stop condition, and page evidence. Mark missing contact routes or conflicting instructions as unknown. Suggest clearer wording in this chat only. Do not send messages, create tickets, edit dtxWiki, or change infrastructure.
Have the procedure owner check every suggested next step against the approved policy and current responsibilities. Test the revised wording with a new teammate before publishing it. An AI suggestion does not authorize a repair, establish a service commitment, or prove a checklist action happened.
Chats lets you inspect recorded dtxWiki tool activity. It is not a complete transcript of the AI conversation or a record of every action in the external service.
Version evidence: Library controls, page editing and publication, review decisions.