HelpSpot Help Desk Software | HelpSpot Blog | HelpSpot Support

Feature Request - more detail on time logs


I asked a while back about start and end time for a different reason (i.e. to calculate time used). This is not for that reason.

It would be helpful if a start and end time were able to be recorded on a time log so that we are able to identify “blank” time spaces - i.e. when we’ve not logged time.

In addition, we often would like to record mileage against a specific time log - say for a site visit to correct an issue. Clearly, mileage is too specific, but would it be possible to have custom fields on time logs as well as against issues. I would consider adding mileage as a customer field to the issue but that would only cater for one instance and not tie to to a specific user.

On a similar note - although I haven’t thought of a use for it yet, custom fields on the call history could also be useful.

Not the end of the world if these can’t happen but they would be useful. :slight_smile:


Hi Jamie,

Thank you for the feedback. We’re going to be thinking about the time tracker more for v3. No details yet, but we’ll certainly consider this.

Custom fields would be interesting, I’ll definitely put it down for consideration but it’s probably not something you’d see in a near term release. We do have some ideas for TT though that could help in this area so we’ll see where it leads.

For now, I have a few ideas. Since I believe you’re parsing this information into another system (you referenced this in an email) you could use the description field for these details. So come up with a standard format that your staff will use. For instance for milage, parse the description for M:17 for 17 miles. So “Went to xyz to fix their printer M:17”

This would depend on the discipline of your staff of course, but other customers are doing similar with good results.

You could also use a custom field as you mention and just have staff increment it. So staffer one goes someplace and puts in 10 miles. Staffer 2 who does 5 more updates the field to 15. Since all the changes are logged you could still see who changed each and at what level.

I think the first idea is easier if you’re parsing into another system, but this could also work.