Celery just released their API on Github, currently in beta. Here are some of the cool stuff you can do with it in Gorgias.

‍

Display customer information

When you receive an email from a customer, you can connect your Celery account and see customer information (orders, shipping address, etc.). Here’s what it looks like:

‍

To configure it, grab your Celery access_token, head to integrations, and add an HTTP integration using this URL:
https://api.trycelery.com/v2/orders?buyer.email={ticket.requester.email}

‍

Then you can customize the sidebar to only show the Celery data you need to respond to customers. Click the cog and simply drag and drop elements you want to show.

‍

Refunds, order change... without leaving tickets

Celery’s API enables you to perform a few actions from your favorite helpdesk:

• Edit an order
• Cancel an order
• Issue a refund
• Create a coupon

‍

Here’s an example of how you can cancel an order from Gorgias itself. Say you already have a macro to cancel an order. Add an HTTP action to it, in this case:
https://api.trycelery.com/v2/orders/{ticket.requester.customer.data[0].number}/order_cancel

‍

Then, when you use this macro and send it to the customer, it will automatically cancel the last order at the same time:

‍

We hope this integration with Celery can save you time. If you'd like to try Celery with Gorgias, shoot us a note! At support@gorgias.com.

TLDR: https://github.com/xarg/pghoard-k8s

‍

This is a small tutorial on how to do incremental backups using pghoard for your PostgreSQL (I assume you’re running everything in Kubernetes). This is intended to help people to get started faster and not waste time finding the right dependencies, etc..

‍

pghoard is a PostgreSQL backup daemon that incrementally backups your files on a object storage (S3, Google Cloud Storage, etc..).
For this tutorial what we’re trying to achieve is to upload our PostgreSQL to S3.

‍

First, let’s create our docker image (we’re using the alpine:3.4 image cause it’s small):

FROM alpine:3.4

ENV REPLICA_USER "replica"
ENV REPLICA_PASSWORD "replica"

RUN apk add --no-cache \
   bash \
   build-base \        
   python3 \
   python3-dev \
   ca-certificates \
   postgresql \
   postgresql-dev \
   libffi-dev \
   snappy-dev
RUN python3 -m ensurepip && \
   rm -r /usr/lib/python*/ensurepip && \
   pip3 install --upgrade pip setuptools && \
   rm -r /root/.cache && \
   pip3 install boto pghoard


COPY pghoard.json /pghoard.json.template
COPY pghoard.sh /

CMD /pghoard.sh

‍

‍

REPLICA_USER and REPLICA_PASSWORD env vars will be replaced later in your Kubernetes conf by whatever your config is in production, I use those values to test locally using docker-compose.

‍

The config pghoard.json which tells where to get your data from and where to upload it and how:

‍

{
   "backup_location": "/data",
   "backup_sites": {
       "default": {
           "active_backup_mode": "pg_receivexlog",
           "basebackup_count": 2,
           "basebackup_interval_hours": 24,
           "nodes": [
               {
                   "host": "YOUR-PG-HOST",
                   "port": 5432,
                   "user": "replica",
                   "password": "replica",
                   "application_name": "pghoard"
               }
           ],
           "object_storage": {
               "aws_access_key_id": "REPLACE",
               "aws_secret_access_key": "REPLACE",
               "bucket_name": "REPLACE",
               "region": "us-east-1",
               "storage_type": "s3"
           },
           "pg_bin_directory": "/usr/bin"
       }
   },
   "http_address": "127.0.0.1",
   "http_port": 16000,
   "log_level": "INFO",
   "syslog": false,
   "syslog_address": "/dev/log",
   "syslog_facility": "local2"
}

‍

Obviously replace the values above with your own. And read pghoard docs for more config explanation.

‍

Note: Make sure you have enough space in your /data; use a Google Persistent Volume if you DB is very big.

‍

Launch script which does 2 things:

1. Replaces our ENV variables with the right username and password for our replication (make sure you have enough connections for your replica user)
2. Launches the pghoard daemon.

‍

‍

#!/usr/bin/env bash

set -e

if [ -n "$TESTING" ]; then
   echo "Not running backup when testing"
   exit 0
fi

cat /pghoard.json.template | sed "s/\"password\": \"replica\"/\"password\": \"${REPLICA_PASSWORD}\"/" | sed "s/\"user\": \"replica\"/\"password\": \"${REPLICA_USER}\"/" > /pghoard.json
pghoard --config /pghoard.json

‍

Once you build and upload your image to gcr.io you’ll need a replication controller to start your pghoard daemon pod:

‍

apiVersion: v1
kind: ReplicationController
metadata:
 name: pghoard
spec:
 replicas: 1
 selector:
   app: pghoard
 template:
   metadata:
     labels:
       app: pghoard
   spec:
       containers:
       - name: pghoard
         env:
           - name: REPLICA_USER
             value: "replicant"
           - name: REPLICA_PASSWORD
             value: "The tortoise lays on its back, its belly baking in the hot sun, beating its legs trying to turn itself over. But it can't. Not with out your help. But you're not helping."
         image: gcr.io/your-project/pghoard:latest

‍

The reason I use a replication controller is because I want the pod to restart if it fails, if a simple pod is used it will stay dead and you’ll not have backups.

‍

Future to do:

• Monitoring (are you backups actually done? if not, do you receive a notification?)
• Stats collection.
• Encryption of backups locally and then uploaded to the cloud (this is supported by pghoard).

Hope it helps, stay safe and sleep well at night.

‍

Again, repo with the above: https://github.com/xarg/pghoard-k8s

At Gorgias we recently switched our flask & celery apps from Google Cloud VMs provisioned with Fabric to using docker with kubernetes (k8s). This is a post about our experience doing this.

‍

Note: I'm assuming that you're somewhat familiar with Docker.

‍

Docker structure

The killer feature of Docker for us is that it allows us to make layered binary images of our app. What this means is that you can start with a minimal base image, then make a python image on top of that, then an app image on top of the python one, etc..

‍

Here's the hierarchy of our docker images:

• gorgias/base - we're using phusion/baseimage as a starting base image.
• gorgias/pgbouncer
• gorgias/rabbitmq
• gorgias/nginx - extends gorgias/base and installs NGINX
• gorgias/python - Installs pip, python3.5 - yes, using it in production.
• gorgias/app - This installs all the system dependencies: libpq, libxml, etc.. and then does pip install -r requirements.txt
• gorgias/web - this sets up uWSGI and runs our flask app
• gorgias/worker - Celery worker

‍

Piece of advice: If you used to run your app using supervisord before I would advise to avoid the temptation to do the same with docker, just let your container crash and let k8s handle it.

‍

Now we can run the above images using: docker-compose, docker-swarm, k8s, Mesos, etc...

‍

We chose Kubernetes too

There is an excellent post about the differences between container deployments which also settles for k8s.

‍

I'll also just assume that you already did your homework and you plan to use k8s. But just to put more data out there:

‍

Main reason: We are using Google Cloud already and it provides a ready to use Kubernetes cluster on their cloud.

‍

This is huge as we don't have to manage the k8s cluster and can focus on deploying our apps to production instead.

‍

Let's begin by making a list of what we need to run our app in production:

• Database (Postgres)
• Message queue (RabbitMQ)
• App servers (uWSGI running Flask)
• Web servers (NGINX proxies uWSGI and serves static files)
• Workers (celery)

‍

Why Kubernetes again?

We ran the above in a normal VM environment, why would we need k8s? To understand this, let's dig a bit into what k8s offers:

• A pod is a group of containers (docker, rtk, lxc...) that runs on a Node. It's a group because sometimes you want to run a few containers next to each other. For example we are running uWSGI and NGINX on the same pod (on the same VM and they share the same ip, ports, etc..).
• A Node is a machine (VM or metal) that runs a k8s daemon (minion) that runs the Pods.
• The nodes are managed by the k8s master (which in our case is managed by the container engine from Google).
• Replication Controller or for short rc tells k8s how many pods of a certain type to run. Note that you don't tell k8s where to run them, it's master's job to schedule them. They are also used to do rolling updates, and autoscaling. Pure awesome.
• Services take the exposed ports of your Pods and publishes them (usually to the Public). Now what's cool about a service that it can load-balance the connections to your pods, so you don't need to manage your HAProxy or NGINX. It uses labels to figure out what pods to include in it's pool.
• Labels: The CSS selectors of k8s - use them everywhere!
• ‍

There are more concepts like volumes, claims, secrets, but let's not worry about them for now.

‍

Postgres

We're using Postgres as our main storage and we are not running it using Kubernetes.

‍

Now we are running postgres in k8s (1 hot standby + pghoard), you can ignore the rest of this paragaph.

The reason here is that we wanted to run Postgres using provisioned SSD + high memory instances. We could have created a cluster just for postgres with these types of machines, but it seemed like an overkill.

The philosophy of k8s is that you should design your cluster with the thought that pods/nodes of your cluster are just gonna die randomly. I haven't figured our how to setup Postgres with this constraint in mind. So we're just running it replicated with a hot-standby and doing backups with wall-e for now. If you want to try it with k8s there is a guide here. And make sure you tell us about it.

‍

RabbitMQ

RabbitMQ (used as message broker for Celery) is running on k8s as it's easier (than Postgres) to make a cluster. Not gonna dive into the details. It's using a replication controller to run 3 pods containing rabbitmq instances. This guide helped: https://www.rabbitmq.com/clustering.html

‍

uWSGI & NGINX

As I mentioned before, we're using a replication controller to run 3 pods, each containing uWSGI & NGINX containers duo: gorgias/web & gorgias/nginx. Here's our replication controller web-rc.yaml config:

‍

apiVersion: v1
kind: ReplicationController
metadata:
 name: web
spec:
 replicas: 3 # how many copies of the template below we need to run
 selector:
   app: web
 template:
   metadata:
     labels:
       app: web
   spec:
     containers:
     - name: web
       image: gcr.io/your-project/web:latest # the image that you pushed to Google Container Registry using gcloud docker push
       ports: # these are the exposed ports of your Pods that are later used by the k8s Service
         - containerPort: 3033
           name: "uwsgi"
         - containerPort: 9099
           name: "stats"
     - name: nginx
       image: gcr.io/your-project/nginx:latest
       ports:
         - containerPort: 8000
           name: "http"
         - containerPort: 4430
           name: "https"
       volumeMounts: # this holds our SSL keys to be used with nginx. I haven't found a way to use the http load balancer of google with k8s.  
         - name: "secrets"
           mountPath: "/path/to/secrets"
           readOnly: true
     volumes:
       - name: "secrets"
         secret:
           secretName: "ssl-secret"
And now the web-service.yaml:apiVersion: v1
kind: Service
metadata:
 name: web
spec:
 ports:
 - port: 80
   targetPort: 8000
   name: "http"
   protocol: TCP
 - port: 443
   targetPort: 4430
   name: "https"
   protocol: TCP
 selector:
   app: web
 type: LoadBalancer

‍

That type: LoadBalancer at the end is super important because it tells k8s to request a public IP and route the network to the Pods with the selector=app:web.
If you're doing a rolling-update or just restarting your pods, you don't have to change the service. It will look for pods matching those labels.

‍

Celery

Also a replication controller that runs 4 pods containing a single container: gorgias/worker, but doesn't need a service as it only consumes stuff. Here's our worker-rc.yaml:

‍

apiVersion: v1
kind: ReplicationController
metadata:
 name: worker
spec:
 replicas: 2
 selector:
   app: worker
 template:
   metadata:
     labels:
       app: worker
   spec:
     containers:
     - name: worker
       image: gcr.io/your-project/worker:latest

‍

‍

Some tips

• Installing some python deps take a long time, for stuff like numpy, scipy, etc.. try to install them in your namespace/app container using pip and then do another pip install in the container that extends it, ex: namespace/web, this way you don't have to rebuild all the deps every time you update one package or just update your app.
• Spend some time playing with gcloud and kubectl. This will be the fastest way to learn of google cloud and k8s.
• Base image choice is important. I tried phusion/baseimage and ubuntu/core. Settled for phusion/baseimage because it seems to handle the init part better than ubuntu core. They still feel too heavy. phusion/baseimage is 188MB.

‍

‍

Conclusion

With Kubernetes, docker finally started to make sense to me. It's great because it provides great tools out of the box for doing web app deployment. Replication controllers, Services (with LoadBalancer included), Persistent Volumes, internal DNS. It should have all you need to make a resilient web app fast.

At Gorgias we're building a next generation helpdesk that allows responding 2x faster to common customer requests and having a fast and reliable infrastructure is crucial to achieve our goals.

If you're interested in working with this kind of stuff (especially to improve it): we're hiring!

We've released a new version of the Chrome Extension, with sharing features and a new navigation bar. We hope you'll love it!

‍

Share templates inside the extension

Before, the only way to share templates with your teammates was to login on Gorgias.io.

If you're on the startup plan, when you create a template, you can choose who has access to it: either only you, specific people, or your entire team.

‍

‍

The account management section is now available in the extension, under settings.

‍

New navigation

Tags are now available on the left. It's easier to manage hundreds of templates with them.
You can also navigate through your private & shared templates. Shared templates include templates shared with specific people or with everyone.

‍

‍

We hope you'll enjoy this new version of our Chrome Extension. As usual, your feedback & questions are welcome!

Today, we’re thrilled to announce that we’ve raised a $1.5 million Seed round led by Charles River Ventures and Amplify Partners, to help build our new helpdesk.

‍

We’re incredibly grateful to early users, customers, mentors we’ve met both at and Techstars.

‍

We started the journey with Alex at the beginning of 2015 with our Chrome extension, which helps write email faster using templates. We’ve been pleased all along with customers telling us about how helpful it was, especially for customer support.

‍

While building the extension, we’ve realized that a big inefficiency in support lies in the lack of integration between the helpdesk, the payment system, CRM and other tools support is using. As a result, agents need to do a lot of repetitive work to respond to customer requests, especially when the company is big.

‍

That’s why we’ve decided to build a new kind of helpdesk to enable customer support agents to respond 2x faster to customers. You can find out more and sign up for our private beta here.

‍

When a company has a lot of customers, support becomes repetitive. We want to provide support teams with tools to automate the way they treat simple repetitive requests. This way, they have more time for complex customer issues.

‍

We'll now focus on this helpdesk and on growing the team, oh, and if you'd like to join, we're hiring! We're super excited about this new helpdesk product. If you’re using the extension, don’t worry.

‍

Romain & Alex

We've been busy, but not deaf!

Last few months we got lots of feedback about our extension and found to our delight that most people are satisfied, but still a few recurrent issues came up:

• The HTML/WYSIWYG editor sucks.
• No support for Outlook.com.

‍

We listened and now we're presenting:

• A brand new editor
• Support for outlook.com
• More on the Rich-Text editor

‍

WYSIWYG editors for the web are notoriously buggy and are just difficult to develop.

‍

I have yet to see one that is bug free. There are few venerable editors that do a good job like TinyMCE, FKEditor or CKEditor.. but they are big and all have edge cases that break the intended formatting and add a lot of garbage html.

‍

There are newer good quality editors in town such as Redactor. The one that got my attention and finally landed in Gorgias is this wonderful editor called which is super lightweight, uses modern content-editable (no i-frames) and 'just works' most of the time. That's not to say it's perfect, but it's good enough and I'm satisfied with it's direction in terms of development.

‍

Enjoy it and as always send us bug-reports or feedback on: support@gorgias.com

TL;DR:

• Support chats can now be directly tied to revenue. Brands are measuring conversations by conversion rate, average order value (AOV), and GMV influenced.
• AI resolution rate is only valuable if the answers are accurate and helpful. A high resolution rate doesn’t matter if it leads to poor recommendations — the best AI both deflects volume and drives confident purchases.
• Chat conversion rates often outperform traditional channels. Brands like Arc’teryx saw a 75% lift in conversions (from 4% to 7%) when AI handled high-intent product questions.
• Shoppers who chat often spend more. Conversations lead to higher AOVs by helping customers understand products, explore upgrades, and discover add-ons — not just through upselling, but smarter guidance.

Conversational commerce finally has a scoreboard.

For years, CX leaders knew support conversations mattered, they just couldn’t prove how much. Conversations lived in that gray area of ecommerce where shoppers got answers, agents did their best, and everyone agreed the channel was “important”… 

But tying those interactions back to actual revenue? Nearly impossible.

Fast forward to today, and everything has changed.

Real-time conversations — whether handled by a human agent or powered by AI — now leave a measurable footprint across the entire customer journey. You can see how many conversations directly influenced a purchase. 

In other words, conversational commerce is finally something CX teams can measure, optimize, and scale with confidence.

Why measuring conversational commerce matters now

If you want to prove the value of your CX strategy to your CFO, your marketing team, or your CEO, you need data, not anecdotes.

Leadership isn’t swayed by “We think conversations help shoppers.” They want to see the receipts. They want to know exactly how interactions influence revenue, which conversations drive conversion, and where AI meaningfully reduces workload without sacrificing quality.

That’s why conversational commerce metrics matter now more than ever. This gives CX leaders a way to:

• Quantify the revenue influence of conversations
• Understand where AI improves efficiency — and where humans add the most value
• Make informed decisions on staffing, automation, and channel investment
• Turn CX into a profit center instead of a cost center

These metrics let you track impact with clarity and confidence.

And once you can measure it, you can build a stronger case for deeper investment in conversational tools and strategy.

The 4 metric categories that define conversational commerce success

So, what exactly should CX teams be measuring?

While conversational commerce touches every part of the customer journey, the most meaningful insights fall into four core categories: 

1. Automation performance
2. Conversion & revenue impact
3. Engagement quality
4. Discounting behavior

Let’s dive into each.

Automation performance metrics

If you want to understand how well your conversational commerce strategy is working, automation performance is the first place to look. These metrics reveal how effectively AI is resolving shopper needs, reducing ticket volume, and stepping into revenue-driving conversations at scale.

The two most foundational metrics?

1. Resolution rate: Are AI-led conversations actually helpful?

Resolution rate measures how many conversations your AI handles from start to finish without needing a human to take over. On paper, high resolution rates sound like a guaranteed win. It suggests your AI is handling product questions, sizing concerns, shade matching, order guidance, and more — all without adding to your team’s workload.

But a high resolution rate doesn’t automatically mean your AI is performing well.

Yes, the ticket was “resolved,” but was the customer actually helped? Was the answer accurate? Did the shopper leave satisfied or frustrated?

This is where quality assurance becomes essential. Your AI should be resolving tickets accurately and helpfully, not simply checking boxes.

At its best, a strong resolution rate signals that your AI is:

• Confidently answering product questions
• Guiding shoppers to the right SKU, variant, shade, size, or style
• Reducing cart abandonment caused by confusion
• Helping pre-sale shoppers convert faster

When resolution rate quality goes up, so does revenue influence.

You can see this clearly with beauty brands, where accuracy matters enormously. bareMinerals, for example, used to receive a flood of shade-matching questions. Everything from “Which concealer matches my undertone?” to “This foundation shade was discontinued; what’s the closest match?” 

Before AI, these questions required well-trained agents and often created inconsistencies depending on who answered.

Once they introduced Shopping Assistant, resolution rate suddenly became more meaningful. AI wasn’t just closing tickets; it was giving smarter, more confident recommendations than many agents could deliver at scale, especially after hours. 

That accuracy paid off. 

AI-influenced purchases at bareMinerals had zero returns in the first 30 days because customers were finally getting the right shade the first time.

That’s the difference between “resolved” and resolved well.

2. Zero-touch tickets: How many tickets never reach a human?

The zero-touch ticket rate measures something slightly different: the percentage of conversations AI manages entirely on its own, without ever being escalated to an agent.

This metric is a direct lens into:

• Workload reduction
• Team efficiency
• Cost savings
• AI’s ability to own high-volume question types

More importantly, deflection widens the funnel for more revenue-driven conversations.

When AI deflects more inbound questions, your support team can focus on conversations that truly require human expertise, including returns exceptions, escalations, VIP shoppers, and emotionally sensitive interactions.

Brands with strong deflection rates typically see:

• Shorter wait times
• Higher CSAT
• Lower support costs
• More AI-influenced revenue

Conversion and revenue impact metrics

If automation metrics tell you how well your AI is working, conversion and revenue metrics tell you how well it’s selling.

This category is where conversational commerce really proves its value because it shows the direct financial impact of every human- or AI-led interaction.

1. Chat Conversion Rate (CVR): How often do conversations turn into purchases?

Chat conversion rate measures the percentage of conversations that end in a purchase, and it’s one of the clearest indicators of whether your conversational strategy is influencing shopper decisions.

A strong CVR tells you that conversations are:

• Building confidence
• Removing hesitation
• Guiding shoppers toward the right product

You see this clearly with brands selling technical or performance-driven products. 

Outdoor apparel shoppers, for example, don’t just need “a jacket” — they need to know which jacket will hold up in specific temperatures, conditions, or terrains. A well-trained AI can step into that moment and convert uncertainty into action.

Arc’teryx saw this firsthand. 

Once Shopping Assistant started handling their high-intent pre-purchase questions, their chat conversion rate jumped dramatically — from 4% to 7%. A 75% lift. 

That’s what happens when shoppers finally get the expert guidance they’ve been searching for.

2. GMV influenced: The revenue ripple effect of conversations

Not every shopper buys the moment they finish a chat. Some take a few hours. Some need a day or two. Some want to compare specs or read reviews before committing.

GMV influenced captures this “tail effect” by tracking revenue within 1–3 days of a conversation.

It’s especially powerful for:

• High-consideration purchases (like outdoor gear, home furniture, equipment)
• Products with many options, specs, or configurations
• Shoppers who need reassurance before buying

In Arc’teryx’s case, shoppers often take time to confirm they’re choosing the right technical gear.

Yet even with that natural pause in behavior, Shopping Assistant still influenced 3.7% of all revenue, not by forcing instant decisions, but by providing the clarity people needed to make the right one.

3. AOV from conversational commerce: Do conversations lead to bigger carts?

This metric looks at the average order value of shoppers who engage in a conversation versus those who don’t. 

If the conversational AOV is higher, it means your AI or agents are educating customers in ways that naturally expand the cart.

Examples of AOV-lifting conversations include:

• Recommending complementary gear, tools, or accessories
• Suggesting upgraded options based on needs
• Helping shoppers understand the difference between product tiers
• Explaining why a specific product is worth the investment

When conversations are done well, AOV increases not because shoppers are being upsold, but because they’re being guided. 

4. ROI of AI-powered conversations: The metric your leadership cares most about

ROI compares the revenue generated by conversational AI to the cost of the tool itself — in short, this is the number that turns heads in boardrooms.

Strong ROI shows that your AI:

• Does the work of multiple agents
• Drives new revenue, not just ticket deflection
• Provides accurate answers consistently, at any time
• Delivers a high-quality experience without expanding headcount

When ROI looks like that, AI stops being a “tool” and starts being an undeniable growth lever.

Related: The hidden power and ROI of automated customer support

Engagement metrics that indicate purchase intent

Not every metric in conversational commerce is a final outcome. Some are early signals that show whether shoppers are interested, paying attention, and moving closer to a purchase.

These engagement metrics are especially valuable because they reveal why conversations convert, not just whether they do. When engagement goes up, conversion usually follows.

1. Click-Through Rate (CTR): Are shoppers acting on the products your AI recommends?

CTR measures the percentage of shoppers who click the product links shared during a conversation. It’s one of the cleanest leading indicators of buyer intent because it reflects a moment where curiosity turns into action.

If CTR is high, it’s a sign that:

• Your recommendations are relevant
• The conversation is persuasive
• The shopper trusts the guidance they’re getting
• The AI is surfacing the right product at the right time

In other words, CTR tells you which conversations are influencing shopping behavior.

And the connection between CTR and revenue is often tighter than teams expect.

Just look at what happened with Caitlyn Minimalist. When they began comparing the results of human-led conversations versus AI-assisted ones over a 90-day period, CTR became one of the clearest predictors of success. Their Shopping Assistant consistently drove meaningful engagement with its recommendations — an 18% click-through rate on the products it suggested.

That level of engagement translated directly into better outcomes:

• AI-driven conversations converted at 20%, compared to just 8% for human agents
• Many of those clicks led to multi-item purchases
• Overall, the brand experienced a 50% lift in sales from AI-assisted chats compared to human-only ones

When shoppers click, they’re moving deeper into the buying cycle. Strong CTR makes it easier to forecast conversion and understand how well your conversational flows are guiding shoppers toward the right products.

Discounting behavior metrics

Discounting can be one of the fastest ways to nudge a shopper toward checkout, but it’s also one of the fastest ways to erode margins. 

That’s why discount-related metrics matter so much in conversational commerce. 

They show not just whether AI is using discounts, but how effectively those discounts are driving conversions.

1. Discounts offered: Are incentives being used strategically or too often?

This metric tracks how many discount codes or promotional offers your AI is sharing during conversations. 

Ideally, discounts should be purposeful — timed to moments when a shopper hesitates or needs an extra nudge — not rolled out as a one-size-fits-all script. When you monitor “discounts offered,” you can ensure that incentives are being used as conversion tools, not crutches.

This visibility becomes particularly important at high-intent touchpoints, such as exit intent or cart recovery interactions, where a small incentive can meaningfully increase conversion if used correctly.

2. Discounts applied: Are those discounts actually influencing the purchase?

Offering a discount is one thing. Seeing whether customers use it is another.

A high “discounts applied” rate suggests:

• The offer was compelling
• The timing was right
• The shopper truly needed that incentive to convert

A low usage rate tells a different story: Your team (or your AI) is discounting unnecessarily.

This metric alone often surprises brands. More often than not, CX teams discover they can discount less without hurting conversion, or that a non-discount incentive (like a relevant product recommendation) performs just as well.

Understanding this relationship helps teams tighten their promotional strategy, protect margins, and use discounts only where they actually drive incremental revenue.

How CX teams use these metrics to make better decisions

Once you know which metrics matter, the next step is building a system that brings them together in one place.

Think of your conversational commerce scorecard as a decision-making engine — something that helps you understand performance at a glance, spot bottlenecks, optimize AI, and guide shoppers more effectively.

In Gorgias, you can customize your analytics dashboard to watch the metrics that matter most to your brand. This becomes the single source of truth for understanding how conversations influence revenue.

Here’s what a powerful dashboard unlocks:

1. You learn where AI performs best (and where humans outperform)

Some parts of the customer journey are perfect for AI: repetitive questions, product education, sizing guidance, shade matching, order status checks. 

Others still benefit from human support, like emotional conversations, complex troubleshooting, multi-item styling, or high-value VIP concerns.

Metrics like resolution rate, zero-touch ticket rate, and chat conversion rate show you exactly which is which.

When you track these consistently, you can:

• Identify conversation types AI should fully own
• Spot where AI needs more training
• Allocate human agents to higher-value conversations
• Decide when humans should step in to drive stronger outcomes

For example, if AI handles 80% of sizing questions successfully but struggles with multi-item styling advice, that tells you where to invest in improving AI, and where human expertise should remain the default.

2. You uncover what shoppers actually need to convert

Metrics like CTR, CVR, and conversational AOV reveal the inner workings of shopper decision-making. They show which recommendations resonate, which don’t, and which messaging actually moves someone to purchase.

With these insights, CX teams can:

• Refine product recommendations
• Improve conversation flows that stall out
• Adjust the tone or structure of AI messaging
• Draft stronger scripts for human agents
• Identify recurring questions that indicate missing PDP information

For instance, if shoppers repeatedly ask clarifying questions about a product’s material or fit, that’s a signal for merchandising or product teams. 

If recommendations with social proof get high engagement, marketing can integrate that insight into on-site messaging. 

Conversations reveal what customers really care about — often before analytics do.

3. You prove that conversations directly drive revenue

This is the moment when the scorecard stops being a CX tool and becomes a business tool.

A clear set of metrics shows how conversations tie to:

• GMV influenced
• AOV lift
• Revenue generated by AI
• ROI of conversational commerce tools

When a CX leader walks into a meeting and says, “Our AI Assistant influenced 5% of last month’s revenue” or “Conversational shoppers have a 20% higher AOV,” the perception of CX changes instantly.

You’re no longer a support cost. You’re a revenue channel.

And once you have numbers like ROI or revenue influence in hand, it becomes nearly impossible for anyone to argue against further investment in CX automation.

4. You identify where shoppers are dropping off or hesitating

A scorecard doesn’t just show what’s working, it surfaces what’s not.

Metrics make friction obvious:

Once you identify these patterns, you can run targeted experiments:

• Test new scripts or flows
• Adjust product recommendations
• Add social proof or benefit framing
• Reassess discounting strategies
• Rework messaging on key PDPs

Compounded over time, these moments create major lifts in conversion and revenue.

5. You create a feedback loop across marketing, merchandising, and product

One of the biggest hidden values of conversational data is how it strengthens cross-functional decision-making.

A clear analytics dashboard gives teams visibility into:

• Unclear or missing product information (from repeated questions)
• Merchandising opportunities (from your most popular products)
• Landing page or PDP improvements (from drop-off points)
• Messaging that resonates with real customers (from AI messages)

Suddenly, CX isn’t just answering questions — it’s informing strategy across the business.

CX drives revenue when you measure what matters

With the right metrics in place, CX leaders can finally quantify the impact of every interaction, and use that data to shape smarter, more profitable customer journeys.

If you're ready to measure — and scale — the impact of your conversations, tools like Gorgias AI Agent and Shopping Assistant give CX teams the visibility, accuracy, and performance needed to turn every interaction into revenue.

Want to see it in action? Book a demo and discover what conversational commerce can do for your bottom line.

{{lead-magnet-2}}

TL;DR: 

• AI hallucinations happen when AI models create false information that sounds real. 
• They occur in customer support when chatbots lack proper training data or face unclear questions.
• Main causes include bad training data, overfitting, and confusing prompts. You can prevent them by grounding responses in real data, setting clear limits, and keeping humans in the loop. 
• When managed right, AI reduces support tickets while staying accurate and on-brand.

Your AI chatbot just told a customer their order ships in two days when you actually need five. That's an AI hallucination, or false information delivered with complete confidence.

These fake-but-convincing responses can wreck customer trust and create headaches for your support team. Understanding what triggers these AI mistakes and how to stop them matters for any brand using AI in customer service. 

This guide covers everything support teams need to know about AI hallucinations, from spotting them to building systems that keep your AI honest and helpful.

{{lead-magnet-1}}

What are AI hallucinations?

AI hallucinations are false or made-up responses from AI models that sound completely believable. This means the AI creates information that isn't based on real data but presents it like it's a fact.

The term “hallucination” comes from psychology, but AI hallucinations work differently than human ones. When an AI hallucinates, it's not seeing things that aren't there. Instead, it's filling gaps in its knowledge with creative guesswork.

Large language models (LLMs) power most modern chatbots. These models predict what word comes next based on patterns they learned during training. Sometimes they predict wrong and create entirely made-up information.

The real problem isn't that AI makes mistakes — it's how confidently it delivers wrong answers. Your AI won't say “I think” or “maybe.” It states false information with authority, making errors hard to catch.

For your ecommerce brand, this could mean your chatbot invents return policies or confirms products are in stock when they're not. These confident lies break customer trust and force your human agents to clean up the mess.

What causes AI hallucinations

AI hallucinations are baked into how current models function, caused by training data limitations, missing context, and statistical prediction errors that lead AI to invent convincing but false answers. Knowing why they happen helps you prevent them in your customer support.

Insufficient training data creates the biggest problems. When you ask AI about topics it hasn't learned, it tries to fill knowledge gaps with educated guesses. These guesses often sound reasonable but are completely wrong.

Overfitting happens when AI memorizes training examples instead of learning patterns. The model becomes an expert at repeating what it's seen before but terrible at handling new situations.

Ambiguous prompts confuse AI models. When customers ask vague questions that could mean several things, AI picks one interpretation and runs with it.

Outdated information causes problems because most AI models have knowledge cutoffs. They don't know about new promotions, products, or policy changes after their training ended. Your AI might confidently share old shipping times or discontinued product details.

Pattern misapplication occurs when AI applies learned patterns to wrong situations. The model recognizes linguistic patterns and uses them inappropriately, creating responses that sound right but make no sense in context.

Examples of AI hallucinations in customer support

AI hallucinations create real problems for support teams. When chatbots hallucinate, human agents spend time fixing the damage instead of helping customers with genuine needs.

Here are common ways AI hallucinates in ecommerce support:

• Product feature invention: Customer asks if a jacket is waterproof. AI confidently says "Yes, it's fully waterproof and tested to 10 feet underwater" when it's only water-resistant.
• Fake discount codes: Shopper requests a discount. AI creates "SAVE20NOW" — a realistic-sounding but non-existent code that fails at checkout.
• Wrong return windows: AI tells customers they have 60 days to return items because it hasn’t been fed your return policy, creating expectations you can't meet.
• Fabricated shipping promises: AI promises next-day delivery for standard shipping orders, setting impossible expectations.
• Invented company policies: Customer asks about price matching. AI creates a detailed policy you've never offered, forcing agents to disappoint customers.

Each hallucination creates a cascade of problems. Customers get frustrated when promises don't match reality. Your support team wastes time explaining why the AI was wrong. Your brand reputation takes a hit when customers can't trust your automated responses.

The worst part? These hallucinations often sound more helpful than honest answers. An AI that says “I don't know” seems less useful than one that confidently provides detailed (but wrong) information.

How to prevent AI hallucinations in customer support

You can't eliminate AI hallucinations completely, but you can reduce them. The key is moving from pure text generation to grounded, controlled responses based on your real data.

Limit possible outcomes

Instead of letting AI create any response it wants, give it specific options to choose from. For common questions about returns or shipping, create approved response categories. This prevents AI from inventing policies on the spot.

Decision trees work well for this approach. When customers ask about returns, your AI follows a predetermined path: check order date, verify product type, provide appropriate response. No creativity required.

You can also set response templates for frequent questions. Templates include placeholders for customer names or order numbers while keeping core information consistent and accurate.

Related: How to write Guidance with the “when, if, then” framework

Train models on relevant data

Generic AI training creates generic problems. Train your AI specifically on your business data — past support tickets, verified Help Center articles, and current product information.

Your training data should include:

• Real customer conversations: Use actual support tickets to teach AI how customers ask questions and what answers work
• Current product catalogs: Keep AI updated on what you actually sell, not what it thinks you might sell
• Verified policies: Only include official company policies, not industry standards or competitor information
• Brand voice examples: Show AI how your team actually talks to customers
• Your public Help Center: Use the resources you already provide to customers to teach it your most-asked questions

Quality matters more than quantity. It’s better to train on 1,000 accurate examples than 10,000 low-quality ones.

Create response templates

Templates give AI structure while allowing personalization. Instead of generating responses from scratch, AI fills in blanks within approved frameworks.

A shipping template might look like: 

• "Hi [customer name], your order [order number] shipped on [ship date] and will arrive by [delivery date]. Track it here: [tracking link]."

Templates ensure consistency across all AI responses. Customers get the same quality information whether they chat at 2 pm or 2 am. Your brand voice stays consistent even when AI handles the conversation.

Tell the model what to include and exclude

Set explicit boundaries for your AI through system prompts and instructions. Create lists of topics that always need human agents, like product safety complaints or legal threats.

Specify which information sources AI can use. Point it toward your Help Center and product database while blocking access to general internet information that might be outdated or irrelevant.

You can also create escalation triggers. When AI encounters certain keywords or question types, it automatically passes the conversation to a human agent instead of guessing.

Test and refine the system

AI isn't a set-it-and-forget-it tool. Regular testing catches problems before customers do.

Set up quality checks on AI responses. Review a sample of conversations weekly to spot inaccuracies or areas for improvement. Look for patterns in escalated tickets — they often reveal gaps in AI training.

A/B testing helps optimize AI performance. Try different prompt configurations to see which produces more accurate responses. Monitor customer satisfaction scores for AI-handled tickets compared to human-handled ones.

Customer feedback provides valuable insights. When customers report AI errors, use those examples to improve training data and refine response templates.

Add human oversight and escalation

Build safety nets into your AI system. Set confidence thresholds so the AI only responds when it's confident in its answer. Uncertain responses get escalated to human agents automatically.

Create clear escalation paths for complex issues. AI should recognize when questions go beyond its capabilities and smoothly transfer customers to appropriate team members.

Human oversight doesn't mean micromanaging every AI response. Instead, focus on monitoring patterns and intervening when AI consistently struggles with specific questions.

Ground answers in Shopify and help center data

This strategy delivers the biggest impact for ecommerce brands. Grounding means forcing AI to base responses on verified, real-time data from your tech stack.

When customers ask about order status, grounded AI checks live Shopify data instead of guessing. When they ask about policies, it pulls exact text from your Help Center instead of paraphrasing from memory.

Grounding transforms AI from a creative writer into a reliable assistant. It can only share information that exists in your approved systems, dramatically reducing hallucination risk.

Integration with your ecommerce platform ensures AI always has current information about inventory, shipping, and customer orders. No more promising products you don't have or delivery dates you can't meet.

Turn AI accuracy into competitive advantage

The brands winning with AI have put in the hours to train it. They've built systems that combine AI efficiency with human oversight, creating customer experiences that feel both fast and trustworthy.

Gorgias AI Agent demonstrates this approach in action. It grounds responses in your Shopify data and Help Center content, ensuring every automated interaction reflects your actual business information. Customizable guardrails let you set boundaries while maintaining the speed customers expect.

Ready to see how accurate AI can transform your support operations? Book a demo and discover how to automate customer service without sacrificing quality or control.

{{lead-magnet-2}}