Working with Work Types: What Actually Works?

“What Type of Work did you do?”

That is the only question a Tech needs to answer for the Customer’s invoice to be correct. The goal of Cascading Contract Automation is to shift the burden of invoice quality from the Support Team to the Professional Services Automation (PSA) software. In order to shift the burden, we need to reduce the support Team’s responsibility down to answering that one key question: “What type of work did you do?”  In other words, the only thing we need the Techs to do is to update the Work Type when filling in their time entries. To make this even easier, speed codes can be used, and I think you’ll find they come in very handy. With the list of exclusions in hand (from our last article), make sure there is a coinciding Work Type as well. By excluding a Work Type out of the Primary Contract, it will either be invoiced at the Standard Role Rate adjusted by the Work Type or picked up by a Secondary Exclusion Contract.

A word about roles:

Before going on to discuss Work Types, a word about Roles is in order. Roles are rates based on skillset, as opposed to the Type of Work that is being performed. A Role is the set Standard Rate the Company charges for each level of skill needed to do the work. The goal of a Cascading Contract Automation is to reduce the invoicing burden on the Support Team as much as possible. Reducing the number of Roles to as few as possible (even one goes a long way) reduces the burden on the Support Team. As long as the Standard Role Rate is the same between Roles, only one is needed. For example, some common Roles are:

  • Technician @ $150

  • Sr. Technician @ $175

  • Engineer @ $190

  • Architect @ $225

Take special note that each has a significant difference in skill level, and each bill at a considerably different rate.

: “What Type of Work did you do?” is the only question a Tech needs to answer for the invoicing to the Customer to be correct! Here’s why…

Work Types: What are they?

Work Types adjust the Standard Role Rate based on the Type of Work being performed. Some Examples of this are:

  • Remote Support @ Standard Role Rate

  • Onsite Support @ Standard Role Rate, but Excluded from some contracts**

  • Projects @ Standard Role Rate x 1.25

  • Afterhours/Emergence @ Standard Role Rate x 1.5

  • Network Administration / Technology Audits @ Standard Role Rate x .85

** If there are no contracts that exclude onsite work, then a Work Type “Onsite” is not needed. Just call the Remote and Onsite Support “Support” and only have one Work Type. If the ratio of Remote work to Onsite work is needed for some reason,there are other ways to mine the data for this information. In the three years SDB-C has been in business, working with Customers around the world, this ratio has never been requested.  Please do not make the burden of invoice quality any harder on the support team than necessary.

To Summarize…

Roles are the Standard Rates charged to Customers without Contracts, based on the skills needed to do certain classes of work.

Work Types override and adjust the Standard Role Rates and are used to exclude certain types of work from contracts. 

Contracts override both the Role and Work Type in the Time Entry and are used to adjust the invoice to the Customer based on Contractual Agreements.

The three work together to make sure the Customer’s invoice is fair and reasonable.  This is based on the relationship with the Customer and the contractual obligations.

One further note: In order to improve the quality of invoicing, and therefore the Customer experience, we use Cascading Contract Automation. Cascading Contract Automation works best when the burden on the Support Team is reduced as much as possible. 

Reducing the burden is done by decreasing the number of Roles (having only one Role if possible) and expecting the Techs to answer one question: What type of work did you do?That is a reasonable expectation and manual time entry requirement. This creates a situation where Work Types is the pivot point of shifting the burden from the Support Team to the PSA Software.

Okay, just one more note about Services: We find that very few MSPs are tracking Services in the Contracts, and for good reason. It’s a burdensome, manual process, and one that provides very little value. Tracking Service in the Contracts does not flow through to invoicing.** If the reason for tracking Services in the Contracts is for profitability reporting, there may be other ways to get to the information.

However, if the MSP would like the Autotask Standard Profitability Reporting running, then it is best to have the Service Coordinator set which Service applies to the request as part of the Triage process. This is a manual process, and from our experience, no one will look at, double check, or question if the right Service has been applied to the ticket or not. My guess is, the information will only be 80% correct, which is enough to base decisions on, but not enough quality to report profitability.

**Note: this is not to say the services attached to the Contract do not impact billing... they do by setting the MRR rate.  But the labor associated with the services attached to the ticket do not flow through to billing.

Now that we’ve discussed the list of Exclusions, a few Roles, and the Work Types needed, we are ready to jump in and start building the cascade…stay tuned!

Previous
Previous

From 0 to Zen: Making MSP Life Easier & More Profitable

Next
Next

Increase Revenue by 15% with Cascading Contract Automation