Help · Working a ticket

Working a ticket

Once a ticket lands in the queue, this is what the coordinator does with it — set status, work the discussion thread, watch the timeline, and link the work it spawns back to the original record.

#Why this exists

The intake article shows how problems get into Gearflow. This article picks up where intake ends. A ticket without follow-through is just a Smartsheet row in a fancier app — the value lands when the coordinator (the office person who works tickets — in Settings > Users, typically the Dispatcher or Account Admin role) uses the ticket as the place where everyone gathers around the same problem: who's on it, what's been promised, what's been done, and what work it spawned downstream.

Most fleet operations teams have nowhere to look for that picture today. They have a status column on a spreadsheet that one person updates, a thread of texts a different person knows about, and an email chain a third person started. That unowned space between the field reporting needs and the office sourcing them is the coordination gap — the problem Gearflow exists to solve. The Working a ticket surface closes it for one ticket at a time: one record, one timeline, one discussion thread, with the requests it spawned linked back to it as cards.

#What you're looking at

Tickets live under the Tickets tab in the left navigation. Each row is one ticket — title, status pill, the job it touches, the unit, and the people on it. The tabs along the top (All / Open / In Progress / History) split the lifecycle into the three buckets a coordinator actually triages from.

The Tickets list view with All / Open / In Progress / History tabs. Rows show titles, status pills, source icons, dates, jobs, and the avatars of the people on each ticket. — The Tickets list. The little icons next to the status pill are the intake source — phone, voice memo, email, SMS, or the in-app form. Avatars on the right are the participants (creator plus anyone added to the discussion).

Open a ticket and the detail panel slides in from the right.

An In Progress ticket detail panel showing the status pill, title, badges for job and energy unit, a Timeline section, a Discussion section with participant avatars, and Ticket info / Create requests buttons at the bottom. — Ticket detail. Status pill and title at the top, then the badges row (job, business unit, optional unit), then the Timeline and Discussion sections, then the Ticket info / Create requests action pair at the bottom.

#Lifecycle

Open → In Progress → Done · Canceled

Open is the initial state — the ticket has been filed but no follow-up action has started. In Progress is the working state — usually entered automatically the moment the ticket spawns its first request (an equipment request, a maintenance, a mobilization, or a parts request), but a coordinator can also push it there manually from the status dropdown. The terminal states are Done (the work resolved successfully) and Canceled (the ticket was dropped — duplicate, false alarm, no longer relevant).

The History tab of the Tickets list, showing four rows — two with Complete status badges and two with Canceled status badges. — The History tab. Complete (Done) and Canceled tickets sit side by side; the status pill on each row tells you which terminal state the ticket landed in.

#Changing status

Status changes happen from the dropdown on the ticket detail. Click the current-status pill at the top of the panel and the four options appear.

The status dropdown on a ticket detail, showing the four options — In Progress (selected), Open, Done, Canceled. — The status dropdown. Four options — Open, In Progress, Done, Canceled — and the current one is checked.

Three rules of thumb for the manual status change:

Open → In Progress happens automatically when the ticket spawns its first request. Use the dropdown if you're working a ticket that won't have any spawned requests (a documentation-only "drop this off at the yard" ticket, say) and you want it to show up under In Progress.
In Progress → Done usually waits for the spawned requests to close out, but the dropdown lets a coordinator mark Done sooner if the resolution is already locked in.
Anything → Canceled is for tickets that were duplicates, false alarms, or no longer relevant. The discussion thread is still preserved as a record.

A Canceled ticket detail panel with the gray Canceled status pill, title 'Flat tire on water truck - false alarm', a one-message discussion thread, and Missing info / Create requests buttons at the bottom. — A Canceled ticket. The status pill goes gray and the discussion thread stays accessible — anyone searching later sees the explanation in the creation message ("Aired it up and it's holding fine. No action needed.").

#The discussion thread

Every ticket has a Discussion section below the Timeline. This is where everyone working the problem talks to each other — back-and-forth between the coordinator and the field user who filed it, mentions of other team members, photos of what's actually going on in the field, decisions made and PO numbers committed. The first message in every thread is the ticket's original description.

The top of a discussion thread on the Excavator down ticket. First message is the original creation description; subsequent replies are from Rupert Dispatcher and another field user adding context. — The top of the discussion thread. Original creation message at the top (the field user's description); replies follow chronologically. Each message shows the sender's name, a date stamp, and edit/menu controls on hover.

Three mechanics worth knowing:

Attachments on every message — PDFs, photos, videos, audio. Drag-and-drop into the composer, or use the paperclip. Photos render as inline thumbnails; documents show as a chip with the filename and an icon.
@-mentions on team members. Type @ and the autocomplete shows everyone in the org. Mentioning someone adds them to the thread (if they weren't already) and triggers a notification. The mention shows up highlighted in blue.
Participant management. The avatar row at the top of the Discussion section is everyone listening to the thread. Any coordinator can add or remove participants. The Unsubscribe link in the header is the self-toggle.

A later part of the same discussion thread, showing an @-mention of Rupert Manager highlighted in blue, an attached PDF chip, and a message confirming the replacement excavator arrived on site. — Lower in the same thread. The coordinator escalates to a manager via `@`-mention (the name highlights in blue and the manager is auto-added to participants); a field user attaches a PDF of notes; a follow-up message closes the loop ("Replacement excavator showed up at 6:45am...").

#The timeline

Above the Discussion section sits the Timeline — a chronological list of everything that happened on the ticket. Different from the Discussion thread, which is what people said. The Timeline is what people did: status changes, requests submitted, assets updated, AI re-analysis, links added, links removed.

The system records nine distinct event types on a ticket:

Created	The moment the ticket was filed.
Status changed	Open → In Progress, In Progress → Done, etc. Records both the from and to status.
Updated	Title, job, or other field edits.
AI description	The AI's structured read of the ticket finished or refreshed.
Assets updated	The unit list on the ticket changed.
Linked	An existing equipment request, mobilization, or maintenance was attached to the ticket.
Unlinked	A link was removed.
Request submitted	A new request (equipment / mobilization / maintenance / parts) was created from this ticket.
Message	Someone posted in the Discussion thread. Mirrors the discussion message but stays on the timeline for chronological reference.

You won't see every event type on every ticket — a one-step ticket that goes Open → In Progress → Done shows three events plus messages. A complex ticket that spawns three requests, gets re-tagged with assets, and crosses two status transitions can show ten or twelve.

#Linking to existing work

The Create requests button on a ticket detail spawns new requests pre-filled by the AI. But ticket work often touches things that already exist — a unit that already has an open maintenance, a mobilization that's already on the schedule, an equipment request that was submitted before the field user even called in. The Associated section on a ticket lets a coordinator attach those existing records without re-creating them.

The Associated section on a ticket detail, showing two linked record cards — a Maintenance for hydraulic pump rebuild and a Mobilization for the move from Chicago to Phoenix office — with a 'Find request' combobox at the top. — The Associated section. Each card shows the type (Maintenance / Mobilization / Equipment), the asset, and the current status. Clicking a card opens that record. The "Find request" combobox at the top is the entry point for linking something new.

Click into the Find request field and the combobox opens, listing existing equipment requests, mobilizations, and maintenance records the coordinator can choose from.

The Find request combobox open, showing existing equipment requests scoped to the same user's organization. Each row shows the asset, status, and job. — The combobox open. Searchable by title, unit number, or job. Pick a result and the link is made — the ticket gets a new Associated card, and the request gets a new "Ticket" link on its detail page. Linking auto-pushes the ticket to **In Progress** if it was still Open.

Two situations where linking matters most:

Cross-domain visibility. A ticket about a broken unit spawns a Maintenance for the repair, a Mobilization to move the unit to the shop, and an Equipment request for the rental that bridges the gap. All three live on the ticket as Associated cards. Anyone opening the ticket sees the whole solution in one place.
Already-existing work. Someone files a ticket about a unit that already has a scheduled maintenance. The coordinator links the existing maintenance to the ticket rather than creating a duplicate — the ticket is now the conversation hub, and the maintenance is the operational record. Same goes for mobilizations and equipment requests.