# A Service Desk for Everyday Student Requests Education | MT BYTES solution study A task-based student portal carries requests, evidence and approval history between departments, with clear ownership and a status students can follow. The student service desk organizes routine requests, appointments and document checks around the task being completed. A request carries evidence, history and approval status between departments. Existing student systems retain their authoritative records. Named ownership, understandable status and assisted routes give students a way to follow progress without navigating the institution's internal departmental structure. ## Solution design ### A request keeps its context between departments Students can find the right service, submit the information it needs and follow its progress. Departmental queues retain the decisions behind each request, while confidential support has its own restricted route and assisted service uses the same case record. - Students receive a case reference they can follow - Departments share the evidence needed for a decision - Telephone and in-person requests remain visible **Business context:** A college serving on-campus and remote students through registry, finance, academic departments and student support. **Core capability:** Software Development ![Solution study artwork](../../images/solution-studies/selected/12-hero.webp) ## Scope - Task-based student service catalogue - Accessible request forms and appointment routes - Departmental case queues and linked approvals - Student information and payment record lookups - Guidance ownership and service reporting ## A simple letter can cross several departments A student needs proof of enrolment and sends an email to the office they recognise. Registry needs the current course status, finance must clarify an account condition and the department holds a missing detail. Forwarded messages become the case record. The student repeats the request because nobody can say where it is waiting. The service desk keeps the request intact while those checks happen. Students choose the task they need to complete rather than an internal department. Behind the form, a case contains the relevant record references, outstanding questions and responsible team. A transfer changes who is working on the request without making the student start again. ## The catalogue describes a task and its decision Each service entry sets out who can request it, the information required, the deciding role and the result the student receives. That work exposes unresolved policy before it becomes a form field. If departments disagree about a condition for issuing a letter, the software cannot settle the question through a hidden routing rule. Some needs are answered by maintained guidance; others require a booking or private conversation. The catalogue reflects those differences. Search terms use the language students bring to the desk, with synonyms for departmental terminology. Information about eligibility, expected handling and alternative contact routes sits beside the action rather than in a separate policy document. ## The portal reads existing records without becoming another ledger Student identity links the request to the correct enrolment and the information the requester is allowed to see. The student information system and finance ledger retain their authority. The service layer stores the request, its attachments, assignments, approvals and correspondence, together with references to the source facts used in a decision. Linked departmental tasks carry the same case reference. Their internal notes remain separate from the student-facing status. If a source system is unavailable, the case waits for a verified lookup instead of treating missing data as a failed eligibility check. Staff can see the interruption and contact the student when it affects the expected response. ## From a prefilled form to the correct issued version The enrolment-letter form presents known details for review and asks only for information that changes the document or approval, such as its recipient. Submission creates a receipt with a case reference. The student can add a correction to that case rather than sending a new request that enters the queue as unrelated work. Registry sees the enrolment status and any required departmental task. An authorised person approves the document and delivery method once those checks are complete. Issued versions retain their date and approval record. A correction supersedes the earlier document in the student's view while preserving it in the case history for staff who need to explain the change. ## Confidential support has a narrower audience A general registry queue is the wrong place for the detail of a confidential support request. Those cases use separate permissions and restrained notification wording. A message can tell a student that their adviser has replied without exposing the subject on a shared device. Unrelated departments see only the information needed for their own task. The same service remains available by telephone and at the desk. Staff create or update the case on the student's behalf, so assistance does not produce a second, invisible process. Online journeys support saved drafts, accessible error messages and keyboard use. File-upload requirements explain acceptable formats before the student spends time preparing the wrong document. ## The service includes the queue behind the form The first release groups settled services with a clear operational owner, such as registry enquiries and official documents. It includes guidance, case queues, response wording and staff instructions. Handling checks cover missing information, reassignment, withdrawn requests and a department taking longer than expected. A case cannot disappear because its current assignee is absent. Open requests receive an explicit cutover decision. Those moving into the service desk keep a verified status and prior correspondence; those remaining in the earlier process retain a clear contact route. Students receive one place to follow each request. Staff rehearse handover and escalation before accepting new cases through the portal. ## Policy changes need a named editor Each service has a policy owner, a content editor and an operating team. A change to an eligibility rule triggers a review of the public guidance, form questions and routing logic together. Rules also specify how the change applies to cases already open, avoiding a mid-process requirement that nobody has explained to the student. Case reviews focus on repeated evidence requests, unnecessary transfers and work reopened after apparent completion. Staff can record the reason for a workaround when they need one. A spreadsheet export used every afternoon may indicate a missing workload view or a handover problem; understanding that purpose is more useful than simply prohibiting the export. ## Resolution matters more than portal traffic The service record distinguishes time actively handled from time awaiting student information or a departmental decision. Reporting follows valid completion, not merely a closed status. Reopened cases and repeat contacts help identify answers that look finished to the institution but leave the student's need unresolved. Comparisons stay within meaningful service types. A quick timetable enquiry and a complex record correction have different requirements. Managers can inspect a delayed case, see the outstanding decision and identify who can make it. Accessibility checks and student feedback add context where a submitted form alone cannot show how difficult the journey was. ## Operational flow 1. **Find the service.** Present the task, its conditions and the appropriate request or contact route. 2. **Submit once.** Review known details, add the required evidence and issue a case receipt. 3. **Complete the checks.** Route linked tasks to the departments authorised to decide them. 4. **Issue the result.** Record approval and deliver the correct document, appointment or response. 5. **Handle corrections.** Retain the case history when the student adds information or reports an error. ## Key decisions ### Tasks before departments The catalogue starts with what the student wants to do. Students should not need to know the institution's structure to reach the correct service. ### Source records stay authoritative The case stores references and decisions rather than separate student or financial ledgers. Staff need to explain a request without maintaining another competing account record. ### One record across channels Online, telephone and desk enquiries use the same case reference. Assisted access must retain the same history and follow-up as a self-service request. ## Evaluation measures These measures define the evaluation criteria for the workflow, its controls and the quality of completed tasks. ### Valid resolution by service **Measure:** Track receipt through delivery, separating handling time from documented waits. **Success criteria:** The student receives the requested service or an understandable decision with a next step. ### Transfers and repeated evidence **Measure:** Review reassignment reasons and requests for information already held. **Success criteria:** A department receives enough context to act without sending the student back through the process. ### Reopened requests **Measure:** Link corrections and follow-up contacts to the original case. **Success criteria:** Closure reflects a resolved need rather than an empty staff queue. ## In practice The service desk gives routine administration a dependable shape. A letter has an approval trail, a transfer has a receiving team and a delayed request has an explanation. Students can follow the task without learning the department structure, while staff keep the specialist decisions that make the service accurate.