Service Requests
Centralized ticket management for customer and internal service requests — from submission to resolution.
Overview
Service Requests is the central inbox of the Service Desk module. It gives agents and administrators a single, unified place to create, track, prioritize, and resolve tickets originating from customers, internal staff, and call center escalations. Every ticket is captured with a subject, description, category, priority level, and an optional assignee, ensuring that no request falls through the cracks.
The screen supports SLA-based prioritization, automatically clocking time from ticket creation until resolution. Category routing allows your team to group related requests together and filter by topic — making it easy for the right agent to find the tickets they own. Real-time status tracking gives every stakeholder visibility into where a ticket stands in its lifecycle at any moment.
Whether you manage a small internal IT helpdesk or a high-volume customer support operation, Service Requests scales to your workflow. Combine it with the SLA Monitor screen for breach alerts and the Knowledge Base screen for self-service deflection.
Key Features
Ticket Inbox
All open, in-progress, resolved, and closed tickets appear in one consolidated list. Use quick filter pills to zero in on a specific status without leaving the screen. The list shows subject, category, priority badge, assignee, and creation date at a glance.
Priority & SLA
Tickets carry one of four priority levels — Critical, High, Medium, or Low — each with a defined SLA target. The SLA clock starts the moment a ticket is created and stops when it reaches Resolved status, giving you accurate response-time data for every request.
Category Routing
Assign each ticket to one of five categories: Hardware, Software, Network, Account, or Other. Category routing lets agents filter their queue by expertise area, and managers can spot which categories are generating the most volume to identify training or infrastructure gaps.
Status Workflow
Every ticket progresses through a clear four-stage lifecycle: Open → In Progress → Resolved → Closed. Each transition is timestamped, creating a complete audit trail. Agents can move tickets forward or reopen a Resolved ticket if the customer reports the issue persists.
Ticket Statuses
Each ticket carries exactly one status at any given time. The status badge is color-coded in the ticket list for instant visual scanning.
| Status | Color | Meaning |
|---|---|---|
| Open | Blue | New ticket awaiting first response. The SLA clock is running. No agent has begun work on the request yet. |
| In Progress | Amber | An agent is actively working on the ticket. The SLA clock continues to run until the ticket is Resolved. |
| Resolved | Green | A solution has been provided and is awaiting customer confirmation. The SLA clock stops at this transition. |
| Closed | Gray | Ticket fully closed and archived. The customer has confirmed the resolution or the ticket has been administratively closed. |
Priority Levels
Priority determines the SLA target time — the maximum elapsed time from ticket creation to resolution. Set priority accurately at submission time to ensure high-impact issues are addressed first.
| Priority | SLA Target | Use Case |
|---|---|---|
| Critical | 4 hours | System outages, data loss, or complete service disruption. All operations are halted for the affected user or team. |
| High | 8 hours | Major functionality is impaired with no viable workaround available. Significant impact on productivity or revenue. |
| Medium | 24 hours | Partial functionality loss where a workaround exists. Users can continue working but with reduced efficiency. |
| Low | 72 hours | Minor issues, cosmetic bugs, general inquiries, or feature requests with no impact on core operations. |
Creating a Ticket
Any agent or administrator can create a new service request directly from the Service Requests screen. Follow the steps below to submit a well-formed ticket that reaches the right agent quickly.
Required Fields
- Subject — A concise, descriptive title for the issue (e.g., "VPN connection drops every 30 minutes"). Keep it under 80 characters so it is fully visible in the ticket list.
- Description — A full account of the issue: what happened, when it started, which users or systems are affected, and any steps already taken to diagnose the problem.
- Category — Select the most relevant category: Hardware, Software, Network, Account, or Other. This controls how the ticket appears in category-filtered views.
- Priority — Choose Critical, High, Medium, or Low based on the impact and urgency guidelines in the Priority Levels table above. The SLA clock starts immediately on save.
Optional Fields
- Assignee — Select the agent responsible for resolving the ticket. If left blank, the ticket appears in the unassigned queue for any agent to pick up.
- Notes — Internal notes visible only to agents. Use this field to document troubleshooting steps, reference a Knowledge Base article, or leave context for another agent who may take over.
Once saved, the ticket status is automatically set to Open and the SLA clock begins. The ticket appears immediately in the main list and in the SLA Monitor screen if its SLA target is within the warning threshold.
SLA Breach Warning
SLA Clock and Breach Alerts
Tickets approaching their SLA deadline display a red clock badge in the ticket list and on the SLA Monitor screen. This badge appears when a ticket has consumed 75% or more of its allotted SLA time without reaching Resolved status.
The SLA timer starts the moment a ticket is created and stops the moment its status changes to Resolved. Changing status to Closed does not stop the SLA clock — only Resolved does. If a Resolved ticket is reopened (status changed back to Open or In Progress), the SLA clock resumes from where it left off.
Use the SLA Monitor screen for a real-time dashboard view of all tickets near or past their SLA target, sortable by time remaining, priority, and category.
Search & Filtering
The Service Requests screen uses the standard TotalApp two-row header layout to keep primary actions and filter controls clearly separated.
Row 1 — Title & Primary Actions
The top row shows the page title ("Service Requests") on the left and the Add Ticket button on the right. This is the only action in Row 1 — no filters or dropdowns belong here.
Row 2 — Filters & Controls
The second row contains all search and filtering controls in left-to-right order:
- Search input — Type any keyword to filter tickets by subject or description in real time. The input grows to fill available horizontal space.
- Status filter pills — Quick-tap pills for All, Open, In Progress, Resolved, and Closed. Selecting a pill immediately narrows the list to tickets with that status. Only one pill can be active at a time.
- Category dropdown — Filter by Hardware, Software, Network, Account, or Other to focus on a specific topic area. Defaults to All Categories.
- Refresh button — Manually reload the ticket list to pull in changes made by other agents. Always positioned as the rightmost control.
Search and status/category filters combine — for example, searching "VPN" while the status pill is set to "In Progress" shows only in-progress tickets whose subject or description contains "VPN".
Tips & Best Practices
Getting the Most from Service Requests
- Reserve Critical priority for genuine outages. Marking every ticket Critical dilutes urgency signals and makes it harder for managers to identify true emergencies. Use the SLA target table to guide priority selection.
- Use the Notes field to document troubleshooting steps. When another agent needs to take over a ticket, a populated Notes field eliminates back-and-forth and reduces resolution time significantly.
- Resolve tickets promptly to keep SLA metrics green. The SLA Monitor screen aggregates breach rates by category and priority — a pattern of breaches in one category is a strong signal that staffing or Knowledge Base coverage needs attention.
- Link related tickets with cross-references in the Notes field. If multiple customers report the same root-cause issue, note the related ticket IDs so your team can track the incident holistically.
- Close tickets only after customer confirmation. Moving directly from In Progress to Closed without a Resolved stage skips the customer confirmation window and can mask recurring issues that were not fully fixed.