Recent searches


No recent searches

Lance Conzett's Avatar

Lance Conzett

Joined Apr 15, 2021

·

Last activity May 16, 2024

Following

0

Follower

1

Total activity

18

Vote

1

Subscriptions

8

ACTIVITY OVERVIEW

Latest activity by Lance Conzett

Lance Conzett commented,

Community commentAnnouncements

We just got added to the EAP and noticed one immediate issue: when merging suggested tickets, we seem to always get the “merging across accounts” warning, even when the tickets all belong to the same requester.

View comment · Posted May 16, 2024 · Lance Conzett

0

Followers

0

Votes

0

Comments


Lance Conzett created a post,

Post Feedback - Voice (Talk)

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)

 

We'd like to be able to encourage the summarization to ignore information relating to account verification. We require agents to verify a customer's name, address, and the last four digits of their SSN for regulatory and compliance reasons. Sometimes, the summarization feature will include that information in the summary, which we'd rather avoid.

 

What problem do you see this solving? (1-2 sentences) 

 

Reduces effort to redact information, prevents potential data leakage, improves summaries to include the most important information from the conversation.

 

When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)

 

This happened at least one in the ~4 hours since enabling this feature. In the case of a short phone call, we anticipate that his will happen more frequently. Our guess is is that because the summary wants to have four bullet points, it's grasping at straws to add the remaining points on a short call.

 

Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)

 

We're redacting this information as it appears.

 

What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)

 

Ideally, we could influence the prompt that Zendesk is using to have Open AI summarize the transcription. Something like “summarize this information, but do not include any social security numbers, addresses, or other PII shared by the customer" would work. That could just be a checkbox that changes the prompt—we don't necessarily need to customize this ourselves.

Posted May 08, 2024 · Lance Conzett

0

Followers

2

Votes

2

Comments


Lance Conzett commented,

CommentTicket automation and collaboration

A little disappointed to see that identifying DOBs or SSNs aren't part of this product. It doesn't happen often, but we need to reliably redact highly sensitive personal information if it's shared through a Zendesk ticket.

Would also like to see toggles for each class of thing that redaction suggestions is suggesting. We don't necessarily need to redact addresses, but we might need to redact other sensitive information. Redaction suggestions as they exist right now make it difficult to double-click to select and copy for searching in our internal systems.

View comment · Posted Mar 07, 2024 · Lance Conzett

0

Followers

4

Votes

0

Comments


Lance Conzett commented,

CommentRouting

Small point of feedback: it's unclear from this doc and from routing settings what "Turn on messaging activity routing" actually does.

There's no real definition of "activity" and I had to hunt to find this announcement to discover why my agents were getting assigned so many chats over their capacity limits: https://support.zendesk.com/hc/en-us/articles/5785684459418-announcing-assignment-and-capacity-management-for-messaging

View comment · Posted Aug 03, 2023 · Lance Conzett

0

Followers

0

Votes

0

Comments


Lance Conzett commented,

CommentTicket automation and collaboration

Really liking the summarize feature, especially for summarizing chats, and have a couple of points of feedback:

1. Right now, for Messaging tickets, the summarizer includes comments/conversations with the bot, which isn't super useful for us.

2. I would love to see summarizing built into business rules. The business case is that we're using a trigger to push certain ticket types into a Slack channel with the initial comment, but that doesn't work for chats and doesn't give the full context of the case. It'd be great if we could send the AI summary as part of the Slack notification, so that PMs and other interested parties can see.

View comment · Posted Jul 11, 2023 · Lance Conzett

0

Followers

0

Votes

0

Comments


Lance Conzett commented,

Community comment Discussion - Tips and best practices from the community

@... @... Sounds like you might have some special characters in your JSON body. That's particularly common when using something like Notepad that changes your quotation marks to curly quotes (rather than straight quotes).

I'd recommend reviewing the characters in your JSON and adjusting as needed.

View comment · Posted Jan 30, 2020 · Lance Conzett

0

Followers

0

Votes

0

Comments


Lance Conzett commented,

Community comment Discussion - Tips and best practices from the community

@... Yes, you'll replace the subdomain with your own ZD subdomain. And you do need to enable auth and enter your username and password in order to pass an API call to Zendesk that updates a ticket.

View comment · Posted Jan 28, 2020 · Lance Conzett

0

Followers

0

Votes

0

Comments


Lance Conzett commented,

Community comment Discussion - Tips and best practices from the community

@... Good question! You can ignore that error message, the JSON target is trying to validate your code as JavaScript rather than Liquid. As long as the JavaScript between the {% when %} lines is valid, you're good.

View comment · Posted Jan 27, 2020 · Lance Conzett

0

Followers

0

Votes

0

Comments


Lance Conzett created a post,

Post Discussion - Tips and best practices from the community

Here’s the scenario: You want to make a change to how one of your workflows operates. Maybe you want to try out some new messaging for when a customer writes in about a particular issue. Or maybe you want to try routing tickets to a different group of associates. The easy part is doing it, but how do you validate whether or not the test was successful?

Normally, you would need to run one option for a few weeks or months, then run the other for the same amount of time. Not only is that an awful long time to spend on a single test, it doesn’t isolate the variable, leaving you with poor data to draw conclusions from. Instead of running consecutive tests, you can use a little bit of Liquid Markup and JSON to do an actual, concurrent A/B test in Zendesk.

Our Case

In our case, we require users to choose an issue type when submitting a ticket to our Zendesk. We wanted to test splitting tickets for one issue type between our own pre-written email responses and our partner's machine learning system. We knew our re-open rate and set an ambitious goal to beat that rate.

The Process

Step 1: Create an HTTP Target

Before you start building anything, you need to create an HTTP Target that points back to your own Zendesk account.

  1. Navigate to Admin > Extensions.
  2. Create a new HTTP Target extension.
  3. Enter https://subdomain.zendesk.com/api/v2/tickets/update_many.json?ids={{ticket.id}} as your URL
  4. Select PUT as the target method.
  5. Select JSON as the content type.
  6. Add your username and password to the Basic Authentication section, then click Save.

This has a drawback, though: if the user whose username and password you're using to authenticate this request leaves the company or otherwise has their Zendesk access deactivated, your target will stop working. If at all possible, dedicate one of your Zendesk seats for these kinds of callback requests to prevent outages. (Or come up with a transition plan for when your admins change.)

Also, note that we’re using the “tickets/update_many” endpoint here, rather than the regular tickets endpoint. The reason for that is because we'll be adding tags to the ticket, which requires the update_many endpoint.

Step 2: Create or A/B Test trigger

Now that you have a JSON notifier in place, we need to build a trigger that places tickets into your A/B test.

  1. Create a new trigger and add “Ticket > Is > Created” as a condition to the ALL section.
  2. Optionally, if you don’t want all of your tickets to get tossed into the A/B test, add any other extra criteria. In our case, we’re only A/B testing on tickets submitted with a particular tag, so we added a tag condition.
  3. Set your action to Notify Target and choose the HTTP Target you just set up.
  4. Add this JSON response:
{% assign randomizer = ticket.id | modulo:2 %}

{% case randomizer %}

{% when 0 %}

{“ticket”: {“additional_tags”:[“control”]}}

{% when 1 %}

{“ticket”: {“additional_tags”:[“experiment”]}}

{% endcase %}

Wait, What?

Let’s break down what that JSON payload actually does. Liquid is a markup language built by Shopify and written in Ruby that allows you to incorporate a handful of logical expressions into your Zendesk triggers. In this case, we’re using Liquid to accomplish a few things:

First, we’re using Randomizer to assign a random number value to the newly created ticket. We’ve specified modulo:2 to tell Randomizer that there are two possible values for it to create.

When Randomizer settles on 0, we’re calling that ticket the Control and adding a control tag to the tag list using the additional_tags endpoint. The Control is the current behavior that you’re testing against. This should act as normal, working through your existing workflow or process.

When Randomizer settles on 1, we’re calling that ticket the Experiment and adding an experiment tag to the tag list using the additional_tags endpoint. The Experiment will be using your new behavior.

This effectively splits your ticket volume, 50/50, into two buckets that can be routed in two different ways. Want to weight the test more? Increase the modulo number and add more when statements. They don’t need to be different — you could add modulo:4 and have three different “when” statements that give you the control and only one that gives you the experiment (splitting your volume 75/25), like this:

{% assign randomizer = ticket.id | modulo:4 %}

{% case randomizer %}

{% when 0 %}

{“ticket”: {“additional_tags”:[“control”]}}

{% when 1 %}

{“ticket”: {“additional_tags”:[“control”]}}

{% when 2 %}

{“ticket”: {“additional_tags”:[“control”]}}

{% when 3 %}

{“ticket”: {“additional_tags”:[“experiment”]}}

{% endcase %}

Step 3: Add Your New Behavior

Now that you’ve split your volume, you can create a trigger that only acts on that experiment tag. You may want to update any existing triggers that would otherwise act on these tickets to not fire on the experiment tag, just to be safe.

In our case, because we wanted to test our partner's response system, we created a new trigger with their JSON target and added the experiment tag as a required condition. We also added the control tag to the existing trigger, to prevent it from firing on the experiment.

That's a relatively simple use-case. Anything that can act on a ticket based on the presence of a tag—triggers, automations, SLAs, skills—can be tested with this method.

Reporting on Your Test

The beauty of this solution is that you can easily report on the control and experiment for as long as the test is running. In Insights or Explore, whatever you happen to be using, build a report based on your success metrics. Is it reopens? Average handle time? Decide on your KPI and build a report that shows data for both the control and experiment.

For our test, we wanted to track total tickets received and total reopens for both our control and our experiment. From that, we can derive the percentage reopened. If the experiment’s reopen percentage is less than the control’s reopen percentage, we’ve got ourselves a winner. Otherwise, we go back to the drawing board.

Posted Apr 22, 2019 · Lance Conzett

1

Follower

25

Votes

21

Comments