CLIP LearnDocs 1.0
For trainers

Support & requests

One place to ask the platform team for help, report a bug, or request a feature — with a reference you can quote, a visible status, and a published response time.

Support & requests is the CLIP team's single channel to the platform team. Anything you'd otherwise send by WhatsApp or a direct email — something broken, something confusing, or something CLIP should be able to do but can't yet — goes here instead.

The point isn't formality. It's that a request raised here gets a reference, a published response time, and a status you can see without having to ask whether anyone read it.

Open it from the tools menu — the grid icon beside your name, on any page — or go straight to /support. It's available to the Faculty and Admin roles. Learners don't see it; they have their own routes for questions and enquiries.

Moe’s voice · genuine CLIP Learn screensOpen full screen ↗

Raising a request

Choose what kind of thing it is — this is what routes it sensibly.
Write a short summary: one line someone can scan in a queue.
Add the detail — what you expected, what actually happened, and which learner or course it affects.
Set how urgent it is, then press Send request.

Picking the right type

TypeUse it when
SupportSomething is confusing, or you're not sure how to do it. There are no silly questions — if it wasn't obvious to you, that's worth knowing.
BugSomething is broken, wrong, or behaving unexpectedly.
Feature requestSomething the platform should do but doesn't yet.
Access / accountLogins, permissions, or a learner who can't get in.

For feature requests, describe the goal — not the button

Tell us what you're trying to achieve rather than how you think it should be built. "I need to mark on the train without signal" tells us far more than "add a download button" — and often has a better answer.

When you'll hear back

Every request carries a published target for a first reply from a person. That's a reply, not necessarily a fix — but it's a real human response, not an auto-acknowledgement.

UrgencyFirst replyUse it when
Urgentwithin 1 hourLearners are affected right now.
Highwithin 6–12 hoursIt's blocking your work.
Normalwithin 24–48 hoursThe default.
Lowwithin 5 working daysWhenever you get to it.

The clock starts when you press send and stops at the first staff reply. You can see where any request stands on your own list, and the platform team is alerted automatically the moment one goes past its target — so a missed deadline surfaces itself rather than going quiet.

Please use Urgent honestly

Urgent jumps the queue. If everything is marked urgent, nothing is, and the requests that genuinely are urgent get lost behind the ones that aren't.

If you re-triage a request before anyone has replied — say a Normal turns out to be Urgent — the deadline moves with the new priority, so the clock always reflects what the request actually is.

After you send

Your request gets a reference like CLIP-014. Quote it anywhere — in a meeting, on WhatsApp, in a corridor — and the team will know exactly what you mean.

Everything you've raised is listed under Your requests with its current status:

StatusMeaning
NewReceived, not yet picked up.
In progressSomeone is working on it.
ResolvedDone — the reply explains what changed.
ClosedNo further action (a duplicate, or withdrawn).

Replies from the team appear in the thread and you're notified in-app. If you remember something afterwards — a learner's name, the exact time it happened — open the request and add a note; it goes straight back to the team.

Don't include passwords

Never paste a learner's password into a request. If it's an access problem, the learner's name or email is enough for us to act on.

For admins: working the queue

Admins work requests at Admin → Team requests (/admin/requests).

The queue is ordered the way it should be worked: anything past its promised reply time floats to the top, then New before In progress, then by urgency, then oldest first. The list defaults to open requests — Show all includes resolved and closed ones.

Opening a request gives you the full thread plus a triage row:

Status — move it through New → In progress → Resolved → Closed.
Type — re-classify it if it was raised under the wrong one.
Priority — re-triage it; the response deadline moves with it if nobody has replied yet.
Assignee — hand it to a specific person on the team.

Press Update to apply. The person who raised it is notified when the status changes, and emailed when it's resolved or closed.

Draft with Moe

In the reply box, Draft with Moe writes a first draft for you. Moe reads the ticket and the conversation so far, and produces a reply that restates the problem, says what happens next, and asks for anything genuinely missing.

Moe drafts, you send

The draft lands in the reply box for you to edit. Nothing reaches the person who raised it until you press Send — the words that go out are always yours. Moe never replies to anyone on its own.

Moe is deliberately conservative here: it won't invent a cause, a release date, or a setting that doesn't exist, and it won't promise a feature. If a diagnosis is uncertain it will say what to check or ask for instead.

Where requests are sent

A new request reaches the platform team three ways at once — in-app, by email, and by WhatsApp. The WhatsApp nudge exists because an Urgent request only has a one-hour clock, and email alone isn't reliably seen inside it.

Emergencies still call

A live class that can't start, or an exam-day failure, is a phone call — not a ticket. Everything else belongs here, where it's tracked.

On this page