Project Management - Services object vs Tickets

[Adam_W]

TL;DR: Should we stop using the Service object and switch to Tickets for project management?

We're currently using monday.com for project management; frankly, it's not great. We almost exclusively communicate with customers via HubSpot as we move them along, and the normal updates and back-and-forth have to be replicated in Monday either using Zapier, a somewhat hit-or-miss connection, or manually. 

Based on the above and the launch of the Services object, we decided to give Services a whirl. A lot of it is working well for managing workload, progress updates, and nicely knitting together the other objects that relate (Contacts, Companies, Deals, etc.).

However, we're running into a big issue on the reporting side. Much like the issues I've had with reporting churn in HubSpot, there appears to be no way to track progress as an average, as the "duration" fields are inaccessible to us muggles. 

Services propertiesTicket properties

So, while I can produce a report that tells me how long most tickets are in "New", "Waiting", "Escalated", etc. and the same with deals moving through the pipeline, you can't do that in Services. For us, this is a big miss. I'd like to be able to track and manage the team as they deliver a customer implementation; however, that doesn't seem possible. 

This means that if I have one person on the team who consistently struggles in phase 2 of a project, there's no easy way to address that.

I know we could create many, many, many custom properties and then futz about with workflows to timestamp progression from one phase to another, but....sheesh...

Is the only way to create another non-support "queue" in tickets and use those as a defacto project object? 

[Adam_W]

Hi @BérangèreL,

Sorry to follow up with you on this. I'm trying to implement this workaround now, and have stumbled upon something odd. When I try to create the first custom property, which I'll use as a date/time field for when new items are added to the queue, I get an error: This label is used by a system property. This seems to suggest that there's already a HubSpot object with the same name!

Naturally, this is a bit frustrating as I'm creating these only because HubSpot doesn't track this information natively. Although this appears to suggest that it does. So, I dug a little further and found that all the fields I need to use/create already exist:

However, none appeared in the exported Excel file when I downloaded the properties.  Lastly, there's a group in the Services properties list that I can't delete, but is empty:

So, is this a soon-to-be-launched new set of properties that will make my life easier? Or something else? I'd love not to have to create dozens of new custom properties and just use the HubSpot ones, so if you need me to beta test them, I'm open to that! 😉

[BérangèreL]

Hi @Adam_W, no worries, you don't need to apologize! If you have questions, just ask, we all have questions 🤗

Plus, that's a great question, I am sure it will help many other Community Members!

To reply to your questions:

1. Regarding system properties
So, yes, the system properties cannot be viewed nor extracted at the moment.

They are only here to help with the system so that the system gets this data.

It doesn't necessarily means that they are for a new feature. But for sure, they are useful for the system.

Here is a post about it: "Unable to View Mysterious "System Property"".

For new feature suggestions, I'd recommend first to search and check if this idea is already present on our Ideas Forum here. If you find a similar idea, give it an upvote and share your unique use case in the comments.

If the idea doesn't exist already, please consider posting and creating a new Idea on our Ideas Forum here.

2. Regarding native properties
And you are right here also, the native default properties that were created by HubSpot cannot be deleted.

I hope that this brings clarification!

Have a great day!
Bérangère

[AllanFormigoni]

The biggest difference we've seen in some of our customers between using Services and Tickets for project management comes down to what kind of process we’re tracking:

• Tickets are still best for reactive, short-term work — things like support requests, troubleshooting, or anything that’s opened and closed quickly.
• Services are a better fit when we need to manage the delivery of a full project or engagement over time.

In our experience with our customers, those switching to Service records for project tracking ended up with way better visibility across their customer delivery work.

Let us know what you end up doing. Just curious about how you solve this. 

Allan @ Arrows

Sales rooms and onboarding plans for teams using HubSpot

[BérangèreL]

Hi @Adam_W, I hope that you are well!
 

Thank you for asking the HubSpot Community!

Have you tried with a calculated property? Would that work for you?

If you cannot, for new feature suggestions, I'd recommend first to search and check if this idea is already present on our Ideas Forum here. If you find a similar idea, give it an upvote and share your unique use case in the comments.

If the idea doesn't exist already, please consider posting and creating a new Idea on our Ideas Forum here.

Also, I'd love to ask our Top Experts: Hi @danmoyle, @00000 and @ScottPennwood do you have recommendations and tips to share with @Adam_W, please?

Have a lovely day and thanks so much in advance!

Kind Regards,
Bérangère

[Adam_W]

Hi @BérangèreL!

Thanks for the quick reply and suggestion. That would likely work, but it would require quite a bit of prep and maintenance as we prove out the process.

For example, in Ticket or Deal Pipelines, if you rename a stage or move it around, the underlying calculations of time spent in that stage remain. Using a custom property and then a calculated duration would break pretty easily (at least in my limited testing). We're still in the early stages of this, so there will definitely be a number of updates, tweaks, changes, etc., that will require these non-trivial edits. 

That said, I'm also not 100% sure of how to calculate accurately when a Service moves back and forth between stages repeatedly. Although that might be something I just need to dig a little more into!

Thanks again!

Adam

[ScottPennwood · Accepted solution]

Hi @Adam_W,

Of course you're absolutely right with regards to the changes - there's no magic happening in the background that does it all for you with what is essentially a (pre-defined) custom object. 

What I would say for this particular problem is that you should do whatever works best for you. If the Tickets object is fit for purpose for running your projects - it's your platform, you do you!

However the big thing to keep in mind are:

- Changes you make to the overall ticket pipeline/structure may have knock-on effects if you are using this in more "traditional" ways such as customer support/complaints. Be ultra-careful to ensure you don't break other processes!

- Even if you're not using your ticket pipeline in such a way, you may want to in the future so build for that.

There are tools available to enable you to do this (team-based views, separate pipeline, property access restriction etc) but you may run in to some areas where you'll need to make compromises (ticket creation, previews). 

Of course, all said my preference is to use the Services object and build in workflows + calculated properties to pull out the data I need so that I keep the business functions nice and separate in function, but still connected.