In this article
A support request is not improved simply by sending it to more people. Each added recipient may have a different role, and a broad message can spread private information without making the problem clearer. The aim is to find the smallest appropriate route for the question you actually have.
Start by distinguishing three kinds of request. A service failure concerns something that does not function as expected. A content question concerns what an instruction means or whether material should be available. A record or policy question concerns an official decision. These are practical categories, not rules determining which university office must handle your case.
Identify the authority you need
Ask what a successful reply would do. Would it explain an error, clarify an assignment, confirm a record or grant an exception? A technology desk may investigate a failed action but cannot be presumed to change a course requirement. An instructor may explain a deadline but cannot be presumed to repair a campus authentication service.
The Campus IT support page distinguishes academic-role support from health-care IT support. The Canvas help page also distinguishes Canvas assistance from video-services coverage. This is a reminder to read service scope, not just the word “help.” Use the live official pages for current channels and hours rather than relying on a copied contact list.
Do not decide urgency only by how anxious you feel. Explain the impact accurately: what work is blocked, how many people you know are affected and what relevant deadline exists. Avoid claiming a campus-wide outage from one failed browser session. A precise description helps support staff evaluate the issue without being pushed toward an unsupported diagnosis.
Give one route a useful starting point
A first message should identify the service and expected result, state what happened instead and explain what you have already checked. Include the time and time zone if relevant. Keep the note short enough that the recipient can see the question without searching through a long narrative.
If you do not know the right destination, say that explicitly and ask for routing. “Can your team investigate this behavior, or should I contact another service?” is more useful than asserting that a particular department caused it. Do not attach personal records simply to make the request feel complete.
When an official support channel requires authentication or a particular identifier, use that channel’s instructions. This site is not a submission gateway. Do not paste a support ticket into our search field or send us the attachments you prepared for the university.
Fictional case: the video works nowhere
In an invented example, Riley can open a course but cannot play one assigned video. Riley begins by drafting “Canvas is down.” That wording obscures the key distinction: the course itself loads, while a particular media item fails. Riley revises the description to name the action and visible result.
The next step is to inspect the official support scopes. Because video coverage is not identical across every Canvas support route, Riley should not assume that the first service labeled Canvas can resolve the media issue. The live university help page identifies the relevant distinction. Riley can also ask the instructor whether the same material has an approved alternative.
Neither request promises an extension or a workaround. The instructor decides course arrangements, and support investigates the technical behavior. Keeping those requests separate lets Riley pursue both legitimate questions without asking either recipient to exercise authority they may not have.
Handle a referral without starting over
If a team refers you elsewhere, preserve the useful facts and the referral reason. Do not simply forward an entire conversation containing identifiers or unrelated details. A concise summary can state that the first team identified a different service scope and provide the existing case reference through an appropriate channel.
Check whether the first ticket remains open and whether the new team can see it. Do not assume systems share every conversation. At the same time, avoid creating multiple competing cases for the same issue unless instructed. Duplicate cases can fragment the evidence and make it harder to know which response is current.
If the referral seems wrong, explain the specific mismatch politely. For example, clarify that the issue is playback rather than account access. Correcting the description is often more productive than arguing about which department should own a vaguely defined problem.
Close the loop on the actual question
A reply containing general instructions is not necessarily a resolution. Try only the steps you understand and are authorized to take. Record whether the expected action now succeeds. If the behavior changes, describe the new observation rather than reporting that “nothing works” when something did change.
If a step would delete unsaved work, alter security settings or expose private information, ask for clarification before proceeding. You do not need to weaken protection to prove cooperation. Explain the constraint and request an appropriate alternative.
At the end, separate the technical outcome from any academic consequence. A working service does not automatically settle a missed deadline, and an instructor’s accommodation does not prove the service is repaired. A good support history closes each question with the person authorized to answer it.
Prepare for an unanswered request
A useful follow-up does not merely repeat “any update?” It states whether the impact or deadline has changed and asks what information is still needed. Refer to the existing case through the appropriate channel so the next person can connect the history. Avoid sending the same private attachments again unless requested.
If you need to contact another office about an academic consequence, explain that a technical investigation is ongoing without claiming that it guarantees a particular decision. The office can tell you what documentation it requires. Do not promise that support will confirm a cause or recovery time that has not been established.
When a response arrives, read the whole instruction before acting. Some steps are conditional or meant for a particular device type. If your situation differs, say so. A well-routed request still needs careful interpretation; the goal is an appropriate action, not automatic compliance with a step that may not apply.
Sources and scope
Public pages reviewed November 9, 2026. The analysis and fictional cases are this publication’s own. No authenticated university account was inspected. Screen labels, service coverage and availability can change.
- Campus IT support: Academic-role help desk, service status and support channels.
- University Canvas help: Canvas entry routes and separation of Canvas and video support.