If You Never Tell Clients It Was a Project, They'll Never Know It Wasn't Just a Bad Ticket.

Your client calls into your service desk. They need Teams voice set up for each of their 15 employees. Your engineer opens a ticket and tells them the work will get started. The engineer begins by researching how to implement Teams voice. They document everything per your documentation expectations. Everything seems to be working well.

After doing the research, they try implementing it with one of the users. But they realize they need to buy licenses and need some additional help. They escalate the ticket and wait for it to be resolved.

The ticket gets escalated to the billing department, who need approval for the licenses. This takes a few days to get done, since Amy in billing is out on PTO. When she returns, she gets the licenses approved by the client and gets things moving again. The ticket goes back to the engineer.

By that time, the client has followed up on the status, expecting tickets to get resolved relatively quickly. From their perspective, they'd already paid for the licenses. Why weren't their new accounts set up and working already?

It takes an additional week for the original engineer to get the phones set up, since the ticket had been sitting in "waiting on client" status. By the second follow-up, the client is getting seriously impatient that the work still isn't complete. They start messaging the MSP's owner directly, voicing real concern over their service experience.

When you look into it, you realize the work being done was never supposed to be handled by the helpdesk in the first place. It classified squarely as a project. The rule you use, one we recommend, is simple: if it impacts more than 5 users, takes more than 5 hours to complete, or takes more than 5 tasks to finish, it's a project. Every single one of those criteria was being met here, and it was still handled as a service ticket.

A bad service ticket at that. One that made the client lose trust in your service quality.

Your team wants to help out. That's one of your core values, something ingrained in them. The helpdesk engineer thought he was helping by opening the ticket and just working it. The problem is, when you misclassify the work, putting project-level tickets on the helpdesk, you set your team up for failure. A bad client experience, a harder time getting through normal ticket volume, and hours of time consuming work sunk into finishing something that was never supposed to be a ticket in the first place.

That project disguised as a service ticket ended up creating a real problem for both you and the client. The client never valued the work being done. They never realized it wasn't a standard request, and they were never given any real expectation for how long it would take. If you never tell your client when their request is actually a project, they'll keep walking away from botched work thinking your team's work is just slow and underwhelming.

I want to call this out one more time, because it matters if you plan on scaling your MSP. You need to get your team to understand what a project ticket actually is, and what a service ticket isn't. Be specific. Be clear. My own definition, the 5-5-5 rule, was easy for my team to remember and call out on sight. Feel free to use it, or come up with your own. Just get your team hyper aware that not every request or ticket submission should be treated the same. Some should never touch the helpdesk at all, because the work is fundamentally different.

A ticket may come in looking doable on the helpdesk. But it fits your definition of a project. What should your team do? Work it anyway? You'd probably say no. Make it a project and hand it to the project team.

I'd build in real controls, so that if a tech starts working a ticket before realizing it's actually a project, they don't get stuck in the project muck. Even a trojan project, one that looks small and doable but quietly creeps past 20 minutes of work, needs a checkpoint. Have your engineer run through a quick check to confirm it really isn't a project. If they can't check every box, the ticket automatically redirects to the project board for review.

Force your engineers to name the ticket for what it is. Over time, they'll learn to recognize what a project looks like before they even start the work. As they get more experienced, they'll be able to call out a project the moment the request comes in, and can even redirect the client to a conversation with their account manager instead.

But if you run into a situation where the ticket had already been nearly completed on the service desk, keep it as a learning moment. Even if your client is pissed off about their experience with the helpdesk working their misclassified project, you still have a chance to save it.

You've most likely missed the opportunity to bill your client for the project. Heck, if you try to bill them now, they'll probably want to reevaluate their whole contract with you. But you still have a real chance to build credibility and a stronger relationship with them.

Have a phone call. Apologize. Listen to them. Then explain that your engineer was so eager to get the issue resolved, they didn't stop to treat it as the billable project it actually was. Explain that this normally would have been handled by a project team member and would have cost around $2,500. Because you appreciate working with them, you wanted to credit that cost this time.

That demonstrates that the work your team did actually had real dollar value behind it. By crediting the project, you build relationship capital with them instead of losing it. Simply put the credit on their invoice and close the issue out. Talk to your team about why projects exist in the first place. They aren't just a way to make more money. The work itself is more specific than helpdesk work, and it requires additional planning.

Make sure you communicate to your client why something was a project, and get your team into the habit of doing the same going forward. Bad tickets often stem from miscommunication, and I've run into this exact misclassified project problem more than I'd like to admit. It's an entirely easy thing to fix once your team actually understands what a project is, and why projects exist in the first place, why every ticket shouldn't just get worked on the helpdesk.

My challenge to you. Talk to your team, and stop letting real project work disappear quietly into the service desk ticket queue.

Start refining your service delivery system at builttorunmsp.com.

Frequently Asked Questions

Why do clients undervalue MSP services that were actually large projects?

If a client is never told something was scoped and delivered as a project, they have no way to recalibrate their sense of what the work actually involved, so they judge it purely on how long it took.

What's the real cost of letting a project run as an unlogged ticket?

There are two costs, not one. The direct cost is unbilled labor at a fully loaded rate. The hidden cost is a client who now believes a normal turnaround time is much longer than it actually is.

How should a technician handle a ticket that turns out to be a full project?

The ticket should pause for proper scoping the moment a defined threshold is hit, and the client should be told directly and early that the work is bigger than originally expected, with a clear plan going forward.

Why does staying silent about scope creep damage the client relationship?

Silence removes the client's ability to see the value being delivered, so a delay reads as poor service instead of as evidence of a larger, more complex job being handled well.