MSP Time Tracking: The Leak Is at the Phone, Not the Timer

A client calls the main line at 10:40. The tech who answers knows them, resets a locked account while the user is still on the phone, confirms they can sign in, and hangs up. Seven minutes. There was no ticket open when the call started, so there was no timer to start, and by the time the next call comes in the work is gone. Nobody decided not to bill it. It just never became a record.

That is where most MSP time tracking breaks. Not in the timer, not in the PSA, and usually not in technician laziness. It breaks at the phone, where real work happens outside the ticket that time tracking assumes already exists.

What MSP time tracking is supposed to do

MSP time tracking is recording the time technicians spend on client work as time entries in the PSA (ConnectWise PSA, Autotask, HaloPSA, Syncro), each tied to a ticket, a client, a work type and a billing decision. Those entries do three jobs:

• Billing. Hourly and block-hour clients are invoiced from them.
• Agreement profitability. On flat-rate and per-user agreements, time entries are the only record of what a client actually costs you to support.
• History. The note on the entry is often the only account of what was done, for the next tech and for the client who asks what they are paying for.

Good time tracking means every piece of client work ends up as an entry, close to when it happened, with a note someone else could act on. Most advice stops at "log time in real time." The harder question is what happens to work that has no ticket to log against.

Where MSP time actually leaks

Look at where unlogged time comes from and the pattern is clear. It is rarely the two-hour project. It is the short, interrupt-driven work that happens between tickets:

1. Calls with no ticket. A quick fix done live on the phone, like the account reset above. The work is finished before anyone thinks to create a ticket, and creating one afterward just to log seven minutes feels like paperwork.
2. Calls on a ticket that is not open on screen. The client calls back about an existing issue. The tech handles it from memory, means to add a note, and moves on.
3. Callbacks and voicemail chases. Three attempts to reach a user before the fourth connects. Each one is a few minutes. Almost nobody logs the misses.
4. End-of-day reconstruction. The tech fills in the timesheet at 5:30 from memory and calendar gaps. Short work gets merged, rounded or forgotten, and the notes get thin.
5. Rounding in the tech's head. Some techs round seven minutes up to fifteen. Others feel awkward billing a client for seven minutes and enter nothing. Your rounding policy ends up being whatever each tech feels like that day.

Notice that only the last two are discipline problems. The first three are structural: the work happened somewhere the time tracking process does not reach.

Why the usual fixes don't close it

The standard advice is to start a timer when you start work, log time before you close a ticket, and track in consistent blocks. All reasonable, and all built on the same assumption: that the work starts inside a ticket.

• Timers only help when someone opens the ticket first. On a live call, the tech is listening and typing into the client's system, not into the PSA.
• "Log it before you close it" catches nothing when there is no ticket to close.
• Time blocks (half hour, full hour) make the reconstruction easier but bury short calls inside larger entries, or drop them.
• A policy memo gets compliance for two weeks. Then the queue gets busy and the phone wins.

If your service desk takes a lot of calls, you can tighten discipline as much as you want and still lose the time that never touched a ticket.

A one-week audit that shows the real gap

Before buying anything, measure it. You already have the two data sources you need.

1. Export a week of answered calls from your phone system (3CX, Teams Phone, RingCentral, Zoom Phone and most others have a call history report), filtered to your technicians, with duration and who answered.
2. Export the same week's time entries from your PSA for the same technicians.
3. Line them up per tech, per day. For each answered call over a couple of minutes, look for a time entry on that client around that time.
4. Sort the calls with no matching entry into the five buckets above.

You are not looking for a precise percentage. You are looking for which bucket is biggest. If most of the gap is calls with no ticket, a timer policy will not fix it. If most of it is end-of-day reconstruction, coaching and a same-day deadline might. The audit tells you which problem you actually have, and it gives you something concrete to show the team instead of a lecture.

One caution: do this as a look at the process, not a hunt for slackers. If techs think the audit is about them, the next week's numbers will look great and tell you nothing.

Make the time entry a byproduct of the work

The durable fix is to stop asking technicians to create a separate record of work they just did, and make the record come out of the work itself. For phone work, that means the call becomes the entry.

That is what Vight does. It pulls each recorded call from the phone system, transcribes it, matches it to the client and ticket, writes a summary of the issue, the steps taken and the resolution, and posts it to the ticket as a note with a time entry. The tech takes the call the way they do now. See how it works with ConnectWise and Autotask.

Whatever tool you use for this, the details that decide whether the entries are right are PSA-specific, and worth checking before you trust any automation:

• ConnectWise PSA. Time entries need a work type that is valid on the ticket's board, and the member posting must have a work role there. ConnectWise may round an entry's hours to the increment set in your system settings, so a seven-minute call may land as a tenth or a quarter hour. Decide that rounding on purpose.
• Autotask. A time entry is posted against a resource with a role. A technician whose resource has no service desk role cannot get one, so check roles before you assume time is being captured for everyone.
• HaloPSA. Time on an action carries a charge rate. Time posted without one is logged as No Charge, even on a ticket covered by a contract, so set the charge rate the automation should use.
• Syncro. Time is a ticket timer entry tied to the technician's Syncro user, with labor products standing in for work types. Map technicians to users first.
• Calls with more than one tech. When a call is transferred or a senior tech joins, decide who gets the time. Vight gives the summary to one technician and a pointing entry to each of the others on Autotask and HaloPSA, but the policy is yours to set.

For work that is not on the phone, such as remote sessions and console work, the same idea applies to the screen. Vight's Work Notes Agent, currently in beta, captures a technician's work session on a ticket and turns it into a step-by-step note the tech can post as a time entry. On ConnectWise it can post those entries automatically.

What to keep human

Automating capture does not mean automating judgment. Three things should stay with people:

• Billable or not. A call about a printer covered by the agreement and a call that turns into a new project request should not get the same billing treatment. Set work types and billing defaults deliberately, and have someone own the exceptions.
• Rounding and minimums. Put your minimum increment in the agreement and the PSA, not in each tech's head. Then a seven-minute call is billed the same way no matter who answered it.
• Review. Someone, usually the service manager, should skim new entries weekly: entries with no note, entries far longer than the work described, and clients whose time suddenly jumps. Automation makes this easier because the notes are consistent. It does not make it optional.

Why this matters most on flat-rate agreements

If you bill hourly, missing time is lost revenue and you feel it on the invoice. On all-you-can-eat and per-user agreements, missing time is worse because you do not feel it at all. The invoice is the same either way. What changes is your read on whether that agreement makes money.

A client whose users call the help desk three times a day for quick fixes can look profitable on paper because none of those calls became entries. When renewal comes, you price the next term from the time you recorded, and you underprice it again. Accurate time on flat-rate clients is how you find out which clients to reprice, which to train, and which to let go.

Common questions about MSP time tracking

Should MSPs track time on flat-rate clients? Yes. You do not bill from it, but it is the only way to know what each agreement costs to deliver. Without it, renewals are priced on guesswork.

What time increment should an MSP use? Pick one minimum billing increment, write it into your agreements, and configure the PSA to match. The specific number matters less than every technician applying the same one.

When should technicians enter time? As close to the work as possible, and the same day at the latest. Entries reconstructed later lose short work and detail. Better still, capture the entry from the work itself so there is nothing to remember.

What is the biggest source of unlogged time at an MSP? It varies by shop, which is why the one-week audit above is worth doing. At service desks that take a lot of calls, quick fixes handled live on the phone with no ticket open are a common culprit, because no timer-based process reaches them.

Do I need separate time tracking software if I have a PSA? Usually not. Your PSA is where time entries belong and where billing reads them. What helps is something that gets work into PSA time entries without the technician retyping it.

Find your own leak first

Run the one-week audit. If calls with no ticket turn out to be your biggest bucket, that is the gap Vight was built for. Book a demo and we will walk through how calls from your phone system turn into notes and time entries in your PSA.