Today, we’re thrilled to announce we’re joining the Shopify Plus Technology partner program.

‍

Over the past few months, we’ve worked with some incredible Shopify Plus merchants like Darn Good Yarn, Fjallraven and Frichti, who serve tens of thousands of customers every month. What they all had in common was a shared commitment to maximizing the efficiency of the customer service team to keep delivering high-quality support as they grow.

‍

We’ve worked with other technology partners, like LoyaltyLion, in order to provide merchants with a holistic view of their customers when they respond to them in an effort to continue delivering best-in-class support interactions. We’ve also worked with the Plus team to leverage the latest features of the Shopify Plus API, to allow agents to create customized solutions for their customers, For example, creating personalized gift cards based on support conversations. Also, check out the guide we wrote comparing Shopify and Shopify Plus for an idea of the additional functionality and benefits ecommerce business owners get when they upgrade to Shopify Plus.

‍

Using our technology, we’re proud to announce that our Shopify Plus customers have managed to improve their support request treatment time by 30%.

‍

By joining the Technology Partner Program, we’re excited to take our collaboration with Shopify Plus and Shopify Plus merchants to the next level, by further enabling more customers to improve their customer service.

‍

"We are glad to welcome Gorgias to the Shopify Plus Technology Partner Program. We’re particularly excited about how they’re helping our merchants provide efficient & personalized customer support, and hope they can help more of them."

Jamie Sutton, Head of Technology Partnerships, Shopify Plus

Great news! Today, we're announcing a new integration with LoyaltyLion. LoyaltyLion is a digital loyalty framework that gives ecommerce stores innovative ways to engage and retain customers.

‍

Our mutual customer Darn Good Yarn uses it to successfully increase customer retention. When they switched from Freshdesk to Gorgias to manage customer support, they wanted to leverage their loyalty program for customer support.

‍

We used their feedback to build the integration with LoyaltyLion, which they have been using for a couple months in beta. Today, we're excited to make it available to all our users.

‍

What is the LoyaltyLion integration?

Here are some of the benefits of this integration:

‍

• Display how many points a customer has when they contact your support team
• When you respond to customer support requests, award loyalty points to customers directly in Gorgias
• Include the customer's personal referral url in your responses. This way, if they are happy about your support, they'll refer their friends to your store.

‍

‍

Overall, this allows your team to use your loyalty program for customer service.

"We love being able to issue our customers loyalty points directly from Gorgias! It's a great way to boost efficiency and also customer retention."

Chloe Kesler, Customer Support manager at Darn Good Yarn

‍

How can I use the LoyaltyLion Integration?

The integration is immediately available on your Gorgias account. If you don't have an account, you can create one here. Then, follow the instructions in our documentation and you can get started!

Most customers are loyal to brands because they know what level of service they can expect. As a result, providing an above-average customer experience is key to increase repeat in sales.

‍

It’s relatively easy to provide great support when you get started with your store: your team gets a few dozens of support requests a day, and they respond to them almost instantly. The thing is, this level of service is very hard to maintain as you scale. Response time usually drops, and most brands start using standardized macros to keep up with the pace, which is a poor customer experience.

‍

Your sales have increased, good. Now, you need to get your customer support up to speed

Source: Gorgias customers during the Thanksgiving peak

‍

At Gorgias, we’ve been chatting with 400 stores over the past year, and we’ve seen a lot of them working on crossing this “chasm”.

‍

This post shares learning on how you can build a customer support organization that will scale with your business, and provide best-in-class customer service, which will drive customer retention.

‍

Step 1: Run an audit of your support organization

A good place to start is to list the most common reasons customers are contacting you about. Go ahead and manually classify 200 tickets from your support inbox. This should take you about an hour. You can build categories from scratch, or use this spreadsheet of the most common requests for e-commerce companies we built.

‍

‍

Now, you should be able to understand what problems are causing the most pain to customers.

‍

If a specific type of request is above 10% of requests, then it’s a good candidate for optimization. For instance, if you’re getting a lot of “where is my order” questions, here are a few things you can do to deflect those:

• Add a tracking section for customers to track their package on your site. Aftership can help here.
• Send updates to customers about issues with delivery, through SMS or email.

‍

Now that you have a good understanding of the reasons customers are contacting you for, you can map the customer journey, and identify what actions your agents need to take to respond to tickets.

‍

Later, you can use this for training purposes, and to identify optimization opportunities.

At Piper, we basically studied the whole customer journey and tried to identify all reasons why someone could contact us (based on previous history). This helped us quickly identify where customers were "blocked"

‍

Finally, let’s analyze the efficiency of your team. Of course, every business is different, but you can use this table to figure out how efficient your agents are compared to other stores. A good metric to track it is ticket closed per month. Just make sure that satisfaction remains consistent.

Related: Learn more about the impact of live chat on sales. And see how Gorgias live chat can help you turn more browsers into buyers with chat campaigns.

Step 2: Figure out how you can improve the customer experience

Now, let’s work on creating “wow moments” for your customers. If you manage to exceed customers expectations when they contact you, you’re most likely to increase their loyalty and have them refer your store to their friends.

Here are a few ways you can create “wow moments”.

Make it easy for customers to contact you

You should be where your customers are. For example, if you have a Facebook page with a large audience, consider it as a real customer support channel. The point is, you should provide the same level of assistance across all support channels that your customer will use.

Also, don't be afraid to contact customers first, especially when they have items in their shopping cart. Offering help or a discount code at the right time could make the difference between a sale and an abandoned cart.

Example: providing high quality support on Facebook
70% of customers consider Facebook as a live chat support. To maximize customer satisfaction, your response time should be no more than 1 min. You’ll then be listed as a very responsive page, which will encourage your customers to respond.

‍

‍

You can also leverage public posts to build relationship with your customers. Another easy way to facilitate customer communication is to remove the need for customers to repeat themselves. On your support platform, make sure your merge Facebook conversations with email tickets. This way, if the customer switches channel, your team will have access to the context of what the customer said before.

Related: Check out our trends and best practices for customer support.

Personalize every interaction with customer support

You should leverage every data point you have about the customer to personalize the way you communicate with them:
For how long they have been a customer
Their order preference
Their location
The days of the “we value your business” are over.

‍

Always go an extra mile for your customers. If the customer asks for the status of their order, don’t respond only with the tracking number. Go get the order status on UPS so the customer doesn’t have to do it themselves when they’ll receive your email in the subway with poor network connection.

Another good thing to do is to use a specific tone with your customer, that matches the brand image you want to convey.

‍

If you’re into gifs, you can use them to build a brand tone your own set of gifs, designed for your own brand, and use them in your support emails. You can hire an illustrator on Upwork for that, or build them yourself.

Related: Tips to respond to angry customer emails.

Step 3: Give your team the “ironman suit” for support

Now that you know the level of support you aim at giving your customers, and you know what actions your agents need to take to get the delivery info, create an RMAs, etc., you can start optimizing the process for them.

Display rich customer profiles for your agents

To personalize messages, your agents need to have access to customer data. You can leverage the standard Shopify integration from your help desk as a starting point.

Though, it can be relevant to connect other data points to your help desk:

• Display fulfillment data. Shippo is great for that
• Inventory data: Stitch, display inventory to the reps
• NPS responses
• Responses to last promotions

If you’re on Zendesk, enabling the Shopify integration is a good start: it shows how much the customer has spent, and the past orders.

Some Gorgias customers have pretty advanced widgets that display data from Shopify, Stitch & Shipstation. This way, all the customer information is available.

Empower your reps to perform actions from support conversations

You can create custom widgets for your help desk, so that your agents can trigger actions from your help desk. Here are the most helpful actions:

• Create a coupon
• Place a replacement order
• Cancelling an order
• Create an RMA

This is a bit more tricky to implement. You need to build a custom app with buttons that will trigger actions - there are some good tutorials for Zendesk, Freshdesk & Help Scout. At Gorgias, we’ve built integrations with Stitch, Shipstation to embed these actions in the product, and enable you to add your own.

Other 3rd party apps like Chargedesk enable you to refund customers in one click.

‍

‍

Step 4: Track your progress

Our goal here is to improve the customer experience to drive sales. A good way to track the efficiency of your support work is to compare the behavior of customers that have been in contact with customer support from those who have not.

Shopify helps you easily to this. You can create an integration between your help desk and Shopify to tag customers who reach out to support, using the Shopify API. Say you add a “customer_support” tag to them.

‍

‍

Then, you can use Shopify statistics to monitor how the cohort of customers who have been in touch with your support team behaves, and assess the impact of your efforts with customer support.

‍

‍

Another way to proceed is to tag orders that generated a support tickets. This way, if you work on improving delivery notifications, you can monitor the impact.

‍

Final thoughts

Building a scalable support team that provides an amazing customer experience takes time.

‍

Try to test different “wow moments”, iterate on the way you personalize messages, on the tone you’re using, and always track your progress. Among the teams we surveyed, several mentioned they managed to increase sales repeat by 30% after implementing these tactics.

Want to learn more about how customer support can improve your conversion rate and lead to more purchases? Check out our guides to ecommerce upselling and Shopify abandoned cart recovery.

‍

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