Incomplete service-call records force owners, schedulers and dispatchers to chase customer details, clarify appointment promises and revise the calendar. The copyable template below captures the minimum information needed to assess a request, confirm an appointment and either assign a technician or leave that decision for dispatch review.
This is a vendor-neutral starting point, not an official industry standard. Choose one set of field labels and use it consistently.
Copyable field service booking template
Copy this table into a document, spreadsheet or scheduling system. Keep required fields concise, and use conditional fields only when they affect timing, capacity or assignment.
| Section | Field | Use | Entry |
|---|---|---|---|
| Record control | Booking reference | Required | |
| Record control | Record owner | Recommended | |
| Record control | Created date and time | Required | |
| Record control | Last updated | Recommended | |
| Customer | Customer name | Required | |
| Customer | Primary phone | Required | |
| Customer | Email or alternate contact | Optional | |
| Customer | Account or customer reference | Conditional | |
| Jobsite | Service address | Required | |
| Jobsite | Site contact | Conditional | |
| Jobsite | Access or parking notes | Conditional | |
| Request | Service category or request type | Required | |
| Request | Concise service description | Required | |
| Request | Priority | Required | Standard / urgent |
| Appointment | Customer-requested date or time | Required | |
| Appointment | Confirmed customer window | Required once confirmed | |
| Appointment | Internal scheduled start | Required once scheduled | |
| Capacity | Estimated job duration | Required before scheduling | |
| Capacity | Buffer input | Conditional | |
| Assignment | Required skill or service capability | Conditional | |
| Assignment | Required crew size | Conditional | |
| Assignment | Known equipment, access or approval requirement | Conditional | |
| Assignment | Assigned technician or crew | Required decision | Name / unassigned pending review |
| Assignment | Pending assignment owner and review time | Required if unassigned | |
| Status | Booking status | Required | |
| Recurring service | Frequency | Conditional | |
| Recurring service | Next-visit preference | Conditional | |
| Recurring service | Series reference | Conditional | |
| Handoff | Scheduling or dispatch note | Optional |
Spreadsheet-ready column labels: Booking reference, record owner, created date and time, last updated, customer name, primary phone, email, account reference, service address, site contact, access notes, service category, service description, priority, requested time, confirmed customer window, internal scheduled start, estimated duration, buffer input, required capability, crew size, known requirements, assigned technician or crew, assignment owner, assignment review time, booking status, recurring frequency, next-visit preference, series reference, handoff note.
The field groups are informed by the current ServiceTitan field service booking template, which includes customer, jobsite, service, priority, appointment, duration, crew and instruction details. That vendor template is useful evidence for common inputs, but it does not establish a universal field-service standard.
What each booking field is for
A field belongs in this pre-job record when it helps staff identify the customer or site, understand the request, assess schedulability, confirm timing, estimate capacity or support assignment. Details used mainly while performing or closing the job belong in downstream documentation instead.
Record control
A unique booking reference helps distinguish similar requests. For paper or spreadsheets, adding a record owner and last-updated time is a practical control that may reduce uncertainty about which copy is current. These controls are operational suggestions rather than requirements validated by the cited vendor template.
Customer and jobsite
Capture enough information to contact the customer and identify the service location. Use a separate site contact when the person granting access differs from the customer. Access notes should contain practical scheduling information, not repair instructions or sensitive information that the booking team does not need.
Service request and priority
The description should be concise but specific enough for a scheduler to recognize the service category and likely capacity requirements. A priority label distinguishes standard and urgent requests, but the label alone does not determine emergency response, escalation or which existing appointment should move.
Duration and capacity
Estimated duration is the expected working time used for planning. A separate buffer input can record any additional calendar allowance required by the business. If the team needs a full method for setting these controls, use the guide to calendar rules and booking buffers rather than expanding the booking form.
Location, duration, date constraints and resource requirements are also reflected in Microsoft’s documented scheduling inputs. The exact fields a small business needs will depend on its services and team structure.
Assignment requirements
Record only requirements already known at booking, such as a required capability, crew size, access condition or equipment category. These entries help determine whether a particular technician or crew can be assigned; they should not become technical diagnosis, repair or safety instructions.
Recurring service
For recurring calls, add the frequency, next-visit preference and a series reference. That is normally enough to identify the booking as part of a sequence without turning one appointment record into a complete recurring-schedule system.
Suggested booking statuses
No official source establishes universal booking-status labels. The following set is an adaptable internal convention. Document who changes each status and the event that triggers it.
| Status | Suggested meaning | Permitted next action |
|---|---|---|
| Requested | The service request has been captured, but no appointment has been promised. | Check requirements and availability. |
| Tentatively scheduled | An internal slot is being held, but customer confirmation is incomplete. | Confirm the customer window or release the slot. |
| Confirmed | The customer-facing appointment window has been agreed. | Assign now or place in assignment review. |
| Assignment pending | The appointment is recorded, but the technician or crew decision remains open. | Named owner reviews assignment. |
| Assigned and ready for dispatch | A technician or crew has been selected and the booking record is ready for the next operational stage. | Hand the record into dispatch. |
| Rescheduled | The previous appointment timing has changed. | Record the new confirmed and internal times. |
| Cancelled | The booking will not proceed as scheduled. | Record the status and latest update. |
If software automatically adds a dispatched status after handoff, treat that as a later workflow event rather than a field needed to make the initial request schedulable.
Separate requested, confirmed and internal appointment times
Using one field called “appointment time” creates ambiguity. Keep these entries separate:
- Customer-requested time: the customer’s preference. It is not yet a promise.
- Confirmed customer window: the customer-facing date or arrival window the business has agreed to.
- Internal scheduled start: the operational time used by the team to plan the appointment.
- Estimated duration: the expected time needed for the service call.
- Buffer input: any additional calendar allowance recorded under the business’s scheduling rules.
- Booking status: the current state of the request, not another time field.
Microsoft documentation on booking time constraints distinguishes promised time windows from other scheduling constraints. The exact terminology is product-specific, but the underlying distinction supports keeping the customer commitment separate from internal planning.
For a detailed process beyond the template fields, see the guide to aligning customer arrival windows and internal job times.
Choose assigned or unassigned before handoff
The booking record needs an explicit assignment decision, but that decision does not always have to be a technician’s name.
Assign during booking when
- The required capability and crew size are understood.
- The expected duration and appointment constraints are recorded.
- Known access or equipment requirements are clear.
- An appropriate technician or crew is available under the business’s scheduling rules.
Leave the booking unassigned when
- The required capability or crew size remains uncertain.
- Availability has not been reviewed.
- Important timing, location or access information is missing.
- A dispatcher or another named person owns the assignment decision.
When leaving a booking unassigned, record both the decision owner and the review time. “Unassigned” should be a visible state, not an empty cell that could mean either pending work or forgotten data.
In its own product workflow, ServiceTitan technician dispatch documentation states that a technician must be assigned before dispatch. That supports distinguishing assignment from dispatch, but it is a ServiceTitan-specific sequence rather than a universal requirement for every business or software system.
Completed booking examples
All names, addresses, references and scenarios below are fictional. They demonstrate how the fields can be used, not universal operating procedures.
Example 1: Solo operator with a known assignment
| Field | Fictional entry |
|---|---|
| Booking reference | EX-SOLO-1042 |
| Record owner | Jordan Lee, owner |
| Customer | Alex Morgan |
| Primary phone | Fictional contact on file |
| Service address | 10 Example Road, Sampletown |
| Service category | Standard service call |
| Service description | Customer requests inspection of a reported operating issue. |
| Priority | Standard |
| Customer-requested time | Tuesday afternoon |
| Confirmed customer window | Tuesday, 1:00 p.m.–3:00 p.m. |
| Internal scheduled start | Tuesday, 1:15 p.m. |
| Estimated duration | 90 minutes |
| Buffer input | 30 minutes recorded under internal calendar rules |
| Assigned technician | Jordan Lee |
| Booking status | Assigned and ready for dispatch |
| Last updated | Monday, 4:10 p.m. |
The owner receives, schedules and performs the call, so assignment is known immediately. The customer’s window remains separate from the internal planned start.
Example 2: Office-managed team with assignment pending
| Field | Fictional entry |
|---|---|
| Booking reference | EX-TEAM-2087 |
| Record owner | Taylor Reed, customer service |
| Customer | Casey Smith |
| Service address | 25 Demonstration Avenue, Example City |
| Site contact | Casey Smith |
| Access notes | Site contact must provide building access. |
| Service category | Assessment visit |
| Service description | Customer requests an on-site assessment of a reported service issue. |
| Priority | Standard |
| Customer-requested time | Thursday morning |
| Confirmed customer window | Thursday, 9:00 a.m.–12:00 p.m. |
| Internal scheduled start | Thursday, 9:30 a.m. |
| Estimated duration | Two hours |
| Required capability | Dispatcher to verify against internal team capability records |
| Assigned technician or crew | Unassigned pending review |
| Pending assignment owner | Sam Patel, dispatcher |
| Assignment review time | Wednesday, 12:00 p.m. |
| Booking status | Assignment pending |
| Last updated | Tuesday, 3:20 p.m. |
Here, the customer service representative captures and confirms the booking, but a dispatcher owns the later assignment decision. The blank technician name is replaced by a clear pending status, owner and review time.
Booking-to-dispatch handoff checklist
- Confirm the customer and service address can be identified.
- Check that the service description, category and priority are understandable without additional interpretation.
- Verify that the requested time, confirmed customer window and internal scheduled time have not been confused.
- Record estimated duration and any applicable buffer input.
- Capture known capability, crew, access or equipment requirements without adding technical instructions.
- Assign a technician or crew when the relevant requirements and availability are known.
- If assignment is pending, name the decision owner and review time.
- Make the current booking status and last update visible.
- Update the same record if the appointment is rescheduled or cancelled.
- Hand the completed pre-job record into the next scheduling or dispatch stage.
After this checklist, the booking is ready for the separate dispatch-board assignment workflow. This template stops at the booking-to-dispatch handoff.
Using the template on paper, in a spreadsheet or in scheduling software
| Format | Practical fit | Control to consider | Main limitation |
|---|---|---|---|
| Paper | Solo operators or very low booking volume | One filing location, visible reference and handwritten update time | Changes and shared visibility depend on manual handling. |
| Spreadsheet | Small teams needing a shared booking list | Unique reference, record owner, controlled status list and last-updated column | Concurrent edits, duplicates and stale copies require active management. |
| Scheduling software | Teams with frequent changes, shared calendars or substantial assignment volume | Consistent required fields and clear ownership | The business still needs agreed field definitions and status rules. |
The paper and spreadsheet controls above are practical suggestions, not source-validated requirements. Static templates can require manual updates and re-entry, a limitation also identified by ServiceTitan’s template page. As booking volume and schedule changes increase, a connected scheduling system may make shared visibility and maintenance more manageable.
Whichever format you use, keep one authoritative booking record, avoid collecting fields that do not affect scheduling or assignment, and stop the template at the booking-to-dispatch handoff.