Hey everyone. Uh thank you for joining

today's workshop on Grokbot for customer

support. My name is David and I am a

software engineer here at SpaceX AI in

the user ops org.

I'm really excited to share what we've

been working on and how we're using

Grokbot for customer support.

So, here's the agenda for today. I'm

going to quickly give some context on

Grokbot in case you have haven't been

watching the live stream or been to one

of the other sessions.

Then I'll share a few

specific use cases for it around

customer support.

Then I'll demo a lot of these.

My goal is that the session is a little

bit bit more demo heavy

uh so you can really see it in action.

And finally, we'll finish with some Q&A.

So, let's get started.

So, first, what is Grokbot? Grokbot is a

new product that lets you hand off real

work

to an AI coworker.

The interface looks very familiar, just

like a messenger app on your phone or

computer.

But under the hood, it's built to keep

working after you've sent your original

message.

So, you aren't just chatting back and

forth with quick, simple

uh one-offs here and there. You're

really able to delegate a real project

to Grokbot

and

it can go off and take it from there.

One of my favorite things about Grokbot

is how flexible it is to the way you

work.

So, you can start with a single general

bot to help you get set up quickly and

easily

or create a team of specialists that

coordinate around the task and work in

parallel on certain

uh subtasks.

And however your team operates, Grokbot

can fit in and be very useful very

quickly.

So, why Grokbot? Why does it feel like

interacting with a capable coworker uh

rather than just another AI tool.

For me, there are three big reasons.

First, Grokbot is always on.

So, by now you may have heard that

Grokbots have their own computer.

What that

All that really means is that uh

they can work without using yours, which

is

uh a little bit uh more powerful than

you would think.

So, if you close your laptop or you are

working on something else, your Grokbots

can still finish the task you assigned

them without you having to check in

constantly and steer them too much or

slowing down your local machine.

There are also routines, which are

cron jobs or event-based triggers that

you can launch your Grokbots with and

make them

super reactive.

Uh this way you don't have to be online

at the exact moment you want them to run

uh or start working on the task.

And these are simple or these are super

simple to set up. All you have to do is

tell it, create a routine at this time

or on this event.

Just like a normal conversation.

Um and it will set it up for you.

Second, uh it is really easy to use.

The interface is familiar for a reason.

You don't have to be an engineer that is

familiar with the ins and outs of an IDE

to use bots effectively.

You can just talk with it normally like

you would a friend or teammate on Slack.

And finally, it fits how you actually

work. There are already connectors for

most tools you use. You just have to go

in the marketplace and search for them.

And

uh there is likely one for you. So, you

can plug Grokbot immediately into your

ticketing system,

whether that's uh Plane, Zendesk,

Intercom,

uh

where are your team chats like Slack, uh

where your Notion base or where your uh

knowledge base is like Notion.

And then from there, you can use the

bots and routines like building blocks

uh that fit the way your team actually

works.

And

one really uh powerful thing about

Grokbot is if there is a missing piece,

you can likely have Grokbot build it.

Um Grokbot has access to cloud agents.

So, if there's something that you're

missing, you can just have it tell it to

spin up a cloud agent to build a certain

connector or certain thing um and it can

go off and do it for you.

So, you can get creative and build

around and you're not stuck waiting on

Eng's roadmap or a third-party vendor to

um add support for the thing you need.

Cool. Now, we'll get into some customer

support use cases.

So, the big one is always can it answer

support tickets?

Uh the answer is yes, and I'll show this

later in the demo.

I know this can be scary at first to let

an agent uh sort of reply to your

customers.

So, you can definitely build up to it.

So, you can crawl, then walk, then run.

At first, you can have it just read

tickets, maybe give you a summary, and

uh the root issue of what the user is

asking about.

And maybe it can draft a response.

Then, you can have it add the draft to a

note in your ticketing system on the

ticket, so you can sort of see it before

you press send.

And finally, when you're confident, then

you can have it answer and actually

uh respond to the ticket and the user.

There's also things you can do around

the guardrails and environment you give

Grokbot.

So, you can set up evals and traces

fairly easily, so you know what it's

thinking and what actions it will take

uh

before it publishes. So, when you can

add traces to those draft steps, and

then sort of make sure it's

behaving the way you want it to before

going on.

Um

Cool. The second one.

Um so, at scale, you may have a lot of

support tickets with a ton of different

customer states. And it can be really

challenging to find the things you

should care about in that exact moment

that need your attention.

Um Grok Bot can make this a lot easier

uh through alerting.

So, you can spin up a bot that looks for

certain things. For example, maybe your

team is hyper-focused on churn this

quarter, and you want to know when

someone writes in

that is threatening to churn that has

been a customer for 6 months.

Um or more.

Anyone on your team can spin up a Grok

Bot that you have connected to your

ticketing system.

You can just at tell it to create a

routine that looks through your uh your

tickets.

Uh every hour

try classifies if a user is um

threatening to churn and has

uh been a customer for a certain period

of time, and then send you an alert in

the Slack channel, uh so everyone has

visibility.

Um Yeah, and another one that maybe is

more uh

powerful than you think or is harder to

get to than you think is an internal

like question and and answer agent. So,

if you've used other support agents,

they are primarily focused on customer

replies.

Uh it's surprisingly cumbersome to

leverage the knowledge knowledge base

you've already sort of created or

accumulated um to answer your own

teammates' questions. You may have

someone in GTM that is trying to get up

to speed on today's release about cloud

agents,

so they They come prepared to a customer

call or a TSE manager looking for

changes to the internal refund policy

over time.

And if that has impacted

certain customers.

You have already done the hard work of

creating this knowledge base of both

public info, so think your docs and help

center.

As well as likely some internal info, so

you might have suggested operating

procedures around how your teammates

handle refunds that does not public

information.

You should be able to query this

intelligently within Slack and Grokbot

makes this really easy.

And

maybe the last one and

one of the cooler ones is it can improve

itself. So finally, you can give Grokbot

your traces or have it look back on the

last week of tickets and sort of

ask it to look and try to find

improvements for tickets that maybe

could have been handled better, could

have been flagged earlier

and it can go and do those things for

you.

Cool.

Um so next we're going to get into the

demo.

Um

I have created this demo. I have a team

of four bots.

They are build, so it sort of runs the

setup

and the infrastructure. Reply, so this

actually answers users in both

our ticketing system and then Slack.

There's an alert, so it this one

usually gets pinged by reply and posts

an alert in Slack.

And tags me and then tune which tries to

improve the system as we go.

I want to call out that you definitely

do not have to have these in mind or set

them up before getting started.

In fact, I don't recommend that.

Instead, you can start with one bot,

name it a generic name and try to teach

it one workflow.

Then when the scope grows or you need

the need more than one running at a

time. Uh

I recommend breaking them up naturally

then and reorganizing them

uh in a way that makes sense to you.

Cool. So, now I'll get into the demo.

I have

Rockbot set up with the bots we

mentioned.

And then I have a few things that might

look familiar if you are uh

inside of a support work. So,

first we have a knowledge base.

Right now I just set this up in Notion

as an example. So, we have

public docs. So, think of this is like

this could be your documentation or your

help center that has a few things on

product and common issues like off and

billing and FAQ.

Oh, I should uh should have mentioned

that I'm going to use the FlyLo example

that you may have seen in other ones uh

other presentations. So,

this is

uh basically like an air a pretend

airline and I'm going to simplify it so

the only uh

like

skew we have is a monthly internet

subscription that is built it monthly

and is $20 a month.

Cool. So, we have this public

information

that a user could find if they searched

Google.

We have some internal policies. So,

right now

uh this is stuff that we want maybe uh a

billing support member to know if you

have a human answering

uh but you don't want to share

broadly with the public. So, this is

just a very simple example of if a user

asked for a refund, you can approve it

within 14 days and cancel and refund if

they've been

subscribed for more than 14 days, deny

the refund.

And then finally, I just have a a bit of

process for the GrokBot agent reply to

use when replying to some of these

tickets.

So, we just have this loop of what it

should do.

Read the Read the ticket. Look for

the knowledge and then decide to reply

or hand off and then

act, leave a note, and

yeah.

Cool. This is Plane. This is our

ticketing system. So, I've already

pre-filled

a few example tickets and we'll walk

through those.

I have Stripe pulled up as well. So, I

mentioned there's a subscription that

users may pay for that is the

basically like the Wi-Fi pass on a

plane.

And then I have Slack that I'll pull up

for later.

Cool. So,

first let's start with

um

maybe this first ticket. So, I'm going

to go through alphabetical.

So, this is just a very basic question.

I forgot my password. How can I sign in?

Or how do I reset it?

So, let me ask GrokBot to try to reply

to this.

So, like I mentioned, um

I have the GrokBots I mentioned. There

is build. So, I've already set up the

some of the connectors to make this a

little quicker. So, I've added Plane.

I've added Notion, Supabase, and Slack.

Um if you aren't familiar, you can just

click the marketplace and search and

click and install.

Cool. So, let's tell Reply,

"Hi, can you reply to Alex in Plane?"

And it is going to go off and try to

reply.

So, let's see. It's going to look it up.

Uh

I pulled up So, basically what it's

while I wait for it to reply, it's going

to go through this process. So, I have

sort of uh

made this loop pretty simple of just

what I wanted to do, how I wanted to

behave, and sort of show some thinking.

And we'll see that it replied. Okay,

cool. It replied.

It said it replied.

If I go back into the ticket,

you see that it followed the sort of

tracing

or it followed the process that I gave

it. So,

it showed some of its thinking where uh

it says it can reply with high

confidence, the root issue, and the

source uh that it referenced to answer

the question.

Um

cool. And then it gave the right

information. So, these are the exact

steps on

this public off forgot your password.

So, if we go to public off forgot your

password,

these are the exact steps.

Cool. So, that's obviously a pretty

basic example.

But, let's go on to a harder one.

So, this is an example of something that

is not covered in the toy knowledge base

we created. So, some SSO octa stuff.

Let's see.

I'm going to try this

prompt it so it will try to reply, but

it uh in the instructions, I told it to

not reply unless it's pretty confident.

Try

replying to Ben.

And playing.

And once again, it's going to go through

the exact same process. If I were to

change something in

this

sort of uh loop, it would

uh I've already told it to like make

sure to read this every single time. So,

if I were to add maybe seven and some

other step, it would know to do that

after every time.

So, let's wait on that for

a few more seconds.

And let's make sure I have

Slack pulled up for later.

Cool. Okay, nice. So, it says it tried

to do that, but there's no public docs

or internal policies, so low confidence

and handoff.

Which is

exactly what we wanted it to do.

And then, you'll notice that this is

new, so it messaged alert.

So, I've

set up that if something

uh if it looks like maybe an enterprise

customer that's locked out, to

uh make sure to alert me, so I can know

in real time. So, it messaged alert,

alert activated, and posted to Slack in

our alerts DG channel.

It is this one. So, yeah. So, now I'm

without too much work, I can already see

like in real time that uh important

tickets that I need to maybe action on

right now.

Cool.

Uh let's go on for now. So, I'm going to

mark this

done for now and go on to the next one.

So, the next one are going The next one

is going to be two uh refund-related

tickets. I mentioned at the beginning

that we have an SOP specifically around

that.

So, we have

two users, Carter and Damon.

If I go into Stripe and click into them,

I've set it up where uh

Carter just subscribed

and is requesting a refund. So, you

Today is September 16th, so his renews

in exactly a month. So, we should get

grant him this refund.

And then, Damon uh

you'll see that uh

it renews in about 10 days. So, it's

already been, call it 20 days, which is

and our policy is only 14 days within.

So, it should deny Damon and

grant the refund to Carter and it will

We've already set up Stripe, so it can

take these actions

uh

for you. You can set up

set it up to have

you approve the actions or you can tell

it let it like run loose. Okay.

So, let's say, okay, now try to answer

Carter and Damon.

And this one may take a second cuz it's

going to run through the loop, sort of

make

the call and then

if it needs to, it will have to run the

actions through Stripe.

So, let me have those pulled up.

And we'll see this

state get changed here shortly.

Uh

let me pass in the customer IDs, maybe

it'll make it quicker.

>> [snorts]

>> Cool. Let's

It should be on its way now.

>> Um,

let's see.

Cool. So, it's thinking it found them

now, and it says both replies are ready

up. So, let's go look at them.

Cool. So, it just answered.

Uh for Carter, like I mentioned, it

should have canceled and issued a

refund.

It's saying that it did that. If we go

to Carter in Stripe and refresh,

the status should have just changed.

So, nice. Uh it went from active to

canceled, and this payment has been

refunded.

And then,

that is what we

That's what it said it did. And then,

for Damon, it says, "We have denied your

refund."

It didn't give like the full SOP, so it

didn't leak the internal information.

It was just vague, and then it says, uh

"I can cancel I can schedule a

cancellation for you at the end of your

period, so you don't get billed for the

next month."

And then, if we go to Damon and refresh,

this should all stay the same.

And it does. Cool.

Great.

Great. Okay, so now we'll go on to the

next one.

So, Elena

is asking if we can if she can

share her Wi-Fi password with another

person.

This is something that's not actively in

the knowledge base.

So, let's see how it handles it.

Uh

home.

It would be under public docs.

Let me

move that. And it would likely go here.

Cool. So, let's tell

reply.

Let's clear that out.

Great.

Can you reply to Elena now?

And it should

go from there.

So, it's already come come back with

some thinking. It's found the ticket and

it's checking it's

uh sort of already classified that pass

sharing is

uh the root issue and looking if it's in

public docs.

And now it's saying that it couldn't

reply yet because public docs and the

FAQ

uh doesn't have pass sharing.

And it's recommending to tell Tune,

which is the self-improver, to add it to

uh the knowledge base.

So, yes, we'll say

add pass

sharing

to the FAQ.

Say this is not allowed.

So, this is an example of it asking

before it doing something um

by itself. So, for your knowledge base,

this is probably something you want uh

just to make sure you have the final say

over what happens because if this were

to go out um

without you looking and you didn't check

it and it wasn't correct and 100 people

asked about the same thing, then

uh yeah, that'd be an issue.

Okay, so it says it added it to the

knowledge base. I told it to

do it in green so we can delineate it.

So, and it just did. So, pass sharing,

no, you cannot share your Wi-Fi pass

with another person for simultaneous

use.

Um great. Let's see. I actually had one

more thing pulled up.

Um.

Okay, actually

let's skip that then.

Um.

Cool. So, back to GrokBot then.

Um.

It's

we've added the knowledge, so now let's

try to respond. So, in the ticket, uh it

left a note saying to hand off that the

information was missing and um it still

needs a response. So, let's tell reply.

Okay, can you try again now?

That the information's added.

And it says it's answering.

And it says it's replied now. So, now we

have a new sort of thinking note. Now it

can reply with high confidence. There's

a root issue and it links to the new

section in docs that covers it.

So, you cannot share your

Wi-Fi pass with another person. Great,

that's exactly what we wanted.

Um.

Let's mark this one as done.

Cool. Um, that covers a lot of it. Now

let's go to the other one of the other

use cases I mentioned. So, if we go into

Slack,

we've already seen that it can send us

alerts.

Um, but

we have another use case where um

you can have your teammates ask the bot

you've already set up to answer

customers and the knowledge base

uh with

to answer like your own teammates.

So, let's say I am

someone on your billing team and

I want to know what is the

uh refund SOP. So, this is I'm an

internal user.

I'm asking a question

um

and it should give me

the internal knowledge for it. Uh so,

that's the most helpful.

So, we sent it. This may take

about a minute, but uh

yeah, we should see

us getting a response here

pretty soon.

Cool. So,

it's asking for permission to post in

Slack. Let's say always allow

for this.

And it should reply here in a second.

Uh okay.

Let's try that again.

>> Make sure it's running.

Do you see the message?

Um

Okay, it's going. Um

Uh I ran this right before, so you can

see that this is what would happen.

Um it would reply

and go from there.

Let's give it maybe 10 more seconds. If

not, we can go on.

Okay. Now it says it's replied.

Great. So, it added the emoji and it

replied.

Awesome. So, that's the one of the other

use cases.

Cool.

Um

So,

that wraps

and cut the demo there. Um

So, what we learned. First, you can and

should feel comfortable setting

guardrails for your bots. You see So,

maybe at the end there it got it was

even more protective than I wanted it to

be, but that's probably better for

writes.

Uh you can have them be read-only to

start and then work up to writes and

have manual approvals for certain

actions. You can also scope permissions

to different your different bots. So,

one bot might have permission to post

automatically to Slack, one might not.

And make them approve those actions

before they do them.

Second, uh start simple. So, the whole

product is still so new, I don't think

there's one meta or one clear playbook

and the product is meant to be very

flexible.

So, try to make the bots fit into how

you work and not five and not vice

versa.

Third, try to get a little creative and

experiment. You can really have it build

what is missing.

Cool. Thank you so much.

Um

that is the rest of the presentation and

we can go into Q&A.

Oh, yeah.

So, any questions?

Yes.

>> What's the pricing like for this?

>> Uh so, it uses your usage that you would

have through any of your Grok

subscriptions or currently cursor

subscriptions.

Uh so, it just tracks usage.

I'll say

it can really depend on how involved

your loops are. So, if you have

classifiers that run

uh before every ticket, if you have um

if you have it write traces

and evals before doing that, that can

also change.

Right now,

the way I use it, it's around

$1 to $2

uh to answer more in medium to uh

complex tickets and

there are ways I've already tried to

like experiment and found ways to get

that down a lot. So,

there are

um a lot of maybe

low complexity billing tickets of like a

user just asking for a refund or

a user asking about a certain new uh

email they received, you can

sort of

bucket those, you can like run a script,

have it run a script to find those first

or run that uh manually, so it has

um more of a contained sort of set and

then have it reply all at once with the

script to those tickets and I found that

I could get that down to about 20 cents

a ticket for those like low complexity

tickets, which is a huge sort of change.

Um, if you've used any of the other sort

of support agents, you know that like

the cost per they usually charge per

resolution and that's easily

at minimum a dollar if not between one

to ten dollars like order of magnitude

and if you're having humans respond to

those tickets, that can be even higher.

Uh, noticeably higher. So, and that's

just like with half a day of trying to

improve it. Um, I think there's a lot of

gains and unlocks there especially.

Yeah.