How to Set Up a Support Ticket System Inside Magento 2

You can run a full support ticket system inside Magento 2 itself: customers open and track tickets from their account, your team answers from the admin, and every ticket carries the product context from the customer's actual order history. That is what the OCM Labs Support Tickets module for Magento 2 does, and since we build and sell it, this walkthrough doubles as its setup guide. Total setup time is about half an hour, and most of that is deciding which inbox gets the notifications.

If you are still weighing whether a built-in ticket system beats a contact form or an external helpdesk, we made that comparison separately in contact form vs extension vs Zendesk. This post assumes you have picked the built-in route and want it live.

What do you need before you start?

Four things:

• Magento Open Source or Adobe Commerce 2.4.7 or 2.4.8 (2.4.9 is not yet supported)
• PHP 8.3 or higher
• Command line access to run bin/magento
• An email address for admin notifications, ideally a shared inbox or distribution list rather than one person's mailbox

The module is $250, works on Luma natively, and has a companion package for Hyva stores.

How do you install the Support Tickets module?

One Composer package, standard Magento install:

composer require ocmlabs/module-support-ticket
bin/magento module:enable OCMLabs_SupportTicket
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

Adobe Commerce stores install ocmlabs/module-support-ticket-commerce instead; the bin/magento steps are the same. Hyva stores add ocmlabs/module-support-ticket-hyva alongside the core module.

Once it is in, you will see Support Tickets under Stores > Support in the admin, and logged-in customers get a My Support Tickets link in their account navigation. Admin access is ACL-controlled with separate permissions for viewing, managing, deleting, and configuring, so you can give support staff the ticket queue without giving them store configuration.

Which settings matter before going live?

Configuration lives at Stores > Configuration > OrangeCollar > Support Tickets, and there are only three settings that decide whether the system works on day one:

1. Enable Support Tickets. The master switch. Off hides the customer portal and the product page Support button, and rejects new submissions.
2. Admin Notification Email. The address that receives every new-ticket and new-reply alert. This one is the trap: it ships empty, and a blank value means admin notifications are silently skipped. Set it before launch. For multiple staff, point it at a distribution list.
3. Email Sender. Which Magento email identity (General Contact, Customer Support, and so on) appears as the From address on ticket emails.

Below those sit five email template selectors, one for each notification the module sends. The shipped defaults are fine to launch with; if you want branded versions, build them under Marketing > Communications > Email Templates and select them here. All five templates share the same variable set (ticket_id, ticket_subject, ticket_status, customer_name, product_name, comment_message, view_url, and friends), and the full list is in the system settings reference.

Everything is store-view scoped, so a multi-store setup can route each brand's tickets to a different inbox with its own sender identity. After changing settings, flush the config cache (bin/magento cache:flush config).

What do customers see?

A support portal inside the account area they already use. From My Support Tickets, a customer sees every ticket they have opened on the current store view, with status and last-updated info, and a Create Ticket button.

The create form asks for a subject, a message, an optional category (Billing, Shipping, Product Issue, General, Other), an optional priority (defaults to Medium), and optionally a related product. That last field is the quiet differentiator: the product dropdown is populated from the customer's actual order history, and the backend rejects any submission for a product they never bought. No anonymous drive-by tickets, no "which product do you even own" round trip.

There is also a Support button on every product page. A logged-in customer who owns the product gets the create form with that product pre-selected; a visitor who is not logged in is routed through login first. It is a one-click path from "this thing I bought has a problem" to a ticket your team can act on.

After submitting, the customer can follow the whole conversation on the ticket view page, reply, and mark their own ticket resolved when they are satisfied. If they reply to a resolved ticket, it reopens automatically.

What does your support team see?

A ticket grid at Stores > Support > Support Tickets covering every store view, with columns for ID, subject, customer, product, status, priority, category, and timestamps. Every column filters, so the daily queue is one saved filter away: status Open, sorted oldest first. If different people handle Billing and Shipping, bookmark a filtered view per category.

Opening a ticket shows the details block (subject, status, priority, and category are all editable; the customer name links to their account page in a new tab) above the full conversation thread. Replying is a text box at the bottom: type, submit, and the customer gets an email. Bulk actions on the grid handle triage, with Set Status applying a status to every checked ticket at once.

One workflow habit worth keeping: do not delete tickets to clean the queue. Deletion permanently removes the conversation thread; setting the ticket to Resolved keeps the history and drops it from the active queue just the same.

How do ticket statuses move?

Mostly by themselves, based on who replied last:

The result is a status column that tells you who owes the next move: Open means you do, Pending means the customer does, In Progress means it is being handled. Nobody bookkeeps this manually, though admins can override any status from the edit page. The exact transition rules are documented in the status workflow page.

What emails go out, and when?

Five, automatically:

1. Ticket created: confirmation to the customer
2. Ticket created: alert to your admin notification address
3. Admin replied: notification to the customer
4. Customer replied: notification to your admin address
5. Ticket resolved: confirmation to the customer

Emails go through Magento's standard transport, so they respect whatever SMTP setup your store already uses. Manual status changes from the admin do not fire emails on their own; only replies and the resolve action do, which keeps triage from spamming customers.

That is the whole system: install, set the notification address, and your store has a working helpdesk with purchase-verified product context on every ticket. The OCM Labs Support Tickets module page has the current version details, we compare it against the big commercial alternative in OCM Support Tickets vs Mirasvit Helpdesk, and the rest of our modules live on the Magento extensions page.