PRACTICAL WORK / TOLUWA STEPHEN ADEBAYO
Support SOP & knowledge-base article
A process excerpt paired with a user-facing guide and measurable acceptance criteria.
Demonstration sample • Synthetic scenario • Prepared with AI assistance for this portfolio; not a client deliverable or a record of a completed incident.
01 / WORK SAMPLE
SOP: receive, prioritise and own a request
Document DEMO-SOP-001 · Version 1.0 · Demonstration only. Proposed owner: Service Desk Lead. Scope: internal IT incidents and service requests. All response targets must be agreed by the organisation.
Priority guide
| Priority | Business impact | Operating response |
|---|---|---|
| Critical | Widespread critical service outage or serious active security concern | Immediate triage and escalation under agreed policy |
| High | Time-sensitive work blocked; limited workaround | Assign owner and communicate next update |
| Normal | Individual issue with viable workaround | Queue by impact, urgency and service commitment |
| Planned | Non-urgent fulfilment or scheduled change | Agree date, approvals and dependencies |
Procedure
- Capture requestor, affected service, symptoms, start time, business impact, deadline and safe contact method.
- Check for related incidents and known issues. Assign priority using impact and urgency, not the sender’s seniority alone.
- Acknowledge ownership and agree the next update. Collect only the information required for diagnosis.
- Troubleshoot within authority. Record each meaningful test, result and change. Escalate when impact, permissions or complexity require another owner.
- Validate the original task with the user; document the cause if known, action, outcome and follow-up before closure.
Required record
Ticket ID; owner; category/priority; affected service; user impact; diagnostic evidence; actions and timestamps; communication history; escalation; validation; closure reason.
Quality check
Another technician should be able to continue from the record without asking the user to repeat the entire problem. A ticket marked resolved must contain verification, not just “done”.
02 / WORK SAMPLE
Knowledge base: a shared file says “Access denied”
Audience: employees. Purpose: help a user gather useful information and try safe checks before support takes over. This is a demonstration article, not a tenant-specific instruction.
Before you begin
Use your approved work account and the original link from the file owner. Do not request that confidential information be made publicly accessible.
Safe steps
- Check the account shown in your browser or application. If it is a personal or different work account, use the intended work identity.
- Open the same link in the browser. Note whether the problem occurs in the browser, desktop application or both.
- Confirm with the file owner that you have the access required for the task. Editing may require different access from viewing.
- If access was recently changed, report that detail to support. Avoid repeatedly creating copies or new links.
- If the problem continues, send the exact error, time, affected application and business impact through the approved support channel. Share sensitive links only with authorised support staff.
What to send support
“I cannot [open/edit] the shared file in [application]. The error is [exact wording]. It started at [time/timezone]. Browser access [works/does not work]. I need this for [task/deadline].” These bracketed fields are intentional input prompts within the sample.
Escalate immediately when
Unexpected people can see confidential material, a suspicious sign-in is involved, or a wider team loses access. Use the organisation’s security reporting route when appropriate.
Article acceptance criteria
A non-technical reader can complete the checks without changing permissions or disclosing credentials. The guide names the next support step and provides enough context to investigate.