Connect your help desk to your customer data

Early in every company's life -- earlier, in fact, than most founders will ever be prepared for -- the support team needs things. Customer data, company data, data visualization tools; the list grows quickly. As the team starts to dig into these needs, there are several realities that eventually everyone comes to agree on:

• Support work is time-sensitive, often measured in minutes or seconds.
• You need both customer and company data in most interactions.
• Your leadership needs both quantitative and qualitative data on the support team's current level of operation.
• This data needs to be easy to get, secure to access, and preferably self-maintaining.
• You do not have resources to spare.

It's hard to meet these needs and our current set of tools make it harder. Eventually we find a way to build a bespoke Jenga tower of "daily customer sync" jobs and inconsistent internal dashboards to try to collect the information we need.

Whose data is it? The answer may surprise you

Most help desks begin from a mistaken belief that they both can and should be your "source of truth" for data about a customer. That means they begin from the assumption that any data you might want about a customer should be put into their tool for you to make use of.

We've written previously about sources of truth, and I highly recommend giving that post a read. This is the definition of a source of truth we came up with:

a source of truth is a canonical depiction of reality inside your company

-- Brian Levine

Using this definition, your help desk cannot be the source of truth for customer data.

Data about your customers exists in multiple places, the primary place being your company's main database. That data will change on its own, at unpredictable times, and the help desk can only be downstream of that.

This means that, at best, you'll have folks building and maintaining a custom event-based system in your application to push information to your help desk in real time. Or more realistically and far more commonly, you won't do that and your support team will rely on a patchwork system of scripts and half-documented processes and lore. This will kind of work, but at the cost of information always being out of date. That's worse than not having the data at all, and it's definitely worse than just giving your support team a safe way to query your customer database directly.

We need customer data in most support requests. More than during requests, we need it for automating the queue, searching important issues, and routing customer requests correctly. But most help desks get it wrong: the help desk can only ever be a consumer of customer data and producer of support data. Trying to shoe-horn it into being "the source of truth" is a fool's errand and results in nothing but pain for you and your team.

Our solution to the problem of reliable, timely access to customer data is a feature we call customer connections.

It's your data, and you need it now

The realization that we can only consume customer data from the help desk clarified some important ideas about what we actually needed as Support Professionals compared to what we currently have:

• Your help desk should ask for data when it needs it.
• Your help desk should give you tools to display that data without needing to deploy an app.

We infused both of these ideas into every decision we made building customer connections, so let's take them point by point.

Don't call us, we'll call you

While everyone agrees that you need some engineering support to have a truly robust, productive support team, that doesn't mean that support tools should assume that you have dedicated engineering resources. In Yetto, we want you to maintain as little as possible. In the case of customer connections, all you need to provide is a single API endpoint for us to send requests for data.

This has some real advantages:

1. You build, secure, and maintain a single JSON API endpoint, rather than having to build a whole API or application for support.
2. There's only one place where you need to review or approve what information you're sending to Yetto.

Once the endpoint is built and ready, you're good! You give us the URL of the endpoint, and we securely request customer data whenver we need it. You can be sure all data is accurate because we just got it from your API, and as a bonus for your security team's peace of mind, we only store the data from that response in memory, it never gets saved to a database.

Look Ma! No iframe!

Ok, that seems simple enough, but what do you send back to Yetto when we ask you for it?

To answer that, let me just show you an example response for a customer connection:

{
  "version": "2024-03-06",
  "customer": {
    "id": "customer_12345",
    "last_active": "10/15/2023",
    "name": "Kelly Customer",
    "plan_type": "Business"
  },
  "sections": [
    {
      "type": "link",
      "title": "Link to customer details",
      "description": "Application data",
      "href": "https://example.com/customer/{{ data.customer.id }}"
    },
    {
      "type": "list",
      "title": "List section",
      "items": [
        {
          "description": "Name",
          "value": "{{ data.customer.name }}"
        },
        {
          "description": "Plan type",
          "value": "{{ data.customer.plan_type }}"
        },
        {
          "description": "Last active",
          "value": "{{ data.customer.last_active }}"
        }
      ]
    }
  ]
}

That's it! No <iframe>. No app to deploy. No marketplace approval process. No separate framework to learn. Just JSON.

Anyway you want it, that's the way you need it

This JSON setup lets you declare both what data you want us to have access to and how you want it displayed, and it's flexible enough to handle your customer data however it's structured.

Lets look at an annotated example of just that customer object:

  ...
  "customer": {
    // The ID of the customer in your database
    "id": "customer_12345",
    // Their personal Stripe ID
    "stripe_id": "cus_QWs34A0j0PwiVz",
    // A nested object about their organization, if it exists
    "organization": {
      "id": "important_org_omg_12345",
      // The organization's Stripe ID
      "stripe_id": "cus_QWs34A0j0PwiVz",
      "role": "member"
    },
    // An arbitrary date when their account was last active, if you needed it
    "last_active": "10/15/2023",
    // Their human readable name
    "name": "Kelly Customer",
    // Subscription plan type as a string
    "plan_type": "Business",
    // A boolean value
    "is_suspended": false,
  },
  ...

Anything under customer is free form. If it's valid JSON, you can send it back to us and use it later on. All data underneath it will be namespaced under data.customer.*, and can be used in the sections array below (more on that later).

Show, don't tell

Ok, so you've put a bunch of customer data into that customer object, and the structure looks good to you, now what? That's where the sections array come in.

The sections array defines how you want (or don't want) that customer data displayed in the metadata sidebar of a Yetto conversation. It will let you do everything from simple tables of information:

...
"sections": [
  {
    "type": "list",
    "title": "List section",
    "items": [
      {
        "description": "Name",
        "value": "{{ data.customer.name }}"
      },
      {
        "description": "Plan type",
        "value": "{{ data.customer.plan_type }}"
      },
      {
        "description": "Last active",
        "value": "{{ data.customer.last_active }}"
      }
    ]
  }
]
...

to links to other systems, like Stripe or Salesforce:

...
"sections": [
  {
    "type": "link",
    "title": "Stripe customer info",
    "description": "Issue refunds, manage subscriptions, verify payment issues",
    "href": "https://dashboard.stripe.com/customers/{{ data.customer.stripe_id }}"
  },
  {
    "type": "link",
    "title": "Salesforce Organization",
    "description": "Note: please check if they're a multi-million dollar org before banning them",
    "href": "https://na#.salesforce.com/{{ data.customer.organization.id }}"
  },
]
...

After we get that back from you, we'll display whatever you've sent us in the sidebar like so:

What if something breaks!?

"Ah yes," I hear you say, "But I have paranoid trust issues. What happens when it fails? What then?"

This is, paradoxically, where I think Yetto's customer connections are strongest. If the API endpoint you've pointed us to fails for any reason, we tell you there's a problem rather than showing you potentially out of date information and giving you a false sense of confidence in answering a ticket.

That means that if the endpoint fails, you could try refreshing the page to see if it was temporary, researching to get the info you need via other means, or raising the alarm and having your team leap into action to fix it. But, importantly, you do not answer the customer with bad information.

More than just the sidebar

The last set of questions you might be asking are something along the lines of "Why would I need to put customer data in its own object? What purpose would that serve? Why don't I just put it in the sections data when I need it?"

This is a bit of a sneak preview to a release later this week, but the short answer is "automation." We don't just make a request to the customer connection endpoint you've given us when you open a conversation, we also do it when your automations run. That means anything in that data.customer object? You can also route, label, or take any other number of actions based on that information.

What about dashboards?

Now, to end on what is potentially my spiciest take of all time: a help desk has no business being a data visualization and exploration tool.

You have a data exploration tool. It's built by people who specialize in those those issues and contains the rest of your company's data.

Support data is not actually useful without the full context. Holding an exported CSV next to the data you actually need to correlate it with is not enough. Looking at a dashboard of truncated data without that context causes bad decisions.

What you actually want, at the end of the day, is for it to be easy for your support data to get into one of those tools. That way, you can see a full picture of how support is impacting and impacted by all the other systems working in your company.

Webhooks

Webhooks are a mature way to notify another system of changes over the internet, and as of today we also let you specify a place you want us to send webhooks for all activity in Yetto. You can consume those webhooks securely and save whatever data your team needs to understand your support team and the unique way it assists customers.

This is the first step to getting the data you need out of the help desk and into the tooling you actually need it in. But be sure to watch this space, we'll be iterating on how this works over time.

A help desk really can help you, too

In the end, the important thing is that your help desk is designed to help you, not lock you in. Our deep belief is that your support data is yours. You need it to make better decisions, support customers more effectively, and eliminate toil for everyone.

Interested in what it feels like to use? Go sign up for our beta. We can't wait to see how you use this.