Step-by-step guide on how to create tickets in HubSpot

To create tickets in HubSpot, a company defines a service pipeline with clear statuses, decides which channels will open tickets automatically, assigns ownership and then lets customers, forms, emails or agents generate the records. The technical steps take minutes. The decisions that make tickets useful, such as what each status means and who answers for it, take longer and matter more.

Picture the service director of a health insurer on the first Monday after a storm season. Claims requests have tripled, and they are arriving by phone, email, the member portal and the broker network. Each team keeps its own spreadsheet, a few cases are answered twice, and a few are not answered at all. The chief executive asks a reasonable question about how many claims are open and how long they have been waiting, and the answer takes two days to assemble and is wrong by the time it arrives. The insurer does not lack effort or goodwill. It lacks a single place where a request becomes a record the moment it appears.

Creating tickets in HubSpot is the practical answer to that situation. Managing requests, complaints and issues in an organized way is essential for efficient customer service, and HubSpot provides a ticketing system that allows clear and structured tracking of every case. Properly built, it centralizes information, assigns responsibilities and maintains full traceability throughout the support process, which strengthens team collaboration and the customer experience. This guide takes the practical route, from the design decisions that come first to the configuration steps that follow, and it complements ICX's article on service tickets in HubSpot Service Hub, which explains why the discipline matters to the business.

What are HubSpot tickets and why are they used?

Tickets are all those requests, queries, complaints or procedures that a customer or a lead makes to a company. Their characteristics depend on the industry. In an insurer they are claims and policy changes, in a clinic they are appointment and billing requests, in a software company they are incidents and access problems. In HubSpot, tickets fulfill all of these functions, and their purpose is to manage the set of queries and requests that customers or leads address to the company.

HubSpot is a CRM with omnichannel features that helps companies centralize, within a single environment, every area of the business and every interaction that customers and prospects have with it. One of those areas is the service module, HubSpot Service Hub, and tickets are one of its principal tools.

HubSpot has a service request flow, the service pipeline, through which all the tickets the company receives are centralized. The ticket carries the contact information of the customer or lead who made the request. Once it is in the pipeline, it advances through stages and control rules that the company defines. The stages and rules can be modified in the ticket configuration to create limits that support the process and that govern how the service executive handles each ticket. The practical lesson is that the pipeline is a management instrument. It expresses the company's promise about how a request will be handled, and it makes any deviation from that promise visible.

How do you design the pipeline before creating the first ticket?

The most common mistake in service implementations is to open the settings and start clicking. The better sequence is to decide first what the pipeline should express. HubSpot ships with a default support pipeline that has four statuses, which are New, Waiting on contact, Waiting on us and Closed, according to HubSpot's documentation on setting up pipelines. It is a sound starting point for simple operations. A company with a more demanding process will need to adapt it, and the documentation describes how statuses are edited under Data Management in the object settings, how each status is marked as open or closed, and how properties can be made required when a ticket reaches a given status.

The ability to require information at a given status is one of the most valuable and least used controls. An insurer can require a claim number and a loss date before a ticket moves to assessment. A software company can require a severity level before an incident moves to engineering. A retailer can require the order number before a return is approved. The result is that data quality is built into the process and is not left to the memory of the agent at the end of a long shift.

Alongside the statuses, define what a ticket means for the company. Which kinds of requests deserve a ticket, and which can be answered in a single message? Who owns a ticket from the moment it arrives, and what happens if the owner is absent? What does closed mean, a resolved case, a case confirmed by the customer or simply a case that the team has stopped working? These questions sound administrative, but they determine the numbers management will see.

What are the ticket creation channels within HubSpot?

There are many ways in which tickets arrive in HubSpot to feed the service process of the team. The first is forms. When creating forms, HubSpot lets the company add properties of different kinds, according to the information the lead or customer should provide. The tool can therefore be adapted for service teams, and once the person completes the form, an automated process generates a ticket. A claims form that asks for the policy number, the date and a description gives the insurer a complete record from the first click.

The second is email. Every time an email arrives in the company's inbox, HubSpot allows the company to define the users to whom the conversation will be assigned and to indicate whether it corresponds to a ticket or not. The third is chatbots. HubSpot has several types of chatbot models, many of which include ticket generation in their programming, so that a conversation that begins as a question can end as a structured request with an owner. The fourth is the ticket pipeline itself. Users with the appropriate permissions and service access can create and manage tickets directly, and tickets can work not only for customers but also within the company, for example for requests between departments.

According to HubSpot's help desk documentation, tickets are created by default from the channels connected to the help desk, tickets can also be created manually, and the experience requires Service Hub Professional or Enterprise. Channels deserve a deliberate rollout. Connect one or two at a time, starting with those that carry the most volume, and confirm in each case that the ticket arrives with the right pipeline, status and priority.

How do you create a ticket in HubSpot, step by step?

Once the design is clear, the configuration is straightforward. The sequence below reflects the current HubSpot documentation and the practice of ICX implementation teams, and it applies to most Service Hub Professional and Enterprise portals.

1. Define the pipeline and statuses in the object settings for tickets, mark which statuses are open or closed, and set the properties that must be completed at each status.
2. Set the ticket defaults for pipeline, status and priority, so that tickets created by any channel start in a predictable place.
3. Connect the channels that will create tickets, beginning with forms and the shared email address, and confirm that a test submission creates a correctly populated ticket.
4. Create a ticket manually from the help desk by selecting the option to create a ticket, entering the subject and contact, and choosing the pipeline and status.
5. Add automation to the pipeline, such as tasks, internal notifications or status changes that fire when a customer replies, and then train the team on the working routine.

The fifth step deserves attention. HubSpot's documentation on automating ticket pipelines explains that a stage can trigger actions such as creating and assigning a task, sending an internal notification or editing a property, and that the ticket status can update automatically when the team emails the customer or when the customer replies on the ticket thread. Configuring these automations requires Super Admin or workflow edit permissions. The point for management is that automation removes the clerical work that most often causes tickets to age without anyone noticing, and that it should be introduced only after the manual routine is stable.

When a ticket is created by hand, the agent should treat the exercise as part of the same discipline. A manual ticket still needs the right owner, a clear subject that someone else could understand and the correct status. A team that creates tickets carelessly will produce a database that nobody trusts, and an untrusted database is worse than none, because it generates reports that mislead.

What does the ticket process look like in different industries?

The same sequence adapts to different realities. A network of private clinics receives requests for appointments, results and billing through the website, a call center and messaging. Each type of request has a different owner and a different expected response time, so the clinic creates a pipeline for administrative requests and a separate one for clinical follow-ups, and makes the patient identifier a required property. The medical director gains a view of how many follow-ups are pending after each consultation, which was impossible while they lived in individual inboxes.

A business software company handles incidents with severity levels. The pipeline includes statuses for triage, escalated to engineering and waiting on customer, and the severity property is required before escalation. The customer success leader can see which accounts have open critical incidents ahead of a renewal conversation, and the commercial team avoids the awkwardness of proposing an expansion to a customer whose problem has been open for three weeks.

An electricity or water utility uses tickets to manage service interruptions and billing disputes, which arrive in large waves. Forms and email are connected first, a priority property classifies the urgency, and automation notifies the operations supervisor when a critical ticket has been waiting beyond the agreed time. An online retailer uses the same logic for returns, requiring the order number and the reason for return so that the logistics and finance teams receive complete information. In each case the tickets are the same kind of object, and the design is what changes.

Which mistakes most often undermine a ticketing rollout?

Three mistakes appear again and again in service projects, and each is easy to avoid when it is named in advance. The first is copying the organization chart into the pipeline. When statuses are named after departments, such as legal review or finance, a ticket seems to disappear into a building and the customer receives no meaningful update. Statuses should describe the state of the request from the customer's point of view, and the department can be recorded as a property.

The second mistake is launching every channel at once. A team that must learn a new pipeline, new properties and five new sources of tickets in the same week will fall back on private spreadsheets within a month, and the project will be remembered as one more system that added work. Introducing channels in sequence allows the team to build confidence and gives management a chance to correct the design while the volume is still manageable.

The third mistake is treating the ticket as the end of the work. A ticket that is closed without analysis wastes its most valuable output, which is information about why customers needed to ask. Companies that review the most frequent causes of tickets every month, and take those causes to the product, billing or logistics teams, remove demand instead of merely serving it. That is where the efficiency promised by a ticketing system comes from, and it is a management routine, not a feature of the software.

What this means for the C-level

For the chief executive, the value of creating tickets properly is that customer problems become a managed asset. Instead of discovering through a lost account that a request was mishandled, leadership can see volume, age and cause every week, and can intervene when a pattern emerges. The decision to ask for that report is a leadership decision, and its absence usually signals that service is considered a cost to be minimized instead of a source of retention to be managed.

For the chief operating officer and the head of customer service, tickets define the operating rhythm. Targets for first response and resolution mean little unless the process records the times, and ownership means little unless each ticket has a named person. For the chief financial officer, the ticket database supports calculations of cost to serve by customer segment, channel and type of request, which in turn support decisions about self-service investments, outsourcing and staffing. And for the chief commercial officer, it is a reliable early-warning system: accounts with repeated or aging tickets are the accounts most likely to resist renewal, and the commercial team should see that signal in the account record.

How to start on Monday morning

A senior advisor would suggest starting small and measuring honestly. Choose the single request type that causes the most friction today, whether it is warranty claims, billing disputes or technical incidents, and build the pipeline for that type first. Define its statuses with the people who handle it, agree on what closed means, and connect one channel. Run it for two weeks with a small group, and review the results together: how many tickets were created, how long they took, where they stalled and what the team found awkward.

Use what you learn to refine the statuses and required properties before extending the model to other request types and channels. The ICX Define Activities and Processes Toolkit offers a structured way to document the service process before it is configured, so that the pipeline reflects how work is really done. Keep the reporting simple at the outset. Volume by channel, time to first response and time to resolution are enough to begin the management conversation, and richer analysis can follow once the data is reliable.

How ICX helps

ICX Consulting helps companies turn a ticketing configuration into a service capability. We work on customer experience consulting to define the service model and the moments that matter, on CX automation to route and escalate requests without manual effort, and on process improvement to remove the causes of repeat contacts. Our HubSpot consultants implement the design in Service Hub and prepare the team to run it.

Are your customers' requests recorded the first time they arrive? Request a diagnostic with an ICX consultant about your HubSpot ticketing setup, and we will show you where the gaps are and what to build first.

Frequently asked questions

How long does it take to set up ticketing in HubSpot?

The basic configuration of a pipeline and one channel can be done in a day. A reliable service process usually takes several weeks, because the time goes into agreeing on statuses, owners and definitions with the teams that will use them. Plan the project around those decisions and not around the settings screens.

Should every customer message become a ticket?

No. A ticket is justified when a request needs an owner, a status and a record of resolution. Simple questions answered in a single message can remain as conversations. Creating tickets for everything inflates volume and obscures the cases that matter, so define a clear rule for what qualifies.

Can tickets move automatically between statuses?

Yes, within limits. HubSpot's documentation explains that status can change automatically when the team emails the customer from the ticket or when the customer replies on the ticket thread, and that stages can trigger tasks and notifications. Automation requires the right permissions and subscription, so confirm both before designing around it.

What should be measured first once tickets are running?

Start with ticket volume by channel, time to first response and time to resolution, plus the share of tickets that reopen. These four measures reveal where the process is slow, which channels carry the load and whether problems are really being resolved. Add satisfaction and cost to serve once the basic data is trusted.

A request recorded properly the first time is the cheapest service a company can offer, and it is also the one customers remember. ICX is ready to help your leadership team design the process that makes it routine.