Most PrestaShop merchants run support out of a shared Gmail inbox and don't realise that PrestaShop already ships a help desk, a real one, with threaded conversations tied to customer and order records, sitting unused in the back office. The problem isn't that you lack a tool. It's that the native tool stops short exactly where a growing store starts to hurt: limited statuses, no priorities, no SLA timers, no canned replies, and a contact form most merchants never finish wiring up. This guide is about building a help desk inside your store, first by switching on what's already there, then knowing precisely when and how to outgrow it, so support conversations carry order context instead of starting from "what's your order number?" every time.
Last updated: June 2026.
This is the operational, in-store side of customer support. The conversational channels that feed it, live chat, WhatsApp, Messenger, each get their own treatment, and we link to them where they belong rather than re-explaining them here.
The help desk PrestaShop already gives you
Open your back office and go to Customer Service → Customer Service. That's the native help desk, driven by the AdminCustomerThreads controller. Every message a customer sends through your store's contact form becomes a CustomerThread, and each reply is a CustomerMessage attached to it. PrestaShop is doing more here than most merchants realise: if the sender is a logged-in customer (or their email matches an account), the thread is linked to that customer, and if they reference an order, it's linked to the order too. Open a thread and you see who they are, what they bought, and the whole back-and-forth in one place.
The feed for all of this is the Contact form, served by the ContactController at /contact-us. Under Customer Service → Contacts you define your contact departments, Customer service, Webmaster, or whatever you add, and each can point at a different email address. Pick "Customer service" and PrestaShop logs the message as a thread; pick a department flagged otherwise and it can simply forward by email. That department dropdown on the contact form is the native equivalent of "route this to the right team."
So what does that buy you? Three things you're probably paying a third-party tool for already: every inquiry captured in one queue instead of scattered across personal inboxes; customer and order context attached automatically, so an agent answers without interrogating the customer first; and a record that survives when an employee leaves with their mailbox. For a store doing a handful of inquiries a day, turning this on, and actually pointing your "Contact us" link at it, is a genuine upgrade over a shared inbox, at zero cost.
Where the native help desk runs out of road
The native customer-service thread system was built to be sufficient, not complete. The gaps are predictable, and they all show up at the same moment: when support volume crosses the line from "I read every message" to "I need a system so nothing slips."
| What you need | Native PrestaShop | What that costs you at volume |
|---|---|---|
| Ticket statuses (open / pending / closed) | Open, Closed and two generic "Pending" states, plus a "handled by" assignment | The Pending states are unlabeled, so there's no clear way to tell what's waiting on the customer from what's waiting on you |
| Priority levels | None | A 14-day-late delivery sits in the same flat list as a sizing question |
| Canned / saved replies | None | Agents retype the same shipping answer twenty times a day |
| Internal notes / agent-to-agent | None. Every message is customer-facing | No clean handoff; escalation context lives in someone's head |
| Response-time / SLA tracking | None | You can't prove or improve first-response time |
| File attachments from customers | Limited / configuration-dependent | "Send me a photo of the damage" becomes a separate email thread |
| Email-to-ticket (reply by email lands in the queue) | Not in core | Customer replies to the notification, it goes to a mailbox, context is lost |
None of these is a flaw in PrestaShop, they're simply the difference between a message log and a help desk. The honest decision framework is volume-based: under roughly a dozen tickets a day, native plus a tidy /contact-us page is fine, and adding software is over-engineering. Past that, the missing pieces start costing real time and real customers, and a purpose-built layer pays for itself.
Turning the native thread system into a real ticketing help desk
When you outgrow native, you have the usual three routes: rebuild it with a developer (total control, ongoing cost, and it tends to break at the next major upgrade), bolt on an external help-desk SaaS (powerful, but now support lives outside your store and loses the order context that made the native version worth keeping), or add a module that extends the same in-store model you already have.
The reason we built Support Revolution is that third option. Keeping support inside PrestaShop so it keeps the customer and order context, while adding the operational layer native is missing. It gives each inquiry a tracked ticket with real statuses, threaded conversations, department routing so a question reaches the right team instead of one shared queue, priority levels so the late delivery jumps ahead of the sizing question, file attachments so a customer can send a photo of the damaged item in-thread, and email notifications that keep both sides moving without anyone refreshing the back office. It works for guests as well as registered customers, and there's optional IMAP email-to-ticket, so a customer who just hits reply on the notification email has their answer land back in the right ticket instead of a dead-end mailbox.
So what's the practical difference on a busy day? Tickets stop falling through the cracks because every one has a status someone owns; agents stop retyping the same answers; the urgent ones surface instead of drowning; and because it runs in your back office on PrestaShop 1.7, 8 and 9, support data stays next to the orders it's about rather than in a separate SaaS dashboard you pay for monthly. The "So what?" for the owner: you can finally measure first-response and resolution time, and fix the queue instead of just emptying it.
Each ticket carries its status, priority and the order it's about. Which is the context an external SaaS throws away.
Deflect before you support: self-service inside the store
The cheapest ticket is the one a customer answers themselves. Before scaling the help desk, scale the things that stop questions reaching it, and PrestaShop gives you most of the hooks for this already.
- Order tracking in the account area. "Where is my order?" is the single most common inquiry, and it's almost entirely self-serviceable. The customer's Order history & details page (the history and OrderDetail controllers) already shows status and, if you've entered a tracking number on the order, a tracking link. Make sure carriers have a URL with the
@placeholder set under Shipping → Carriers so the tracking number becomes a live link, that one setting deletes a whole category of tickets. - A real FAQ that covers the 20 questions behind 80% of volume. Shipping times, returns, sizing, payment methods, order tracking, answered once, findable always. A static CMS page works; a structured, searchable FAQ works better. An Issue Tracker for known-issue notes with status tracking, paired with a structured FAQ manager, turns those answers into a tab right on the product page, so the answer sits where the question forms.
- Product pages that pre-empt the question. Accurate sizing charts, compatibility notes and clear photos answer pre-purchase questions before they become tickets. Every question resolved on the product page is a ticket that never existed.
Self-service isn't a substitute for support. It's what keeps the help desk small enough to be excellent.
The conversational channels that feed the desk
A ticket queue answers questions thoroughly; live chat and messaging answer them now. The two aren't rivals. Chat catches the pre-sale "does this fit?" moment, the help desk handles anything that needs a record or a follow-up. Rather than re-explain each channel here, this is where they live in the cluster:
- Whether live chat actually moves the numbers, before you add another widget: does live chat actually increase sales.
- Choosing a free chat tool: Tawk.to vs Tidio vs Crisp compared, and the broader WhatsApp vs Messenger vs Tawk.to face-off.
- Meeting customers on the apps they already use: WhatsApp chat for PrestaShop (and the hands-on setup and best practices), or Messenger chat: pros, cons and setup.
And when a support conversation ends well, it shouldn't go cold. The same customer is your best candidate for a post-purchase email sequence, and a lapsed one for a win-back campaign. Support and retention are the same relationship viewed at different moments.
Measuring whether your help desk is working
You can't improve what native PrestaShop won't let you see. Which is precisely why the metrics below are the strongest argument for a real ticketing layer. Once tickets carry statuses and timestamps, track four numbers:
- First-response time, how long until a human replies. A common service target is a few hours within business hours; what matters is that it trends down, not the exact threshold.
- Resolution time, open to closed, for standard inquiries.
- First-contact resolution rate, the share solved without a second round-trip. This is where order context pays off, because the agent isn't asking for information the system already holds.
- Ticket topic distribution, and this is the one that actually saves money. If a third of your tickets are the same question, that's not a support problem, it's a missing FAQ entry, an unclear returns page, or a product description gap. Fix the root cause and the tickets stop arriving.
Review the topic mix monthly. The goal of a good help desk isn't to handle more tickets faster forever. It's to make each category of ticket smaller by fixing what causes it, so your queue shrinks even as your order count grows.
Support is a cost centre that quietly protects revenue: every well-handled inquiry preserves a customer whose lifetime value dwarfs the cost of answering well, and every dropped one risks a bad review or a chargeback. The PrestaShop-specific takeaway is that you don't start from zero, you already own a context-aware thread system in Customer Service → Customer Service. Switch it on, point your contact page at it, deflect the predictable questions with self-service, and add a ticketing layer like Support Revolution the moment volume turns "I read every message" into "I need a system." Keep it inside the store, and support keeps the one thing an external tool throws away: the order it's about.
In-store help desk FAQ
Does PrestaShop already have a help desk? Yes, Customer Service → Customer Service, driven by the AdminCustomerThreads controller. Messages sent through your contact form become threads tied to the customer and, where referenced, the order. Most merchants never point their "Contact us" link at it and run a shared Gmail inbox instead. For a handful of inquiries a day, just switching it on is a real upgrade at zero cost.
When should I move beyond the native customer-service threads? Roughly when volume crosses from "I read every message" to "I need a system so nothing slips", about a dozen tickets a day. Below that, native plus a tidy /contact-us page is enough and adding software is over-engineering. Past it, the missing pieces (priorities, SLA timers, canned replies, internal notes, email-to-ticket) start costing real time and customers.
What does native PrestaShop's support not do? No priority levels, no saved replies, no agent-only internal notes, no response-time/SLA tracking, limited customer attachments, and no reply-by-email landing back in the queue. Its two "Pending" states are unlabeled, so you can't tell what's waiting on the customer from what's waiting on you.
Why keep support inside PrestaShop instead of using a SaaS help desk? Because the in-store thread system links each conversation to the customer and the order automatically. Move support to an external SaaS and you gain features but lose that order context. The agent is back to asking "what's your order number?". A module that extends the native model keeps the context and adds the operational layer.
How do I cut ticket volume without hiring? Deflect with self-service: working order tracking (set the carrier URL with the @ placeholder under Shipping → Carriers so tracking numbers become live links), a real FAQ covering the 20 questions behind 80% of volume, and product pages that pre-empt questions with accurate sizing and clear photos. Then review your ticket-topic mix monthly and fix the root cause of the biggest category.
Related reading
- Support Revolution. Adds statuses, priorities, departments, attachments and IMAP email-to-ticket, all inside your back office.
- Issue Tracker and FAQ manager, deflect questions before they reach the desk.
- Does live chat actually increase sales, the real-time channel that feeds the queue.
