Gorgias Chat Setup for Shopify: Step by Step

What does Gorgias chat actually do on a Shopify store?

Gorgias chat is a live chat widget that sits on your Shopify storefront and feeds every conversation into the Gorgias helpdesk as a ticket. That last part is the point. A chat is not a separate inbox with its own history. It is a ticket with a different channel label, which means your rules, tags, macros and reporting apply to it the same way they apply to email.

Most guides for gorgias chat stop at “paste the snippet, pick a colour.” The widget takes ten minutes. What takes the time, and what decides whether chat helps or quietly hurts your service, is what happens after a customer types the first message. Who sees it, when, and what the customer experiences if nobody answers.

This article is the setup order for a Shopify store, written for operators at roughly $3M–$30M in revenue on Shopify Plus or a paid subscription platform. It is not for a store still deciding whether to offer chat at all, and it is not for brands with no helpdesk. If you are choosing between chat tools, read our guide to Shopify live chat first, and if you are weighing Gorgias itself, read Gorgias alternatives.

One caution before the steps. Gorgias changes plan names, limits and interface labels, and I am not going to quote any of them. Where a setting has a name, I give the name it has carried for a long time and tell you to confirm it in the current admin. Where a value depends on your store, I give you the method to find it.

What you need before you start

You need an admin login for both Shopify and Gorgias, a decision on who owns chat during business hours, and a decision on who owns it outside them. That last one is the input almost everyone lacks. If you cannot name a person or a queue that reads after-hours chats the next morning, stop and settle that first. The setup that follows assumes you have an answer.

You also need a working Shopify customer record to test with: one real order, placed from an email address you control. Testing chat without a matched order tells you nothing about the part that matters, which is whether agents can see what the customer bought.

How do you set up Gorgias chat on Shopify, step by step?

The order of these five steps is deliberate. Each step depends on the one before it, and reversing steps 1 and 2 is the most common cause of a launch that looks fine and answers badly.

1. Connect Shopify before you touch the chat widget

Connect the Shopify store to Gorgias first, and confirm the connection with an order before you create any chat. The Shopify integration is what lets an agent see the customer’s orders, addresses and fulfilment status in the ticket sidebar. A chat widget installed before that connection works, but every conversation opens with the agent asking “what’s your order number?”, which is the question chat exists to avoid.

After connecting, place a test order from an email address you own. Open a test chat later using that same address and check that the order appears next to the conversation. If it does not, the customer match has failed, and nothing you configure later will fix it.

Two things commonly break this. The first is a store with multiple Shopify markets or storefronts: check that each one is connected and that the chat you install lives on the storefront you tested. The second is a customer who chats before giving an email address. The match depends on an identifier, so the widget has to ask for one, which is handled in step 3.

2. Set business hours and the offline behaviour

Enter your business hours in the time zone your support team actually works in, then decide what the widget does outside them. The setting is labelled around business hours and offline behaviour in the chat configuration; confirm the exact wording in your admin. This is the step teams rush, and it is where the customer’s first impression is decided.

There are three offline behaviours worth choosing between:

Take from the table that the second row is the only one that is both honest and useful. Hiding the widget is safe but wasteful. Showing it as if live is the failure mode, and it happens by default whenever hours are left unset.

The offline message needs a promise you can keep. Write the reply window as a statement of your actual practice, such as “we reply the next working day”, not an aspiration. A reply window is a commitment your team will be measured against by the customer, so set it from the slowest morning you have, not the best one. If you do not know how long your overnight backlog takes to clear, that is a metric to confirm: pull a fortnight of after-hours tickets and measure the gap between arrival and first reply.

Public holidays deserve their own line. If the platform lets you add holiday closures, add the ones you observe. If you skip it, the widget will greet customers as live on a day nobody is there.

3. Configure the widget: position, greeting, and the first question

Set the position, greeting and first prompt so the widget helps a buyer rather than blocking them. Three decisions, each with a reason.

Position first. The default corner often collides with something. On many Shopify themes that means a sticky add-to-cart bar on mobile, a cookie banner, or another app’s widget. Open your product page on a phone, scroll, and watch what the chat bubble covers. If it sits on the buy button, move it or hide it on that template. A chat bubble that costs you an add-to-cart is a bad trade for any store.

Greeting second. State what the chat can help with, in one sentence, in the customer’s vocabulary: “Ask about sizing, delivery or an existing order.” A generic “Hi! How can we help?” invites every question, including the ones you would rather handle by email. A narrower greeting is not less friendly; it filters the volume you take.

Then the first question. Ask for the email address early, in the first exchange, and say why: “So we can follow up if we get cut off.” This one line does more for the handoff (step 5) than any rule you will write later, because an email address is what lets an agent reach the customer after the chat window closes. It is also what makes the Shopify order match in step 1 work.

Decide which pages get the widget. Product and cart pages cover pre-purchase questions. Order-status and account pages cover post-purchase ones. Checkout is a different matter: Shopify restricts what can run there, and on Shopify Plus it runs through checkout extensibility rather than theme code. Confirm what your plan permits before promising checkout coverage to anyone.

4. Route chats into tickets with rules

Write rules so a chat ticket is tagged, prioritised and assigned the same way an email ticket would be. Because a chat is a ticket, the rules engine sees it. Use that. A store that treats chat as a separate world ends up with two sets of routing logic that drift.

Start with three rules and stop:

1. Tag by intent. Match on the opening message for words like “where is my order”, “refund”, “size” or “cancel” and apply a tag. Keep the keyword list short and review it monthly, because a long list of loose matches tags everything as something.
2. Assign by tag. Order-status and pre-sale tags go to the general queue. Refund and dispute tags go to a named person. Nothing involving money moves without a human reading it.
3. Flag the after-hours arrivals. Any chat created outside business hours gets a tag such as after-hours and lands in a view the morning shift opens first. This rule is the whole answer to the orphan problem in step 5.

Resist writing a fourth rule until the first three have run for a fortnight. New rules are cheap to write and expensive to debug, and rule collisions are the most common reason a ticket lands in the wrong queue. For a wider view of what to automate in a helpdesk and what to leave alone, see helpdesk automation tools, and for how the helpdesk fits a Shopify store, see helpdesk for Shopify.

5. Test the handoff the way a customer would break it

Run three test conversations that deliberately fail, and record where each one ends up. This is the step most teams get wrong, because it is the one nobody sees until a customer complains.

Test one: chat during business hours, then leave. Open the widget on your store, send a question using your test email, and close the tab before an agent answers. Now reply as an agent. Where does your reply go? If the customer gave an email address, check whether the reply reaches that inbox. If they did not, note what happens: an agent typing into a chat the customer has left is typing to nobody.

Test two: chat after hours. Change the hours temporarily or wait until the store is closed. Send a message through the offline form. Confirm that a ticket is created, that it carries the after-hours tag from the routing rules, and that it appears in the morning view. Then check the auto-reply text the customer received against the reply window you promised in step 2.

Test three: chat, get an answer, come back. Chat in the morning, close the tab, open it again in the afternoon. Does the customer see the earlier conversation or a blank widget? A customer who has to repeat themselves will not tell you; they will just leave.

The failure I see most is not a broken feature. It is a chat that works in the demo, where the tester stays in the tab, and fails in production, where customers leave. A ticket that exists in the helpdesk but that the customer will never read a reply to is worse than no ticket, because your dashboards count it as handled.

If you find an orphan, the fix is almost always upstream: ask for the email earlier (step 3), or make the offline form require one (step 2). Do not patch it with more rules.

What goes wrong with Gorgias chat once volume grows?

Volume exposes four problems that a quiet launch hides. None of them is a fault in the tool; each is a decision left unmade.

Chat competes with email for the same agents. A chat wants an answer in minutes, an email can wait. If one person is expected to watch both, chat wins the attention and the email queue ages. Decide up front whether chat has dedicated cover during its hours. If it does not, shorten the hours the widget is live rather than staffing thinly across long ones.

Proactive campaigns create volume you did not plan for. Gorgias lets you trigger chat messages on certain pages or behaviours. Each one is a small experiment in how many conversations you can afford. Turn one on at a time, watch the queue for a week, and only then add another. Before launch, check whether chat conversations count toward your plan’s ticket allowance, because a campaign that doubles chats may double a metered cost.

The same question gets answered by hand forever. Chat is a fast way to discover which questions repeat. Every time an agent types the same answer three times, that is a candidate for a saved reply or a self-service link. Review the top tags monthly and convert the top few into content the customer can reach without a human.

Order data is wrong, and chat exposes it faster than email. A customer asking “where is my parcel?” in a live chat expects an answer in the next minute. If the tracking data in Shopify is stale, or your carrier statuses lag, the agent reads out a wrong answer at speed. That is a data problem showing up as a service problem, and no chat setting fixes it.

When should you automate Gorgias chat answers?

Automate only the questions where a wrong answer is cheap and the data is reliable. Order status and delivery-window lookups qualify if your fulfilment data is clean. Policy questions such as returns windows qualify if the policy is written down and current.

Do not automate refunds, cancellations, or anything involving a payment without a human in the loop. A wrong automated answer to “can I return this?” costs a support conversation; a wrong automated refund costs money and trust. Also skip automation entirely where the underlying data is unreliable: an automated reply is a confident statement, and confident wrong answers are worse than slow correct ones.

For the wider picture of where AI belongs in a support operation, customer service automation sets out the split between what a rule can do and what needs a person.

How do you verify that Gorgias chat is working after launch?

Verify with the three handoff tests, repeated after any change to hours, rules or the widget, plus a weekly look at three views. This is a short routine; the value is in doing it every time.

The views to open weekly:

• After-hours chats with no reply. Sort by age. Anything older than the promise you made in step 2 is a broken commitment.
• Chats with no email address. If a growing share of conversations arrive without one, your first-question prompt is not working, and your orphan rate is rising.
• Chats tagged refund or dispute. Confirm each was read by a human and not closed by a rule.

Measure the outcome in your own numbers. Track first-reply time for chat separately from email, and the share of chats that needed a follow-up by email. Both are metric to confirm items for your store, because published averages describe other people’s catalogues and staffing. Gorgias publishes case studies with customer results; treat those as vendor-reported and use them for ideas, not as a benchmark.

If chat volume is small enough that the whole exercise feels like too much process, that is a real finding. For some stores the right answer is a well-organised email queue and a good returns page. Chat earns its place when a meaningful share of buyers ask a question just before purchase and leave if they do not get an answer.

Who should not set up Gorgias chat?

Skip it if nobody can own the queue during the hours the widget is live. A chat widget with no owner is worse than no widget, because it makes a promise the store cannot keep. Skip it if your product is simple enough that questions rarely block a purchase. And skip it if you are under the revenue floor where a helpdesk cannot pay for itself; a shared inbox is honest at that size.

Gorgias chat is also a poor fit if you have already standardised on another helpdesk and only want a chat bubble. Splitting history across two tools costs more than it saves. In that case compare against your existing tool’s own chat before adding a second system.

Chat is a customer service AI problem, not a widget problem

Setting up Gorgias chat is the easy part. The larger part is deciding what a machine may answer, what a person must read, where data has to be right before either of them speaks, and who owns the queue at 2am. That is the customer service AI problem in miniature, and it is the one Pointerflow builds and runs for scaling brands: customer service automation covers routing, saved answers and the guardrails around them for stores in the scaling brands bracket.