How to log phone calls as tickets (a field-by-field template)

Why calls are the channel that leaks

Email arrives already written down. Chat leaves a transcript. A phone call leaves nothing unless a person turns it into a record, and that person is usually busy, mid-conversation, and about to take the next call.

So the failure mode is predictable. A client calls, the tech says “I’ll take a look,” and the promise lives in one head. Three days later the client calls again, someone else answers, and the history is gone. This is the same slow leak described in how to move from a shared inbox to a help desk, except calls are worse because there is not even an inbox to scroll back through.

This guide is about the human routine: what to write down, in what order, and how to keep it under a minute. It assumes you want one record per problem, not one record per call. If you are still deciding how calls reach your techs in the first place, start with how to set up a help desk phone line and come back.

The principle: log the problem, not the conversation

A call log says “10:42, Dana, 6 minutes.” A ticket says “Dana’s shared drive is read-only since this morning, affects 4 people, she tried a reboot, she needs it by 2pm.” Only the second is useful to the next person who touches it.

Write for a colleague who has never heard the call. If they could pick the ticket up cold and act on it, you logged it correctly.

A field-by-field template

You do not need a long form. Capture these, in this order, while the caller is still on the line.

1. Who is calling, and for whom

• Caller name and a callback number. Confirm the number out loud, because the number on caller ID is often a desk phone or a mobile that is not the one they want you to use.
• Organization. For an MSP this is the field that keeps client A’s problems out of client B’s queue. Set it before anything else.
• Affected person. The caller is not always the person with the problem. “My boss can’t print” is a ticket about the boss.

2. What is broken, in one sentence

Write a title that names the thing and the symptom: “Reception printer offline, jobs stuck in queue.” Avoid “Printer issue” and never use “Call from Dana” as a title. Titles are how techs scan a queue, and a name tells them nothing.

3. Impact and urgency

Ask two questions and write down the answers:

• How many people are affected?
• Can they work around it right now?

One person with a workaround is a normal-priority ticket. A whole office that cannot take payments is not, no matter how calmly the caller describes it. Callers underplay and overplay equally, so record the facts you were told and let the priority follow from them.

4. What they already tried

“Restarted it” and “same on two laptops” are the two most valuable lines in any ticket. They save the next tech from repeating the first five minutes, and they save you from asking the caller the same questions twice.

5. The exact error, if there is one

Ask the caller to read it to you or, better, send a screenshot by email or text while you are talking. Paraphrased errors (“something about a certificate”) waste hours. Exact strings are searchable.

6. What you promised, and by when

This is the field most shops skip and most clients remember. Write the commitment as a sentence: “Tech will call back by 3pm with a status.” If you promised nothing, write that too, so nobody assumes a promise existed. If you track response targets, our guide to tracking SLAs in a help desk covers how to turn that sentence into a timer.

7. Which asset it touches

If you keep an inventory, link the device or service. If you do not, put the hostname, serial number, or location in the description. Either way, “the server” is not an answer when the client has three.

Classify before you hang up

Most help desks distinguish between something that is broken and something someone wants. Make that call while the caller is still there, because you can ask a clarifying question for free and cannot later.

• “The VPN stopped working” is a break: log it as an incident.
• “Can you set up a laptop for the new hire starting Monday?” is a service request.
• “This is the third time the same thing has failed this month” is a signal that the underlying cause needs its own record.

Do not agonize. A wrong type is easy to fix later. A missing ticket is not.

Dedupe: update the open ticket instead of creating another

Before creating anything, search by caller, organization, and keywords. A client calling to ask “any update?” should add a note to the existing ticket, not generate a second one.

Two quick rules:

1. Same problem, same caller or same organization, still open: add a comment and bump priority if the caller says it is getting worse.
2. Same symptom from a different person at the same client: link it to the first ticket, because a second person reporting it is useful evidence of scope.

If three people call about the same outage, you want one ticket with three callers listed, not three tickets with three techs working the same problem separately.

The 60-second routine

When volume is low, you can do all of this live. When it is not, use two passes.

During the call (30 seconds): caller, organization, callback number, one-line title. Create the ticket now so it exists even if the next call interrupts you.

Right after the call (30 seconds): impact, what they tried, the error text, your promise, and the type. Send the caller a confirmation if your tool supports it, so they have the ticket number in writing.

The rule that makes this work: the ticket is created before the call ends, even if it is nearly empty. An incomplete ticket gets finished. A mental note does not.

Handling the awkward calls

Calls that arrive while you are already on one. Don’t put the caller on a long hold to write things up. Take name and number, say you will call back in a few minutes, and create a placeholder ticket titled with the caller and time. Fill it in afterward.

Missed calls. A missed call is still a request. Someone should create a ticket for it, or your tool should, with the number and time. Call back, then write down that you did and what you heard.

Voicemail. Treat each message as a ticket draft. Listen, retitle it with the actual problem, and file it under the right organization. A mailbox that gets checked weekly is where promises go to expire. We cover that pattern in more detail in how to answer support calls after hours.

Calls that are just a quick answer. If you solved it in two minutes, log it anyway and close it with a one-line resolution. Those tickets are the data that shows which problems keep coming back, which is how you decide what to document or fix at the source.

What automation can and cannot do

Some of this can be automated: matching the caller’s number to a contact, attaching a recording or transcript, and turning a voicemail into a ticket. Those are worth having because they remove typing.

What automation does not replace is judgment about the problem. A transcript is not a title, and a recording is not a statement of impact. Whoever owns the ticket still needs to read it and write down the one sentence that makes it actionable.

Where ITSM fits

ITSM is built so calls land as tickets rather than as a separate log. It supports an AI phone agent that answers inbound calls using live ticket data, and a browser softphone add-on so techs can take calls without a separate PBX. Tickets cover incidents, requests, problems, and changes, with organization-level separation, SLA tracking, and a CMDB for the asset link. You can sign up free at /register and try the routine above on a real queue, or look around on the ITSM site first.

The template works in any help desk, though, including one you already own. The tool matters less than the habit of creating the ticket before the call ends.

ITSM is a small product with a free tier (2 seats, $0), so judge it on your own queue rather than on our word.