# 6. Account Requests User Type: **Super Administrator** Source: *Mi Digital Academy - Education CRM Features Document* --- ## 6. Account Requests ### 6.1 Process Account-Related Requests **What it does:** Provides a queue and workflow for account-related requests submitted by users or staff — registration help, profile changes, verification issues, suspension appeals, and deletion/closure requests. Each request is tracked from submission to resolution with an owner, a target timeframe, and a recorded outcome, so no account request is lost or forgotten. **Sub-features:** - Request queue: all open requests with type, requester, priority, and age - Request types: registration help, profile change, verification issue, suspension appeal, deletion/closure, access issue - Request detail: the request, the account, the context, and the history - Ownership and assignment: each request has an owner (Super Admin or delegated) - Target timeframe per type with overdue highlighting - Resolution with a recorded outcome and user notification - Audit logging of request lifecycle events **Super Administrator User Journey:** 1. Super Admin opens the Account Requests queue: 12 open requests — 3 registration help, 2 profile changes, 2 verification issues, 1 suspension appeal, 1 deletion request, 3 access issues. 2. Reviews the oldest first (a registration help from 4 days ago, past its target). Opens it: a parent could not complete a child's registration (the guardian verification step failed). 3. Resolves it: re-sends the guardian verification, walks the parent through it (via support), and confirms the child's account is complete. Marks the request resolved with the outcome and notifies the parent. 4. Assigns the 3 access issues to the support sub-admin (delegated) and keeps the suspension appeal and deletion request for direct handling. 5. Reviews the suspension appeal (see 3.4): resolves it and links the re-activation. 6. Reviews the deletion request: confirms the account's eligibility (deactivated, retention elapsed, no holds) and routes it to the deletion flow (see 3.3). 7. Checks the overdue view: no requests are now past their target; the queue is clear. 8. Every request's lifecycle — submission, assignment, resolution, notification — is audit-logged. **Rules & Edge Cases:** - Every request has an owner and a target timeframe; overdue requests are highlighted, not buried. - Resolution requires a recorded outcome; a request is not closed without it. - The user is notified of the resolution (and of key interim updates per policy). - Deletion and suspension-appeal requests route to their owning flows (3.3, 3.4) with the request as the trigger. - Delegation is possible (to sub-admins with the permission); the original requester is unaffected. - The full request lifecycle is audit-logged with the account, owner, and timestamps. ### 6.2 Handle Course Access Issues **What it does:** Diagnoses and resolves issues where a user cannot access a course they should be able to reach — enrollment not reflected, a seat or membership lapse, a permission gap, or a content-availability problem. It connects the account, enrollment, membership, and permission views to find the root cause and apply the correct fix. **Sub-features:** - Access-issue intake: the user, the course, and the symptom (cannot open, cannot see, partial access) - Diagnosis checks: enrollment state, membership/seat validity, role/permission, content availability, account status - Root-cause identification with the specific failing check - Fix application: correct the enrollment, restore the membership/seat, adjust the permission, or escalate the content issue - Verification: confirm the user can now access the course - User notification with the resolution - Audit logging of the diagnosis and fix **Super Administrator User Journey:** 1. A student reports: "I can't open my course." Super Admin opens the access-issue request and runs the diagnosis checks for the student and the course. 2. The checks show: enrollment (present), membership (active), account status (active), permissions (correct for a student) — but content availability: the course's first module is still in "draft" (not published). 3. Identifies the root cause: the course content was not fully published. Escalates to the content owner (via Content Management) to publish the module, or publishes it if within the Super Admin's authority. 4. For a different case — a student who can see the course but not its assessments — the diagnosis shows the assessment is restricted to a sub-group the student is not in. Super Admin corrects the student's group assignment. 5. For a membership-lapse case — a student's access dropped when the subscription paused — Super Admin confirms the billing state, resolves the payment issue (routed to Payment & Billing), and the access restores on renewal. 6. Verifies each fix: the student can now open the course and its components. 7. Notifies the user with the resolution and the cause (in plain terms). 8. The diagnosis, root cause, and fix are audit-logged against the request and the account. **Rules & Edge Cases:** - Diagnosis is structured (enrollment, membership, permission, content, status) so the root cause is identified, not guessed. - The fix matches the root cause: an enrollment fix for an enrollment problem, not a permission change that masks it. - Fixes that belong to other modules (billing, content publishing) are routed to those modules, not forced here. - Verification is part of the resolution: the user's access is confirmed, not assumed. - The user is notified with the resolution and the cause. - The full diagnosis and fix are audit-logged for the request and the account. ### 6.3 Request Tracking and SLA Monitoring **What it does:** Tracks all account requests against their target timeframes (SLAs) and provides monitoring views so the Super Administrator can see queue health, spot overdue items, measure resolution times, and keep the request process accountable. It turns the request queue into a managed, measurable service. **Sub-features:** - SLA targets per request type with per-request countdown - Overdue and at-risk views (approaching the target) - Queue health: open count by type, average resolution time, overdue count - Resolution-time metrics by type and by owner - Escalation for overdue requests (notify the owner, then the Super Admin) - Reporting export for service reviews - Audit logging of SLA events (breach, escalation) **Super Administrator User Journey:** 1. Super Admin opens the Request SLA view: 12 open requests, 1 overdue (the 4-day registration help), 2 at-risk (within 20% of their target). 2. The overdue request has already triggered an escalation notification; Super Admin resolves it (as in 6.1) and records the breach. 3. Resolves the 2 at-risk requests before they breach. 4. Reviews the queue health: average resolution time by type (registration help 1.2 days, access issues 0.8 days, appeals 2.1 days) and by owner. 5. Notices appeals average 2.1 days against a 2-day target — a slight trend. Reviews the appeal workload and assigns an additional reviewer to keep the SLA. 6. Exports the monthly SLA report for the service review: volumes, resolution times, breaches, and escalations by type. 7. Reviews the breach log: each breach shows the request, the target, the actual, and the escalation path. 8. The SLA events (breaches, escalations) are audit-logged, and the metrics feed the Super Admin Dashboard's support-health indicators. **Rules & Edge Cases:** - Every request type has an SLA target; the per-request countdown makes the deadline visible. - Overdue requests escalate automatically (owner, then Super Admin); they are not left to be noticed. - Metrics are by type and by owner, so trends and workload imbalances are visible. - SLA breaches are recorded and reviewable; they are not hidden by resolution. - The SLA report is exportable for service reviews and compliance. - SLA events are audit-logged with the request, target, actual, and escalation path.