Internal support intake workflow transition
Assessment: CIA-EXAMPLE-001 revision 1.0.0. Status: reviewed_for_coordination.
Fictional teaching record. Reviewed for coordination does not mean approved, ready, compliant, safe, complete, or successful. Degree and direction are written in every row and are not communicated by color alone.
Change boundary
Current state: Internal requesters email a shared inbox; triage staff manually re-key category, urgency, owner, and status into a private tracker.
Intended future state: Internal requesters submit a bounded form; a routed queue preserves the request record, human triage decision, owner, status, and service handoff.
Impact register
| Impact ID | Affected group | Dimension | Current state | Future state | Impact | Direction | Degree | Confidence | Validation | Evidence | Handoffs |
|---|---|---|---|---|---|---|---|---|---|---|---|
| IMP-001 | Internal requesters | Process and workflow | A requester writes an unstructured email and waits for a manual acknowledgement. | A requester submits bounded fields and receives a recorded acknowledgement state. | Requesters must choose a category and provide the minimum routing information before submission. | mixed | medium | stakeholder_validated | stakeholder_reviewed | EVD-001, EVD-002 | HND-001 |
| IMP-002 | Internal requesters | Systems and tools | Requesters use email and cannot inspect a durable request status. | Requesters use a bounded form and can inspect the request acknowledgement and current status allowed to their role. | The submission and status path moves from email to a role-bounded workflow. | mixed | medium | observed | owner_reviewed | EVD-001, EVD-003 | HND-001, HND-003 |
| IMP-003 | Internal requesters | Customer or service experience | Acknowledgement and ownership are visible only when a triage operator replies. | The request record exposes a bounded acknowledgement and owner state after human triage. | Requesters gain a consistent status reference without receiving a promise of resolution time. | supportive | low | hypothesis | owner_reviewed | EVD-007 | None |
| IMP-004 | Triage operators | Process and workflow | Triage operators read email, re-key request details, and reply from the shared inbox. | Triage operators review structured records, correct exceptions, decide routing, and record the decision once. | Triage work shifts from repeated transcription to exception review and accountable routing. | mixed | high | stakeholder_validated | stakeholder_reviewed | EVD-002, EVD-003 | HND-001, HND-002, HND-003 |
| IMP-005 | Triage operators | Roles and responsibilities | The inbox responder informally chooses category, urgency, owner, and follow-up. | A named triage role records category, urgency, owner, exception reason, and escalation state under one revisioned rule set. | Triage decision authority and escalation responsibility become explicit and reviewable. | mixed | high | observed | stakeholder_reviewed | EVD-003, EVD-006 | HND-001, HND-002 |
| IMP-006 | Triage operators | Workload and capacity | Interruptions and re-keying effort vary with email quality and are not measured consistently. | Structured fields may reduce re-keying while exception review and queue monitoring add different effort. | Net triage capacity impact is unknown until a bounded production-shaped rehearsal is observed. | unknown | unknown | unsupported | unvalidated | EVD-002, EVD-003 | HND-004, HND-007 |
| IMP-007 | Specialist service teams | Process and workflow | Specialist teams receive forwarded email threads with inconsistent context. | Specialist teams receive a routed record with bounded context, triage decision, and an explicit return path. | Specialists must work from the routed record and return exceptions through the defined service handoff. | mixed | medium | observed | owner_reviewed | EVD-004 | HND-001 |
| IMP-008 | Specialist service teams | Systems and tools | Specialists use forwarded email and local team records. | Specialists use a role-bounded queue reference while keeping team-specific service records in their accountable system. | The receiving team must reconcile the shared request reference with its own controlled service record. | disruptive | medium | hypothesis | owner_reviewed | EVD-004, EVD-005 | HND-003 |
| IMP-009 | Specialist service teams | Data and information | Email threads can contain inconsistent details and attachments outside a bounded field model. | The intake record stores minimum routing metadata and references specialist-controlled records instead of copying private evidence. | Data collection, references, access, retention, export, and deletion ownership need explicit qualified review. | disruptive | high | observed | owner_reviewed | EVD-005 | HND-002, HND-003, HND-005, HND-006 |
| IMP-010 | Support service leadership | Policies and controls | Required intake fields and escalation exceptions are applied through informal inbox practice. | A revisioned rule set records required fields, exception reasons, escalation ownership, and review status. | The service owner must approve the operating rule set in its accountable record, outside this assessment. | mixed | medium | observed | owner_reviewed | EVD-006 | HND-002, HND-006 |
| IMP-011 | Support service leadership | Customer or service experience | Service review depends on manually assembled inbox and tracker summaries. | Service review uses a bounded status view and separately owned service evidence. | Leadership can review queue shape and exceptions without treating a dashboard as proof of service quality. | supportive | medium | hypothesis | owner_reviewed | EVD-007 | None |
| IMP-012 | Support service leadership | Location and work pattern | Reviewers coordinate by inbox flags and a weekly manually prepared summary. | Rotating reviewers use one bounded queue review and record unresolved exceptions for the next shift. | Cross-shift coordination moves from inbox conventions to an explicit unresolved-exception handoff. | neutral | low | observed | owner_reviewed | EVD-003, EVD-006 | None |
Authority boundaries
changeApproved: falseinvestmentAuthorized: falseimplementationReady: falseadoptionProven: falseriskAccepted: falserequirementsCoverageProven: falsetechnicalImpactComplete: falseprivacyComplianceEstablished: falsesecurityApproved: falseaccessibilityConformanceEstablished: falseoutcomeGuaranteed: false