Playbook, university

A technical fault with a deadline attached to it

Most technical questions on a university site are ordinary: the network will not join, a reading sits behind a login, a recording has not appeared. One category is not ordinary. A student who cannot submit an assessment an hour before the cut off is somewhere a slow or wrong reply has an academic consequence, and the job there is to name the evidence to keep and the people to tell, not to troubleshoot.

Why this is not the general answer

The handling pattern for technical troubleshooting holds across every trade. What follows is the part that does not.

  • Off campus access to subscribed readings fails through the library authentication route rather than through anything on the student's own machine, which is why students conclude they have to buy an article the university already pays for.
  • The campus wireless network is joined with the student account rather than a shared key, so most connection failures are really account failures and belong with the account material instead of with a networking guide.
  • A submission failure is an academic event as well as a technical one: the error text, the time and a screenshot are evidence for the extenuating circumstances route, and telling a student to capture them is worth more than any fix the assistant could suggest.
  • Recordings and reading lists are published by teaching staff rather than by a central service, so a missing item is usually a person who has not uploaded it, and sending that to a service desk sends it to somebody with no ability to act.

How it arrives

  • i cannot upload my assignment and it is due tonight
  • the reading list link is asking me to pay
  • how do i connect to the wifi on campus
  • the lecture recording has not appeared
  • i cannot open the journal article from home
  • my printing credit is not working

What has to be indexed for this to work

Material behind this answer
Submission guidance, including what to do when it failsFile types and size limits, what the cut off actually does, and the instruction to capture the error with the time visible before retrying. That last line protects the student and almost no submission page carries it.
The library off campus access routeHow to reach subscribed material from outside, named the way the library names it. Without it, students conclude every article is paywalled and quietly give up on the reading.
Network access instructions tied to the accountThat the wireless network uses the student account, and what to do when it will not accept it. Kept beside the account material rather than filed under networking, because that is what it actually is.
Who to contact for teaching material rather than systemsThe department for a missing recording or reading, the service desk for a system fault. Two destinations, and unless the page names both, everything lands on the desk.

The reply

A reply worth copying
If a submission is not going through and the deadline is close, capture a screenshot showing the error and the time before you do anything else, because that is what the extenuating circumstances route asks for [1]. The submission guidance has the file limits and what the cut off does [2]. Then contact the service desk, and tell your module leader in the same hour. I cannot see the system, cannot tell whether anything is down and cannot extend a deadline. If you want your details passed on, I can do that too.

It leads with the instruction that protects the student, ahead of any troubleshooting, because the evidence vanishes as soon as the page reloads. It names two contacts, since a submission problem is technical and academic at once. And it is explicit that it cannot tell whether anything is down, which is what people assume a chat window can do.

Where it stops

The trigger. The visitor is up against an assessment deadline, says a system is down, or describes a fault the published guidance does not cover.

The handover, worded
I cannot check a system or extend a deadline. Keep the screenshot with the time on it, contact the service desk, and if you leave me your name, an email and your module, I will pass this on so somebody in the department knows it happened tonight.

It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.

Never say this here

Out of bounds

  • Never say a system is down, is back up or is being worked on, because nothing here has any view of any service.
  • Never tell a student a deadline will be extended or a late submission excused, since that is a decision for the department.
  • Never walk a student through changing a setting on a university managed device or account.
  • Never say a reading has to be paid for, as the library route usually reaches it and the student is one login away from it.

Questions

Can it see whether the learning environment is down?
No. It has no monitoring, no status feed and no connection to any service. If you publish a status page it can point at it, and that is the honest limit of what it does here.
Is a chat window the right place for a submission failure at midnight?
It is the place the student will use, which settles the question. What it must do is spend thirty seconds saying keep the evidence and here are the two people to tell, rather than offering steps that burn the time left.
How do we stop everything landing on the service desk?
Publish the split. A missing recording is a person who has not uploaded it and a login loop is a system, and a student cannot tell those apart. If the page names both destinations, the reply will name them too.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.