►
From YouTube: Support Ops - Zendesk - Automation Change Management
Description
Jason Colyer, Support Operations Manager, takes us through change management for Zendesk Automations
A
Greetings
all
my
name
is
jason
collier,
I'm
the
support
operations
manager
here
at
gitlab,
and
today
we're
going
to
talk
about
change
management
for
automations
and
zipdesk.
It's
really
important
that
we
have
a
change
management
process
that
we
follow
it
as
closely
and
as
accurately
as
we
can.
It
ensures
that
we
do
good
testing
that
the
results
that
are
going
to
occur
from
our
implementation
are
what
is
desired
by
the
requester
that
what
we're
doing
isn't
going
to
cause
other
issues
it
really.
A
It
saves
us
time
in
the
long
run
by
ensuring
we
do
things
right,
the
first
time
so
to
kind
of
go
over.
It
there's
there's
kind
of
what
I
call
stages
to
a
change
occurring
for
zendesk
automations
and
it
kind
of
begins
with
the
request
stage,
and
that's
where
someone
being
a
support,
engineer,
support
manager,
a
sales.
You
know
a
tam,
an
am
a
sales
rep.
Whatever
makes
a
request
for
something
to
be
changed.
A
This
request
should
be
focused
on
like
what
they
want
to
see
as
a
result,
not
what
they
want
changed
in
zendesk,
and
this
is
something
really
important.
You
should
absolutely
push
back
if
somebody's,
just
like
oh
deactivate,
this
automation
or
add
an
automation
that
adds
this
tag.
We
want
to
push
back
on
that
for
the
sole
reason
of
that
may
not
be
the
best
thing
to
do
in
the
situation.
What
we
want
to
know
is
what
is
it
you
want
to
see
like
what?
What
is
it?
A
Your
end
goal
is:
oh,
we
want
to
find
these
tickets
and
have
some
way
to
grab
them,
so
we
can
perform
metrics
on
cool
support.
Ops
will
figure
out
how
to
best
implement
that
in
a
way
that
doesn't
cause
a
bunch
of
issues.
For
you
know
the
rest
of
zendesk,
the
rest
of
the
org,
but
a
kind
of
key
important
thing
there
on
the
request
issue
is
at
its
creation.
They
should
have
a
couple
labels
by
default.
A
One
will
be
support,
ops,
category
automations,
that's
a
categorization
label.
We
use
it's
specifically
for
automations
it'll
have
some
kind
of
priority
label,
which
is
support
authority,
urgent,
high
normal
low.
Our
default
is
low.
When
you
create
one
and
it
doesn't
exist,
it
will
get
the
low
tag.
You
can
look
in
our
documentation
to
kind
of
see
how
we
define
what
each
of
those
mean
it
should
contain
the
zendesk
global
or
the
zendesk
federal
instance.
A
I'm
sorry
tag
based
on
which
instance
this
is
for
in
the
case
where
it
is
needed
for
both.
We
should
actually
have
two
issues
made.
Sorry
two
issues
made
that
way.
We
can
have
one
for
global
one
for
us
federal
because
they
often
do
have
a
little
bit
of
difference,
variance
to
them
and
then
beyond
that
you'll
have
a
like
support,
ops
to
do
as
a
default.
That's
to
say
it
is
something
we
need
to
do.
A
We've
got
scripting
and
templating
in
place
to
find
when
these
kind
of
tags
are
missing,
but
you
should
still
strive
to
make
sure
they're,
always
there
and
add
any
that
are
missing
once
the
request
is
in
good
standing,
you
can
assign
it
to
yourself
if
it's
not
already
assigned
and
then
add
the
tag
supportops
doing
to
it
to
indicate
you
are
actively
now
working
on
this.
This
moves
us
to
the
testing
stage.
A
This
is
a
really
important
stage.
It's
where
you're
going
to
go
into
the
sandbox
of
the
zendesk
instance
that
you
are
working
on
and
make
the
changes
that
you
believe
need
to
occur
once
this
is
done.
You
want
to
update
the
original
request
with
a
link
to
the
new
automation
or
a
link
showing
it's
been
inactive.
If
you
need
to
do
that,
however
much
time
you
added
you,
you
took
to
do
your
change
in
the
sandbox
in
the
request,
you
can
use
slash,
spend
space
x,
space
minutes
for
x,
the
number
of
minutes
you
spent.
A
A
This
is
to
ensure
that
not
only
everything's
being
tested
thoroughly,
but
others
have
a
time
to
review
your
test
results.
Automation's
often
like
involve
time-based
events.
Things
like
oh,
it's
been
pending
for
72
hours,
because
of
that
I
recommend
in
your
testing,
at
least
to
like
set
that
number
as
low
as
you
can
like
it's
been
pending
for
one
hour
or
something
like
that,
so
that
you
can
adequately
test
your
automation
is
working
in
the
way
that
it's
intended
often
you're
gonna
need
assistance
in
testing
out
changes.
A
A
So
if,
if
you
believe
you
need
assistance,
testing
out
changes
or
you
believe
it's
best,
that
support
does
some
testing
as
well
consider
reaching
out
to
like
the
requester
to
ask
for
help
with
that
or
a
fellow
support
office
team
member
to
help,
or
you
can
always
reach
out
to
a
support.
Ops
manager
like
myself
and
we're
more
than
willing
to
help
out
with
that.
A
A
This
means
we
need
to
update
the
original
request
with
what
happened
why
it
fit
why
we
believe
it
failed,
and
then
we
kind
of
need
to
dive
into
what
we
can
do
about
this.
If
it
was
a
flaw
in
the
request,
we
should
state
as
much
and
recommend
the
request
or
go
back
to
their
original
support
team
meta
issue
to
rediscuss
this.
A
A
Ask
the
requester
to
you
know,
review
the
test
results:
ask
if
they
want
to
do
their
own
testing
if
they'd
like
to
review
them
or
if
they
want
to
do
their
own
testing
cool,
let
them
if
they
decline,
you
can
move
on.
We
gave
the
opportunity
that's
about
the
best
we
can
do,
but
if
they
do
want
to
test
it,
we
have
to
wait
for
them
to
test
it
and
give
their
results
back
now,
after
testing
is
done,
everything
looks
great.
It's
ready.
We
believe
it's
time
for
production.
Well,
not
quite.
A
We
need
to
actually
set
up
the
repo
to
have
this
done.
Change
done
so
to
prepare
it
you're
going
to
want
to
create
a
merge
request
for
the
corresponding
zendesk
automations
repo
there's
two
different
ones,
one
for
zendesk
global
one
for
us
federal
for
the
existing
automation.
It's
actually
simpler
because
we
already
have
an
automation
file
or
it
has
the
id
from
zendesk
in
it.
You
just
need
to
edit
that
file
and
then
submit
your
merge
request
in
draft
mode
linking
back
to
the
request
that
started
all
of
this
for
newer
automations.
A
The
implementation
date
can
be
determined
because
of
this
process
being
slightly
lengthy.
At
this
point,
we
do
not
set
an
implementation
date
until
this
merger
request
is
in
a
place
where
we
can't
actually
merge
it.
This
is
to
set
the
proper
expectations
of.
We
don't
want
to
say.
Oh
we'll
have
this
done
by
friday.
Well,
testing
failed
and
it's
going
to
have
to
be
delayed.
It's
much
better
to
say:
we
can't
determine
implementation
until
we've
completed
testing
and
got
to
this
repo
stage.
A
A
So
beyond
that
you're
now
in
the
pre-implementation
announcement
stage,
which
is
a
very
long
name
for
just
tell
people
you're
doing
this
thing,
but
once
you've
determined
the
implementation
date,
you
need
to
announce
that.
So
to
do
this,
we
have
a
template,
it's
in
our
training
documentation,
but
it's
basically.
As
per
the
request
of
issue
of
requester,
we
are
planning
to
implement
summary
of
what
we're
doing.
This
is
slated
to
be
done
on
implementation
dates.
The
impact
you
might
see
is
a
you
know,
summary
of
the
impact.
A
So
to
give
you
an
example
of
this,
if
you're
uploading,
a
change
that
adds
the
long-running
ticket
tag
to
tickets,
that
have
not
been
solved
by
the
30-day
mark-
and
this
was
requested
by
you-
know-
google.com.
It
was
requested
via
google.com
by
bob
and
the
implementation
date
is
december.
18Th
1988.
A
The
announcement
would
sound
something
like
this.
As
per
the
request
of
google.com,
we
are
planning
to
implement
sorry
as
per
the
request
of
google.com.
By
bob,
we
are
planning
to
implement
an
automation
that
will
add
little
tag,
long
running
tickets
to
any
ticket
that
has
not
been
put
in
a
solved
or
closed
state
30
days
after
ticket
creation.
This
is
slated
to
be
done
on
december.
A
Now,
once
you've
got
your
message
ready,
you're
going
to
post
it
in
the
support
operations,
slack
channel,
you
also
are
going
to
go
into
the
support
week
and
review.
Google
documents
find
the
thing
the
most
recent
things
to
know
about
section
the
one
for
this
current
week
and
add
that
exact
message
there
as
well.
A
Now,
after
we've
done
this,
we
need
to
cross
link
the
announcement
to
other
channels
now
crosslink
simply
means
grab
the
link
of
the
post
and
then
go
into
the
support
team
chat
and
the
support
managers
channel
and
post
it
there
to
make
sure.
As
many
people
as
we
can
see
this
now,
the
next
stage
is
implementation,
and
luckily,
we've
got
a
merge
request
ready.
This
is
it's
been
approved,
it's
been
reviewed,
so
this
is
actually
the
easy
stage,
because
all
we
have
to
do
is
mark.
A
Now,
after
this,
we
get
to
the
final
stage,
which
is
post
implementation,
announcement
change,
which
is
just
telling
people
that
we've
actually
done
it.
So
your
template
looks
really
simpler
for
this,
that
it
did
for
the
pre-implementation
as
per
request
of
issue
link
of
requester,
we
have
implemented
brief
summary
of
changes.
The
impact
you
might
see
is
brief.
Summary
of
impact.
A
So
that's
our
current
change
management
process
for
zendesk
automations.
I
know
it's
a
bit.
It's
a
lot
to
take
in
and
you'll
kind
of
get
the
hang
of
it
as
you
continue
going,
but
the
training
materials
are
always
good,
doctor
reference
and
then
you've
always
can
reach
out
to
your
fellow
support,
ops,
team
members
or
a
support
option
manager
like
myself
for
guidance
assistance.