> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pawtograder.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Office Hours Overview

> Set up and run office-hours queues, work the help queue, and resolve student help requests

Office hours in Pawtograder are a real-time queue system for live help. Students submit help requests into a queue, course staff start working a queue to indicate they're available, claim requests, and chat with students by text or video until the request is resolved.

This page is the staff reference. The student-facing view is documented under [Office Hours for Students](/students/office-hours).

## Queues

A course can have any number of help queues. Common patterns include a queue per campus, separate text and video queues, or a queue per assignment during a busy week.

Each queue has the following configuration (set in **Manage > Office Hours > Settings > Queue Management**):

* **Name** and **description** — shown to students when picking where to request help.
* **Queue type** — `Text Chat`, `Video Call`, or `In Person`. Determines how staff and students communicate.
* **Active flag** (`is_active`) — see [Active vs inactive queues](#active-vs-inactive-queues) below.
* **Available flag** (`available`) — when unchecked, the queue stops accepting new requests but remains visible.
* **Demo flag** (`is_demo`) — demo queues are labelled "DEMO - NOT A REAL QUEUE" in the UI, send no notifications, and do not require active staff to accept requests. Use them for training.
* **Ordinal** — controls display order. Lower numbers appear first; ties break alphabetically by name.
* **Max concurrent requests** — optional cap on the number of open requests in the queue at once.
* **Closing time** — optional timestamp at which the queue automatically closes.
* **Color** — optional accent color used in queue badges.

Queues can be linked to Discord channels and to calendar events. When a calendar event's queue name matches a queue (or is explicitly linked), it appears as the staffed time for that queue on the dashboard.

### Active vs inactive queues

The **active** flag controls whether a queue participates in the live office-hours experience:

* **Active queues** appear on the student "Browse Queues" view and on the staff dashboard. Students can submit new requests to them (subject to the `available` flag and staffing).
* **Inactive queues** are hidden from both students and the staff dashboard, but remain editable under Queue Management.

Mark a queue inactive when it isn't currently in use — for example, an assignment-specific queue that's outside its window. You don't need to delete it; toggling `is_active` keeps history intact.

## The staff dashboard

Open **Manage > Office Hours**. The page has two modes depending on whether you're currently working a queue:

* **Not working any queue** — you see the **TA Dashboard**, listing all active queues with their depth, currently-working staff, and current/upcoming scheduled staff times pulled from the office-hours calendar. Click **Start Working** on a queue to join it.
* **Working at least one queue** — you see the **Working view**, listing:
  * **Requests I'm Responsible For** — split into **My Assigned** (requests where `assignee` is you and status is `open` or `in_progress`) and **Unassigned** open requests in queues you're working.

The header bar provides quick navigation to **Working**, **All Requests**, and **Settings** (Queue Management, Assignment Management, Templates, Moderation, Student Karma, Student Activity, Time Tracking, and — for instructors — Feedback).

### Starting and stopping work

Clicking **Start Working** creates an active `help_queue_assignments` row tying you to that queue. Other staff and students see you listed as currently staffing it. Click **Stop Working** (per queue, or the count button in the header to stop all at once) to end the assignment.

You can be working multiple queues simultaneously. The header shows a green badge with the queue name (or count) for any queues you're currently working.

## Resolving requests

Help requests move through four statuses, defined by the `help_request_status` enum:

| Status        | Meaning                                                 |
| ------------- | ------------------------------------------------------- |
| `open`        | Submitted, not yet picked up. Visible in the queue.     |
| `in_progress` | A staff member has claimed it and is helping.           |
| `resolved`    | The request is done. Removed from the queue.            |
| `closed`      | Closed without resolution (e.g. moderation, abandoned). |

From an open request, a staff member clicks **Start Helping** to take it. This sets `assignee` to the current staff profile and the status to `in_progress`. The student sees the assignee's name and a "Helping" badge with a running timer (based on `updated_at`).

While helping, the assignee can:

* Send text chat messages. Unsent text remains in the input if the connection drops so messages aren't lost.
* Click **Start Video Chat** to open a video call with screen sharing. After the staff member starts the call, the student sees a **Join Video Chat** button.
* Click **Stop** to release the request back to the queue (clears `assignee`, returns status to `open`).
* Resolve the request when finished.

### Who can resolve

Either the assigned staff member or the student can mark a request as resolved.

When a **student** resolves their own request, they pick a `help_request_resolution_status`:

| Value          | Label                                 |
| -------------- | ------------------------------------- |
| `self_solved`  | I solved it myself                    |
| `staff_helped` | Staff helped me                       |
| `peer_helped`  | A peer helped me                      |
| `no_time`      | No time to wait                       |
| `other`        | Other (with optional free-text notes) |

Students may also optionally provide thumbs-up/thumbs-down feedback with a comment when they resolve.

Staff resolve requests directly from the request view; the resolution status will reflect that staff closed the request.

## Help request templates

Instructors and graders can create help request templates under **Settings > Templates**. A template is a pre-filled help request body that prompts students to include specific information (steps tried, what they expected vs. observed, links to discussion posts, etc.).

Each template has:

* **Name** — what the template is called in the picker.
* **Category** — used to group templates in the picker (defaults to `General`).
* **Description** — optional short explanation of when to use this template.
* **Template content** — the body inserted into the student's new request, including any placeholder prompts.
* **Active flag** — inactive templates are hidden from students but kept for reference.

The template list shows a usage count per template, so you can see which prompts students are actually picking up. Use templates to enforce a "have you tried X" checklist before students join the queue.

### Referenced submissions and files

Students can attach a submission, specific submission files, and even line numbers to a help request. When a submission or file is attached, the request is automatically marked **private** (visible only to the student and staff) — the system enforces this when refs are added or removed, so private code doesn't accidentally end up on a public request. Staff helping the request see those file references inline in the chat view.

## Notifications

The office-hours UI surfaces multi-channel notifications (browser notifications, page-title updates, sound alerts, and a favicon badge) so participants don't have to keep the page focused.

If browser-notification permission isn't granted, a `NotificationPermissionWarning` banner appears on the dashboard with a button to request permission. You can test notifications from your help request page.

These notifications behave the same for staff and students. The student-facing details — including the persistent **Get Help** button and the active-request widget — live in [Office Hours for Students](/students/office-hours).

## AI assistance

When viewing a help request or a discussion thread, instructors and graders see an **AI Help** button that generates a Model Context Protocol (MCP) context URL. Connect that URL to any MCP-compatible AI client (Claude Desktop, Cursor, etc.) and the assistant can pull in the request, the student's referenced submission, test results, and build output to help you diagnose the issue.

AI assistance is restricted to instructors and graders; student-identifying data is not exposed to the AI. Configuration details, supported clients, and the available MCP tools are documented in [AI Assistance](/staff/ai-assistance).

## Other settings

The **Settings** menu in the Office Hours header also exposes:

* **Assignment Management** — manage staff queue assignments and shift records.
* **Moderation** — moderation actions taken on disruptive students.
* **Student Karma** — adjust per-student karma used for request prioritization.
* **Student Activity** — per-student activity summary across help requests.
* **Time Tracking** — staff time spent working queues.
* **Feedback** (instructor-only) — student feedback collected at resolution time, used to monitor quality of help.

## See also

* [Office Hours for Students](/students/office-hours) — the student-side experience (Get Help button, help drawer, active-request widget).
* [AI Assistance](/staff/ai-assistance) — setting up and using the MCP server and AI Help button.
* [Discussion](/staff/discussion) — for asynchronous help that doesn't need a live queue.