The new Ticket Efficiency reports do not appear to take into account the Labor Log, but instead appears to rely only changes to Ticket Status.
Why isn’t the Labor Log being taken into account?
1 Like
@andy, I am curious if you have any input here? as I am having a hard time understanding the point of measuring Technician efficiency without taking into account how much time technicians are logging/billing.
I’ve a few more questions too, but will hold those for a bit.
While there is value in tracking billed time by technician, this was specifically designed to measure tech efficiency against a global average. This is used to identify inefficiencies in your technician usage when taking into account when the tickets were in a workable state. This report won’t be used by small MSPs because they will typically “know” what’s going on when you just have 1 tech. At larger sizes it’s basically mandatory to know which techs are burning your efficiencies, and more importantly, where.
The part that would be more geared toward MSPs of your size would be the Customer variant. This one will identify for you which customers are consuming more or less time against your company average (across all customers). So it’s really easy to see where time is getting burned, often unexpectedly, along with knowing where you are faring better so you can act accordingly.
This report is useless. It has no bearing on time getting burned by techs or their efficiency. The calculation appears to be from when the ticket is created until it is closed. That has nothing to do with the amount of time a tech spent on the ticket or how efficient they are.
In a way you have to set it up. So for example, exclude “new” tickets as part of the timer and then have your techs switch it to “in progress” to start the timer. Something our company was doing already so I had data to use. Granted, somethings can be a bit off, but over all it does seem to be useful over time if you have more than one client either eating a lot of time or a tech. While I knew it already, it did show quoting eating a lot of our time up compare to some of the other task we was performing. As Andy said, if you are a small msp you more than likely know where your time is going… so the report it self wont be as useful. While we’re not a big msp, even having a few techs, it does help show me where we can improve time on some task over all.
But I understand where you are coming from. I believe you would like it to show bill time over - over all time - that was spent on that ticket. In theory, when your techs get on site, they could change it to something like “Billable Time” or “In Progress” and then when they leave switch it to something else. In that case, we would need a way to automate the switch if it was me. For example, we do have a “schedule” status - during that time the ticket doesnt add time - but when it comes time, it would be cool if it switch the task status to “in progress”.
@Andy With that said, this is also why I was requesting two in/out types for tickets
To better understand what the ticket was about / better idea on what was going on.
Also, the reports might be less useful if, for example, two techs were on a single ticket. That’s where the time sheets would be better represent their time. I might be wrong, but the current way doesnt actually take that into account either. Over all, garyh is asking for a way to account for real “billable time” over just the over all time report for a ticket.
@Andy
correct, the report you have called “Ticket Efficiency by Technician” isn’t all that useful for MSPs at our size of 1 to 2 techs.
Though for large sophisticated service delivery organisations (at least at the scale I’ve worked in previously), they wouldn’t call this report “Ticket Efficiency by Technician”. They would call this report a “Ticket Status Aging” report, and they would design the report output so a break down by status code could be seen. For example, keeping track of the time a ticket is waiting for parts, or waiting for quote is as important to know as keeping track of the time a ticket is in progress.
Such large SD orgs would measure Technician efficiency based on Available hours and Billed hours. Ticket aging is still important, but not used in isolation to measure Technician efficiency.
Available hours takes into account each employees FTE or technician time factor (FTE = Full Time Equilvalent) For a supervisor of a technical team, they might have an FTE of .2 or .5 or .7, depending on how much time they are expected spend “on the tools” so to speak.
Available hours takes into account, anytime off or any staff meetings, scheduled breaks etc etc. All this needs to be accurately recorded to establish the available hours employees can be reasonible expected to be focused on service delivery.
Billable hours is obvious, though a highly organised service delivery department will also have the concept of SUPs.
A SUP is a standard unit of production, and is measured in decimals. For example 1.5 or .75 or 5.24.
Usually SUPs are assigned to standardised procedures, and unless the procedure changes the SUP value stays the same.
SUPs are great for comparing service delivery departments to each other, especially those in different geographic areas/countries.
We are 4 engineers and manage 2000 endpoints. To make this report even somewhat useful, our engineers would need to put a ticket into a production status like “In Progress” when starting to work on each ticket, and set another status when they stop, even if they take a break. That is just not going to happen. Our engineers already accurately track the actual time spent working on a ticket and accounting double checks for anomalies during billing, all based on one data point.
We want to spend as little time as possible on repetitive non-productive tasks like updating ticket statuses that adds up, and more time on actually addressing the ticket goal.
I’ve also noticed that after putting a ticket to In Progress, it takes time (more than 1 hour) for the report to show any data about the ticket.
Why is this?
Why isn’t it instantaneous? Is there some background cron job that is running occasionally to push ticket data around?
Efficiency is exactly what this is measuring. It’s taking the efficiency of your entire MSP as a baseline, and this must include time the tickets are sitting unattended in a queue, and then breaks that down to compare each technician’s work against the global effort. If you don’t count the time the ticket was stuck in a queue, you could be taking two weeks to resolve a problem as an MSP, even when the ticket took 5 minutes of work to complete.
I think what you are likely after is technician utilization, though that isn’t measuring efficiency either. This is basically saying my tech clocked in for 40 hours this week, show me all the time they logged (assigned time to, billable or otherwise) for the same period of time. This report isn’t designed with that in mind, and this would be another report down the road which I do admit we need and we should build.
Yep this report wasn’t designed for one-person shops or those with one tech. At that level any report measuring tech efficiency or utilization isn’t going to be overly beneficial, because you are small enough to monitor those types of things as part of your normal “day-to-day.” However, the customer efficiency report is massively beneficial to MSPs of all sizes, including startup MSPs, because it exposes poorly qualified contracts by design.
This specifically has nothing to do with technician efficiency. I would highly suggest reading our KB article so you can better understand the feature and how it can be customized to these types of situations. You can pause the timer on any status you want, so you shouldn’t ever be tracking the time a ticket wasn’t in a workable status, like when you are waiting for a part of holding on a customer to approve a quote.
You are mixing two different reports, here. When measuring billed time against available hours, that is typically defined as technician utilization. Again, that has far less to do with efficiency and far more to do with ensuring all time is being allocated for properly (missed billables).
Your customers don’t care if you took a break or not, which is why efficiency is measured as the time any given ticket was in a workable state. Saying that your company efficiency, and therefore your tech efficiency is identical if your employees take 4 hours of breaks in an 8-hour period vs 1 hour in an 8-hour period cannot and should not be reported the same way.
As I mentioned above, I think you are looking more for a tech utilization report. That’s something we’ll be looking at in the future.
ahhh, no. That is wrong.
Low utilization is an employee who was idle because he wasn’t directed or provided the opportunity to do anything.
We have an asset that has nothing to do for part of the time that the asset is available to us.
Low efficiency is an employee who was idle when there was a lot of work to do.
We have an asset that isn't doing anything because it is broken or a sleep, or is locked away
High utilization and high efficiency are the opposites of those.
Efficiency is a measure of how much work is done over a particular measure of time. Using the amount of time in status codes doesn’t achieve that, and I was not infering that waiting for parts or waiting for quote was anything to do with technician efficiency (though it can be an indication of non technical employee efficiency in large SD orgs)…but other reports would be needed too to get the full picture of what was going on.
Here is an example of why data from Syncro Tickets being used in a Technician Efficiency report isn’t useful.
I’m focusing on a single ticket here, over a short time period.
The report says the average time per ticket was 11.89 hours.
@andy Given the change history of the ticket, how is this 11.89 hours calculated?
Yes, I delibrately set the ticket to in progress and then resolved with the ticket being in the in progress state for only a few seconds. I wanted to see what would happen to the Customer Efficiency report.
Notice that the ticket sat at New status for much longer that 11.89 hours.
Here is the change history of a ticket.
Hey Andrew,
You are very much getting into semantics of definitions here. These reports will showcase technician efficiency against your baseline. As I mentioned, there isn’t much value for an MSP of your size. Tech Utilization is something we’re looking at in the future, which is showcasing where your technician hours went in any given time period. These are not one in the same. Feel free to call those reports whatever you like, but the descriptions I’ve provided are exactly what they do and will be reporting on.
In regard to your last question, the time is calculated as the total time the ticket was in a workable state (again, this is documented in our KB I linked for you above). A workable state means the ball was in your court, and that can be customized by status in the Report Settings. Also, the ticket isn’t in a workable state if your business is closed, or your are on a holiday, for example, assuming you have those configured.
The definitions of all measurement methodology involving employees and customers are very important to get right.
- Employees that feel unhappy in the way they are measured are often unhappy employees…
- Business decisions about customer efficiency/profitablilty that are based on poorly designed measuring techniques…
can both obviously lead to poor business outcomes.
Ahhhh, that isn’t detailed in the knowledge base article you shared.
So this means that the calculation of customer or technician efficiency is trying (and failing) to take into account employee availability (which hours they are at work for), but there is no mechanism I can see to take into account these items which collectively can greatly influence the data
- staff that have a Full Time Equilvalent factor of less than 1.
- the standard number of full time hour week that staff are employeed for, which could be far less than the opening hours of the business.
- sub contractors
- staff in a different state that have different public holidays
- working outside of business hours (on call 24 x7 support)
- overtime
- sick leave
- annual leave
- long service leave
- having to leave early to pick up sick child from school
- starting early
- lunch breaks
- morning tea
- afternoon tea
- training events
- conferences
- staff meetings
- public holidays that are state based, not national based.
Also, what is the SyncroMSP definition of business open/closed?
I see this URL.
Business Hours (Holiday Calendar) - Knowledge Base / Admin and Settings - Syncro Support Community (syncromsp.com)
So I have set my business hours to 9am to 5pm (Mon to Sat), because I don’t want appointments or SLAs or tickets due outside of those hours, but for many Business Owners and many IT staff, that doesn’t mean that work doesn’t get done outside of those hours.
Another part of your new reports that is missing, which I hope is on the road map is the ability to compare months, quarters or years on a x-axis, with measured data on the y-axis. Column or Line or some other chart type etc.
I do agree these are very important metrics to get right, which is why they were developed the way they were. At this point Andrew, I think it’s safe to say this report isn’t going to give you what you’re after. I would suggest making some feature requests in the FR category here on these forums so you can detail exactly what you are after for new reports we may deliver somewhere down the line.
None of the things you referenced in the bullets above will really matter in regard to how the metrics are calculated. A technician has to work a ticket for it to be factored into a technician’s average. So if they are only part time, take a vacation, or get COVID for 2 weeks (or whatever) that doesn’t affect anything, because someone else is working those tickets and they aren’t being associated with the tech in question. I suppose if you had a tech sick for 2 weeks and no one picked up their tickets that might affect something, but if that type of thing is happening you have bigger problems at large.
In regard to other things like morning tea, afternoon tea, lunch breaks, staff meetings, training events, and having to pickup kids from school, the first thing I’d probably ask if I was consulting for said MSP would be, “When do your technicians actually work?” The second thing I’d say is that those, too, won’t matter. If you work 10 hours or 40 hours your averages are still your averages. The amount of time you spend per ticket on average shouldn’t change. If you regularly have someone working say Monday through Wednesday each week regularly leaving unfinished tickets open Wednesday night without properly passing them off to another technician, this is precisely the types of bad practices these reports will expose for you.
If you have business hours enabled, closed means the times you have defined as not being open. If you have an optional holiday schedule applied, it means you are closed on said holidays as well. If you work tickets after hours as a regular matter of practice, that too, should be reflected by your averages. In fact, any odd (good or bad) thing you may do as an MSP regularly would be averaged in, which is the reason these types of reports require averages and are designed to work off a company baseline.
There are not any current plans for comparisons as you described, but that would be a good example of what you could add as a feature request.
@andy
Agree, these reports are not going to be useful to me for measuring customer efficiency (or as we grow in 2023 and beyond will they be useful for technician efficiency).
Then why include business hours in the measurement if other things I mentioned which expand and reduce work hours dont matter. Hours a technician is avialable to work are either important or they are not important.
More feature requests?
There are plenty FRs at the moment I would prefer Syncro work on rather than adding to the pile.
And given the indication from you that measurement methodology is not going to change or be improved, me logging feature requests for time series comparisons isn’t logical as time series comparisons are pointless until the quality of the measurement methodology is improved.
I’m not following. All of the things you mentioned occur when you’re open. Being closed occurs, well, when you’re closed. You are closed far more than you’re open in any given week…
No problem, then feel free to focus on the things you find most important!
Open for business hours are hours that you expect customers to call, or schedule onsite visits, or schedule remote sessions with customers etc. Outside of those hours phones typically go to voicemail.
Those hours can be entirely different to hours that staff work. That an inherent part of being in the IT industry, and staff can be on flexible arrangements outside of standard office open hours.
Yes, these efficiency reports (customer and technician) I had high hopes to consider important for our business future (see eMyth revisited). But these reports are fast becoming unimportant to me because of the measurement methodology.
So I’m only tying up loose ends now, and I will put on our roadmap to design our own reports using the Syncro API.
@Andy I very much appreciate your time to chat about this, so I better understand your point of view. 
This is not within the confines of how business hours work within Syncro. They are relegated to when you’d like to run automations, and now, how these reports are calced as well. Again, the definitions matter here.
Sounds good!
I will again state here, the reports Syncro thinks would be important to us are NOT what we think will be important to us. We need to be able to create our own reports with full access to all our data and a full-fledged report writer like Power BI.
We are 4 engineers. I have played around with these reports in different ways and find the data is all over the place and not useful due to the way it is collected. For example, ae “efficiency” report for yesterday shows my Sr. Engineer at 1 hour but his employee time reports shows 7 billable hours.
1 Like
This report isn’t designed to track billable hours. The efficiencies presented are accurate as described in our KB article. Also, this is designed to track tickets from new to a resolved state. Billable time can be included on tickets that aren’t resolved…
@garyh I think this is the KB that Andy is refering to. I agree with you the reports are not of much value. Having read access to the database would be of far more value.
Customer and Technician Efficiency Reports - Knowledge Base / Reports - Syncro Support Community (syncromsp.com)
@Andy
This is incorrect
Your KB article does not describe that the Business Opening hours configuration are included in the calculation.
Please fix that.