Administrator Response Tracking
Core Framework: Three-Tier Escalation Model
| Tier | Definition | SC Action in TDX |
|---|
| Handle |
SC resolves independently — no admin involvement needed. |
Resolve and close normally. |
| Collaborate |
SC retains ownership; admin added as participant for input. All communication via ticket — no Slack workarounds. |
Add admin as participant. Contact via ticket only. SC retains responsibility. |
| Escalate |
Full ownership transfer required. Issue is outside SC scope. Pre-escalation checklist must be completed before transfer. |
Complete checklist, transfer with tag, reason, and meta-protocol message. Log response/non-response. |
The Collaborate tier formalizes informal Slack workarounds, keeps communication on record, and gives administrators a lower-commitment way to assist without taking full ticket ownership.
Key Principles
- Say it loud, say it often. Reference the framework in all IT meetings, coffee conversations, and 1:1 check-ins with other supervisors.
- Agree to deliver a process, not a playbook. A process is: "If a ticket doesn't feel like yours, send it to Serenity." A playbook is a document that can be contested.
- Outsider perspective is an asset. "This is how every organization I've worked for handles this" is normalizing context, not criticism.
- Make admins responsible for their own purview definition. SC is not in a position to define admin responsibilities unilaterally — and should not try to.
Strategic Notes
Core Strategic Posture
- Stop trying to deliver the framework — own the process that produces it.
- If SC delivers a runbook, SC owns it — and anyone who dislikes it will claim they never agreed to it.
- If SC owns the process and requires admins to declare their purview, accountability for gaps sits with them.
- Non-engagement is not a blocker — it becomes documented evidence of who is and is not cooperating.
Senior Management Pushback
- Senior management will likely hear complaints from admins and expect SC to absorb them rather than enforce the framework. Anticipate this.
- When it happens, respond with process: "I'm routing based on what's been documented. Admins who want different handling should send me their preferred process."
- Every iteration of the framework should be traceable to admin-provided input or a documented gap — SC does not guess at admin responsibilities.
Slack Communication Policy
- SC can adopt this policy unilaterally — it does not require admin agreement.
- Frame it as: "We're routing IT queries through the support channel to improve visibility and response tracking."
- Individuals who continue using direct messages after policy communication are creating a documented pattern.
- Resistance to being on record (e.g. preference for Slack DMs) should be surfaced to Steven as context.
Slack Communication Policy
A significant volume of IT support communication currently bypasses TDX through direct Slack messages to administrators — creating information gaps and allowing individuals to operate outside any formal process without record.
Policy: Any IT query that would be sent directly to an admin must instead be posted to the designated IT Support channel. No exceptions.
- Captures informal traffic currently leaking outside the system.
- Makes non-responses observable — unanswered questions in a channel are visible to everyone.
- Creates the audit trail needed to populate the ownership matrix with real patterns.
- Removes the ability to operate by private arrangement without accountability.
ITIL Grounding
This initiative aligns with established ITIL practices. ITIL framing positions the work as industry-standard rather than internal political initiative, and makes resistance look like resistance to professional norms.
Suggested framing: "This is how every organization I have worked for handles escalation — it is standard ITIL practice. I want to make sure WestEd gets there too."
| ITIL Practice | Relevance to This Initiative |
|---|
| Escalation Management |
ITIL defines clear tiers of support (L1/L2/L3) with documented criteria for escalation between them. Undefined SC/sysadmin boundaries are a textbook Incident Management gap. |
| Incident vs. Request Fulfillment |
ITIL distinguishes incidents (something is broken) from service requests (standard tasks). Many SC-to-admin disputes involve requests that should have a documented fulfillment procedure SC can follow. |
| Knowledge Management |
Admin refusal to document handling procedures violates ITIL Knowledge Management. The meta-protocol's ask — "what process can SC follow next time?" — is direct ITIL knowledge capture. |
| Service Ownership |
Every service has an owner responsible for defining how support requests related to it are handled. Admins rejecting tickets without redirecting them are failing a core ITIL service ownership obligation. |
| SC Admin Accounts (Anti-Pattern) |
Granting SC admin-level access to compensate for admin non-responsiveness is an ITIL anti-pattern — it bypasses access control principles and signals process breakdown rather than a solution. |
ITIL Reference — Key Points
- When admins push back, ask: is this approach ITIL-compliant? Then cite the relevant practice.
- The SC admin accounts proposal is a named ITIL anti-pattern — document it as such if it comes up again.
- ITIL does not require unanimous agreement to establish process; it requires service owners to define handling procedures.