Leave the call with a request someone can act on
A customer says, 'Can you send someone Tuesday?' You have an opening, so you agree. Then the technician asks which building, what the visit covers, and who will let them in. The calendar has an appointment, but the team still has an unfinished conversation.
Service call intake closes that gap before booking. Its job is to establish the purpose of the visit, collect the details needed to arrange it, and identify what still requires a decision. You do not need to solve the service problem over the phone. You need a request that another person can understand without reconstructing the call.
Use the questions below as a conversation guide. Adapt them to your team's work, and skip details that do not affect the request. Try the worksheet on one actual call and check what your dispatcher still needs before adopting it. Finish with one clear outcome: book, request an internal review, or collect specific missing information.
Clarify the visit before discussing a time
Start with 'What would you like us to help with?' Let the customer describe the request, then ask what they expect from this visit. A routine service, an initial assessment, and work already described in an accepted estimate are different requests. Do not quietly turn one into another because the customer used a familiar job name.
Ask whether the request relates to a previous visit or document. Find the relevant record and check that it concerns the same location and equipment. A matching customer name is useful context; it does not establish that today's scope is unchanged.
Microsoft's work order documentation separates details about the work, service location, contacts, and assets. Its scheduling guide then checks duration, location, date range, and any promised arrival window. For a phone conversation, the useful principle is to collect the request first and check its booking requirements before making a commitment. The worksheet below is a suggested process, not a description of software fields.
References: Microsoft Learn: work order details, location, contacts, and assets · Microsoft Learn: review requirements before scheduling
Copy this service call intake worksheet
Keep one copy with the request. Write short answers in the customer's language, adding a source or confirmation where it matters. An explicit 'unknown' is more useful than a blank that could mean either 'not applicable' or 'forgot to ask.'
- Request reference and call date: _____. Caller name, role, and callback number: _____. Read the number back.
- Service location: _____. Which building, unit, room, or area does the request concern? _____.
- Customer's request, in their own words: _____. What should this visit address? _____.
- Relevant equipment or item, if known: _____. Existing job, visit, or estimate reference: _____.
- Visit purpose: _____. What is already agreed, and what still needs review? _____.
- Access contact and arrangements: _____. Who has confirmed that someone can provide access? _____.
- Availability: _____. Any date constraint: _____. Requested time versus time actually agreed: _____.
- Open questions affecting booking: _____. For each, who will obtain the answer, and by when? _____.
- Outcome: book / internal review / missing information. Next action: _____. Named owner: _____. Next customer update due: _____.
Separate reported concerns, confirmed details, and unknowns
A useful intake record shows how you know something. 'Customer reports a recurring interruption' preserves what the caller said. 'Equipment failure confirmed' makes a different claim and needs supporting evidence. Avoid converting a customer's suggested cause into a technician's finding.
Keep the distinction visible in ordinary language. You do not need a complicated coding system. These three labels are enough for a first pass:
- Customer-reported: the concern, timing, or previous experience described by the caller. Attribute it to them.
- Confirmed: an administrative detail checked during intake. Record the source, such as 'caller confirmed service address' or 'visit scope matches estimate reference 104.'
- Unknown: information still needed, why it matters to the booking, and who will obtain it. Do not fill the gap with an assumption.
Choose one next step and name its owner
Use the answers to make one decision. Missing details need attention when they affect which visit to arrange, where it happens, access, or a commitment to the customer. A detail that can reasonably be collected later should still have an owner, but it need not automatically stop the booking.
Do not describe a request as booked when someone is still deciding whether the proposed visit fits. Microsoft's creation guide distinguishes saving a work order from saving and booking it. Your team's wording should make that same practical distinction clear.
- Book: the visit purpose and necessary arrangements are clear, and the dispatcher has checked the appropriate availability. Read back what is actually agreed.
- Internal review: the office needs a colleague to decide the visit type or scope. Name that reviewer and the person responsible for updating the customer.
- Missing information: identify the exact answer required, who will supply it, and when your team will check back. Keep the request open with a named owner.
References: Microsoft Learn: save a request or save and book it · Next: build the field service schedule
Fictional example: turn a vague request into an owned follow-up
This example is fictional. Jamie calls to request 'the same maintenance as last time' for a small office and asks for Tuesday morning. The previous record covers two items at the main building. Jamie now wants one item serviced in the annex, but cannot confirm who will open it.
A vague note would say: 'Repeat maintenance, Tuesday morning.' A useful note says: 'Customer requests maintenance for one item in the annex. Prior visit covered two items in the main building; scope is not confirmed as identical. Caller confirmed the annex address. Access contact is unknown. Tuesday morning is requested, not booked.'
The intake outcome is missing information. Alex in the office owns the request, will obtain the access contact from Jamie by Monday afternoon, and will check the visit scope against the team's maintenance process. Alex will then arrange the appointment or explain the next review needed. The customer knows who is calling back and when.
Before ending any intake call, read back the purpose, current outcome, and next action. Ask whether that matches the customer's understanding. Once the visit is booked, carry those details into the schedule and keep the open questions attached to the request. The same habit makes the eventual customer handoff easier: each person can see what was requested, what was agreed, and what still needs an answer.
References: Later in the workflow: the customer handoff checklist