The best part about building a ticketing system in Slate: it’s in Slate. By putting together a couple out-of-the-box Slate tools, you’ll be triaging, responding, and tracking support requests, student questions, staff tasks, and more all from the comfort of your own database.

What are you tracking?

First, identify who will submit tickets: students, staff, or external users?

Next, decide the information required on each ticket. This might include:

• Requestor name

• Department

• Category, or type of request

• Priority

• Description

• Attachments

• Deadline, and so on.

Define the resolution stages of a ticket. An example:  

• Submitted

• Triage

• In Progress

• Awaiting Info

• Escalated

• Resolved / Closed

Finally, assign responsibilities: who among your staff triages? resolves? escalates? monitors response time?

Your menu of options

Now that we know the requirements of the ticketing system we want to make, we can get into the implementation details.

There are many ways to go about it; Slate tools are open-ended and can be fitted together many different ways.

Here are some options:

Whichever Slate objects you choose to represent tickets depends on your requirements and your appetite for complexity.

Regardless of the route you choose, you can pull ticket data into a report, dashboard, or portal to track time to completion, look at  category breakdowns, and more.

Try our example ticketing system

Don’t feel like building all that out on your own? No problem: we’ve created an internal support ticketing system that you can import into your database and tweak to your liking.

This example uses forms to gather ticket data and collects it all in a dashboard:

Copy this Suitcase ID and paste it in Database → Suitcase Import to import our pre-made ticketing system:

d2609bbd-56b2-4394-88cf-19ab9b42d4bb:slate-examples

Making your own

If for whatever reason you don’t want to use the example ticketing system we’ve provided, you can always do it yourself.

This guide lays out the broad steps needed to make a medium-complexity ticketing system comprised of:

• ✏️ Custom fields, prompts, and material types

• 📝 A form (or forms) with which users can submit tickets

• ➡️ A workflow where tickets move through bins that represent resolution stages

• 🔔 Communications for acknowledgement, reminders, and escalations

• 🤖 Rules that assign ownership, change status, and route tickets

• 📊 A dashboard or portal in which staff can see tickets relevant to them

Best practices ⭐

• Keep the number of statuses/stages reasonable: Too many makes the system hard to manage

• Ownership should be unambiguous:  Each ticket should have someone responsible for its shepherding through the resolution stages

• Set expectations: So users know what to expect, make response times and stage transition times transparent

• Create notifications judiciously: Avoid overwhelming staff with too many messages

• Document your system: So staff know the meaning of each stage and how to respond

Step 1: Create custom fields & status indicators

▶️ Action item: Create any custom fields you’ll need to collect on the ticket submission form.

Your tickets will start their journey through your system as form responses. These forms will likely need custom fields to represent ticket data.

These fields might include:

• Ticket Stage or Status prompt (Dropdown or Single Select) with options mirrored to the lifecycle stages defined in the previous step.

• Assigned Staff / Owner

• Priority

• Due Date

• Last Response Date

• Resolution Date

Optionally create new material types to represent attachments like screenshots.

Step 2: Make the ticket submission form (or forms)

▶️ Action item: Create a form to capture ticket data.

• Add prompts / fields for all metadata (category, priority, etc.).

• Optionally allow attachments.

• Configure user access and authentication: internal vs external, whether they must login, whether form is public via portal, etc.

• Consider adding conditional prompts. Examples:

  • If category is IT → display Computer Type field

  • If category is Facilities → display Room Number field

• Otherwise, create a dedicated form for each category.

Step 3: Set up the workflow

▶️ Action item: Create a workflow for tickets.

• Define bin settings: which users or teams can see/order the bin, which bins feed into which next bins, whether any bins are “locked” or have restricted permissions.

• Automate movement of tickets through the workflow with bin & queue automations.

• Create multiple workflows if different request types follow very different paths, but beware the complexity that arises from many paths.

Step 4: Automate ticket assignment, notifications

▶️ Action item: Create staff assignment rules to assign tickets to staff or teams based on category or department.

Examples of these automations might include:

• On form submission → Assign default owner / triage group; set status = Submitted; send acknowledgement email

• If status remains in Triage for more than X hours/days → escalate or send reminder

• On change of status to Resolved/Closed → send resolution message to requestor; update Resolution Date

Consider also using populations to group tickets by owner, department, or priority, so staff dashboards show what’s assigned to them.

Step 5: Automate notifications

▶️ Action item: Create the notifications you want ticket assignees to receive throughout the lifecycle of a ticket. Create these notifications as form communications in the ticket submission form.

For reference, there are four communications associated with our example form:

• Confirmation: Sent to the ticket submitter with ticket number, title, and description upon submission.

• Assignment Notification: Sent to the assignee when a ticket is assigned (if the "notify assignee" checkbox is selected).

• Update Notification (Assignee): Alerts the assignee when a new message is added by the submitter.

• Update Notification (Submitter):  Sent when a ticket is updated with a new message, status change, or assignment includes key info and directs the user back to the portal.

Step 6: Visualize ticket data

Your options here are varied. Since we’re working from a workflow, we already have a tool with which to visualize certain aspects of the ticket pathway.

You might also create a standalone portal or dashboard that present the user with, for example:

• Open tickets by status, category, owner

• Aging tickets (tickets older than N days)

• Number of tickets submitted over time

• Average time in each status

💡 Tip: Ask Slate AI for help constructing queries, reports, dashboards, and portals.

Step 7: Test and train

Before full roll-out:

• Test the form(s), workflows, and notifications with sample entries.

• Confirm that owners get the tickets, the statuses and stage movements work, notifications are delivered.

• Train staff on how to use the system: how to mark status, reassign, add notes, respond, close.

Step 8: Monitor & iterate

• Use reports and queries to watch for bottlenecks (for example, tickets stuck in Triage)

• Regularly review workflows & stages: do any need modification? Are categories working well?

• Solicit feedback from requestors and staff to ensure clarity and ease of use

• Adjust automations (frequency of reminders, escalation thresholds) based on observed performance