I am currently reviewing the service feature, and i have a bit of a hard time to understand the value it is providing.
I have a potential use case, that we are currently handling with tickets in Hubspot, and I wonder if moving this process to a Service might bring benefits or not. Has anyone implemented a successful Service and what are the positive aspects of using this object V a ticket for example?
@TMessi the service and the ticket object behave in a very similar way, both have a pipeline logic to it, both are be default sortable by category.
The main difference is that the service object comes with properties like 'Amount paid', 'Amount remaining', 'Total cost', 'Start date' and 'Target end date' etc – so there's a price / billing component that the ticket object does not have (out of the box, but which can be easily added as custom properties).
In other words, if you have an existing process set up on the ticket object, I would probably not migrate it to the services object – unless you think the 'Ticket' name is misleading and think 'Services' is better suited.
Best regards!
Karsten Köhler HubSpot Freelancer | RevOps & CRM Consultant | Community Hall of Famer
So I am rereading my post and my title, and it looks like I forgot some words and use incorrect ones, my bad.
So to go from the start :
I am reviewing the service Object feature (not Hubspot Service) and I still do not know what would be the benefits of using it, VS the other Objects.
My use case is : we are offering a CAD file support for our platform (when customers are not able to create and provide their own files), and currently we are using a form and a ticket pipeline to handle those requests. My first thought was that this service we are providing to our customers, sounds like a case for the Service object. But at the end, which value would it provide to manage our process with a Service Object V the current set up we have?
@TMessi the service and the ticket object behave in a very similar way, both have a pipeline logic to it, both are be default sortable by category.
The main difference is that the service object comes with properties like 'Amount paid', 'Amount remaining', 'Total cost', 'Start date' and 'Target end date' etc – so there's a price / billing component that the ticket object does not have (out of the box, but which can be easily added as custom properties).
In other words, if you have an existing process set up on the ticket object, I would probably not migrate it to the services object – unless you think the 'Ticket' name is misleading and think 'Services' is better suited.
Best regards!
Karsten Köhler HubSpot Freelancer | RevOps & CRM Consultant | Community Hall of Famer
Yes that is also a benefit that I see, since we have moved to Helpdesk too. But the effort of moving our current tickets processes are gigantic too 😄 and the risk high .. thanks for the input!
Could you describe your use case in a bit more detail? The broad answer would be: yes, the service hub with its helpdesk and ticket records is very useful for managing incoming request from customers, reporting on it, and potentially also manage other after-sales processes.
The service hub in HubSpot revolves around the ticket object. (Main objects in HubSpot are contacts, companies, deals, tickets. In other words, there is no distinction between object and ticket. The ticket is an object type.)
Best regards
Karsten Köhler HubSpot Freelancer | RevOps & CRM Consultant | Community Hall of Famer