What each tab on a service ticket is for, and which one to reach for.
Last updated
A service ticket is more than a description and a status. The tabs across it are where most of the real work happens, and each one exists for a distinct job. Here is the map.
The ticket itself: what the issue is, which unit it concerns, priority, status, who it is assigned to, and the schedule. Start here and keep it accurate, because everything else quotes from it. In particular, vendors price from this description and recipients of an access request read the access details stored on it.
The running conversation about the work. Use it for anything a future reader would need in order to understand why the job went the way it did, especially decisions taken verbally.
The automatic history of what happened to the ticket and when. You do not write here; you read it when reconstructing events.
Files attached to this ticket: photographs, quotes, reports, drawings, sign off sheets. See Documents on a Service Ticket.
Asking the occupants of a unit for permission to enter, or giving notice that entry is required, and tracking each answer. See Requests for Access.
Inviting vendors to quote on the work, comparing the proposals, putting the choice to a board vote where required, and awarding it. See Requests for Proposal.
Closing the amenities the work affects, and dealing with the bookings already in the diary. See Asset Impact and Closures.
A typical larger job runs through several of them in order. The ticket is raised and described on Details. Quotes are gathered on RFP and awarded, which sets the schedule. Asset Impact closes the affected amenity for those dates. Access Requests gives the affected units notice. Paperwork lands in Documents, and the decisions that were taken by phone get written into Comments so the next person understands them.
Skipping a step rarely fails immediately. It fails on the morning of the work, when a resident has the gym booked and nobody told the unit that a technician is coming.