Hello,
Is it possible to set a fixed rate for logging labor hours? At our company, if we de a job for 20 minutes, clients are charged 30 minutes. Or if we work 50 minutes, they’re charged an hour. But when we log the time as such, the rate is calculated differently. Wich is normal of course, but we would like to change this. I have not found a setting for this and it would be really convenient to have this.
There is not, at least not in the way you are describing. There is a setting in the Admin Settings > Ticket Preferences > Advanced called “Ticket Timer - Round UP to number of minutes.” So if it’s 15 minutes you’d always bill in 15, 30, 45 or 60 minute increments basically.
We are looking at having minimum charges for certain labor types. For example, if you have an on-site labor type you might make that a minimum of 60 minutes. So entering 15 minutes would fail validation and require you enter a minimum of 60 minutes there as well.
All of that said, it sounds like the rounding mechanic would solve your issue, right?
I like this.
However can it please be contract dependant?
For example, our current practice is.
Non-contract customers are charged for the first hour as a minium for onsite work, and in 30 minute increments after that.
Contract customers gain the benefit of being charged in 30 minute increments from the beginning of the onsite work.
Well I think it makes more sense being labor-type dependent for a few reasons:
1.) This allows you to have the same “rules” apply to every single contract, while using labor-type overrides on contracts so you can have differing rates off the same labor product (e.g. “Contract Labor”)
2.) It’s easier to setup if you run a hybrid MSP like you are describing. So all break/fix work can be handled without contract considerations
In your scenario, I believe all you’d need to do is have a “Break/Fix Labor” item that follows your hour minimum and 30 minute increment rule, and then a “Contract Labor” item that follows your 30 minute minimum, 30 minute increment rule.
Here is what I was thinking in how this would work. This would likely be in the Admin Settings under the Tickets header. Let me know if you think this would work for the way you described your use case:
Thanks @Andy , I think that would work too.
Ok cool. This should award folks quite a bit of flexibility overall that they don’t have today.
Sorry if i’m in the wrong spot, but this also needs “grace periods.” For example, we bill in one-hour increments, but to be fair to our customers, one hour and 15 minutes is an hour, but one hour 16 minutes is two hours.
I don’t think this would be possible here. This sets the minimum required billable time, and the minimum increments of time that can be billed for each labor type. Grace periods aren’t a super common practice, so the vast majority of folks would just bill that (75 minutes) out at 1.25 hours.
I made a note and I’ll track it to see if anyone else asks for anything similar.
Understood…we’ve been doing grace periods “in our head” or “at our discretion” for years, so it’s not that hard to do moving forward. We could also consider billing quarter hours.
Yeah we always used to have our techs do this as well at their discretion. It’s hard to handle this “officially,” but quarter-hour increments or even half-hour increments would probably work just as well.
This is what I do, as a 1-guy shop. If it’s trivial and not abused, then you’re not billed. Would be hard to codify I’m sure. Doubtful they’d want to have a “how hard actually was this ticket” field to perform maths on. 
I came here searching for exactly this. Is this in the pipe?
It is, actually. Check a few posts above I describe how it will work.
Yep, I read the entire thread. It’s a workable solution, not perfect but it is a start.
What do you feel is missing?
I probably misspoke. I’m coming from Autotask where there is such granularity in everything. I like the simplicity of Syncro. It doesn’t need to be a beast and I hope it doesn’t become one. I’m still going through my setup and testing. I’m sure there is much more functionality I haven’t seen yet to make my transition easier.
Is there an eta when this will be added?
No, it got pushed for other priorities but I just checked, and it’s still planned to be worked. No eta.
Hi @Andy! This all sounds interesting! I came here looking for some options to bill a minimum amount each month.
In theory, I like the options being discussed, but I’ve always felt that by rounding up individual timer entries really skews the actual labor, so there is no way to account for real time spent on a ticket. For example, if my ticket timer rounds to 30 minutes. I connect to a PC, start a virus scan which takes 4 minutes, it records 30 minutes. Then I come back and review the results and log another 6 minutes, it records 30 minutes. Actual time is 10 minutes, but I’d see a full 60 minutes logged (because I tracked time twice for a ticket). Heaven forbid you revisit an issue numerous times in small increments.
Instead…
I see this as more of a billing function (instead of a ticket or time-tracking function), in that I’d like to see billed hours rounded up at the time of billing. This would still allow me to see actual time spent on an issue without inflated labor time logs. It seems this would allow us to better track the overall profitability of our agreements.
For example…
ClientA amassed 45 minutes of labor across all tickets, but their contract says we bill a minimum of 1 hour labor in 30 minute increments for each billing period. It would be great if, when generating the invoice, it would make sure it met or exceeded the minimum (ie billed a total of 1 hour, instead of 45 min) and rounded anything over an hour up to the nearest half-hour (ie 1 hour, 12 minutes would be billed as 1.5 hours).
Just some thoughts… I know there are a million different ways and a million different ideas on the best way to handle it. I’m happy to discuss further if it would be helpful!
Thanks for all you and the Syncro team are doing to support us!
Dude, SUPER good point on the time rounding. In fact, billable vs actual usage is a pretty sick metric if you think about it.
So I think what you are really saying is tracking time against technicians is one thing, and tracking time billed as labor is completely segregated from that. Let me know if that’s how you are thinking about it (that’s how I am thinking about it now.
The only negative I see to this is the development cost, because tracked time literally touches like half of the entire platform. So I am curious your opinion, if doing this as proposed took a few weeks, but doing it how you suggest could potentially takes months (just throwing out numbers I have no idea the engineering cost currently), then:
1.) Does what is proposed here offer an improvement over what exists today, even if we don’t divide out the time?
2.) Would you rather see it split out, even if that means it takes significantly longer and has the potential to be deprioritized (whenever the scope expands then it always raises a question of priority)
I am curious to hear your thoughts on those.
