Service Desk vs Project Work: Count Onboarding Hours

Why Not Use the Desk's Spare Time?

A desk is staffed in whole people, so it can carry some slack, as the example below does. The modeled annual available hours already include deductions for leave. The model describes the rounding headroom as absorbing dispatch, leave and peaks, so check coverage across the actual roster before assigning that time to projects.

In the model's example MSP, 700 seats at a well-run ticket rate, the desk does 3.20 FTE of work with four people. That leaves 0.80 FTE of slack, about 77.6 hours a month, before the desk needs a fifth tech.

Now put onboarding there. The example signs 8.7 new clients a year at 60 hours each, which is 43.6 hours of onboarding a month. That uses more than half the desk's slack, every month.

In the growth setting it is worse. The example signs 14.5 new clients a year, and onboarding becomes 72.7 hours a month. That is nearly all of the slack, gone to projects.

But Is It Cheaper on Paper?

Yes, and it is worth saying so. The model priced it: leaving onboarding in the desk's slack instead of on project engineers would add $43,362 to the example's EBITDA, about 1.2 points.

My view: that saving is borrowed from your desk's headroom. It only exists while the desk happens to have slack, and I'd expect the cost to show up where the P&L doesn't track it, in a slower queue. The model's own decision is the same: onboarding is project work, done by project engineers.

How Big Should the Project Team Be?

Size it from two kinds of hours, not one.

• Billed project hours a month: your yearly project revenue divided by your project rate, divided by 12.
• Onboarding hours a month: new clients a year times about 60 hours each, divided by 12. Nobody pays for these, but somebody does them.

Add the two monthly figures and divide by a project engineer's productive hours a month. The model plans project engineers at 85% of their available hours, 117.58 hours a month.

Using the model's rounded monthly hours, billed projects plus onboarding require (131.0 + 43.6) / 117.58 = about 1.48 project engineer FTE. Billed work alone needs 131.0 / 117.58 = about 1.11 FTE. Onboarding needs 43.6 / 117.58 = about 0.37 FTE, which accounts for the difference.

Compare billed and onboarding commitments with available project hours for the dates you've promised. Have the project lead name an owner for any work the current allocation doesn't cover before it is assigned.

Why Does Onboarding Cost so Much If It Is Free?

The fee is waived, but the work isn't. You quote an onboarding fee, then include it to get the agreement signed. The client pays nothing, and the 60 hours still happen.

That is why the example's project labor runs $10,524 over its 50% allowance. The billed projects earn their margin, and the free onboarding hours pull the project line down. Knowing that is better than hiding it in the desk.

What If You Do Not Have a Project Engineer Yet?

Then name one. At a small size, the project engineer may be one of your senior techs. Skip the title debate and put the named person's project role separately on the board.

• Project lead: put project and onboarding work in a separate queue or board, not on the service desk queue.
• Person assigning tickets: block that person's project days in advance, and take them off the ticket rotation on those days.
• Project engineer: track hours in the two buckets, billed and onboarding, so the owner can size the role from real numbers next quarter.

When onboarding hours plus billed hours fill most of a person's productive month, that is your signal to hire the next one.

What Do You Check Every Month?

Two numbers. First, desk slack: productive hours on the desk minus ticket and alert hours. If it is shrinking while ticket volume holds steady, something other than tickets is eating it, and a project is the first place I would look.

Second, project hours a month: billed plus onboarding, against your project engineers' productive hours a month. When that line gets close, hire before the next client signs rather than after. Fix the delivery side before adding clients, so new signatures don't come out of the service your existing clients get.