►
From YouTube: Emilie S. and Taylor M. discuss the open Zendesk SLA MR
A
Great
so
context
we
are
going
to
talk
through
the
SLA
calculation
for
Zendesk,
mr
this
introduces
the
SLA
policies
table
which
we
were
not
previously
using,
and
the
goal
is
to
match
our
numbers
to
have
to
what
the
support
team
is
currently
reporting:
fair,
characterization,
creative.
So,
let's
start
with
SLI
policy's
table.
B
A
B
A
So
I
went
back
and
forth
on
the
best
way
to
do
this,
and
then
the
detail-
that's
important
here,
like
let's
look
at
how
these
other
policies
are
set
so
premium
and
ultimate
or
gold
and
silver.
The
way
these
SLA
sir
set
is
based
on
the
organization
tag.
So
in
an
ideal
world,
where
you
know
it's
always
based
off
a
certain
criteria,
then
we
could
have
it
reference.
A
The
specific
the
specific
policy
but
like
so
the
one
thought
I
had
was
moving
this
case,
one
statement
into
here
and
then
kind
of
like
case
when
this
is
true
its
premium
case
when
this
is
true
its
ultimate
case
when
this
is
true
its
emergency.
But
the
problem
with
that
approach
is
that
we're
hashing
the
recipient
email
addresses,
because
we
want
people
to
know
which
support
rep
is
answering
it.
We're
also,
you
know
so
we're
masking
that
information
in
the
interest
of
privacy,
and
so
that's
why
that's
happening
in
the
base
model.
A
The
other
advantage
to
doing
it
this
way
and
I
think
we
talked
about
this
a
little
bit
asynchronously
is
that
we've
identified
that
some
tickets
have
both.
They
meet
the
emergency
SLA
criteria
and
the
the
ultimate
premium,
gold
and
silver
SLA
criteria
and
I'm,
pretty
sure,
they're
being
counted
in
both.
So
these
two
things
have
to
be
distinct.
A
ticket
can't
just
have
like
an
SLA
policy,
one
off
column
attached
to
it.
Since
tickets
can
have
multiple
SLA
policies,
yeah.
B
That's
fair,
and
that
makes
sense,
because
I
think
SLA
is
just
like
a
bucket.
Not
it's!
It's
a
non
meet
si
bucket
yeah.
Definitely
quick
question
on
the
recipient.
Is
we're
hashing
the
recipient,
but
that,
based
on
what
I
see
here
seems
like
it
that's
information
about
gitlab.
Is
that
accurate
or
is
recipient?
Sometimes
you.
B
A
So-
and
you
know,
that's
not
something
I
changed
I
did
add
that
we
were
hashing
the
subjects
it's
a.
It
included
some
customer
information,
but
I
didn't
make
that
change
and
I
I
think
we
would
have
to
to
support
before
we
moved
it
up.
I,
don't
think
like,
because
everyone
Idealab
has
access
to
Zendesk.
We
can
see
most
of
these
tickets.
A
A
You
know
like
there's
no
pattern
to
them.
I
didn't
think
it
made
sense
to
kind
of
Dean
s
them
all.
Given
the
fact
that
I
did
visually
inspect
all
the
tag
names
to
make
sure
there
were,
there
wouldn't
be
collisions,
so
there
isn't
like
prospecting
premium,
that
we
need
to
worry
about
affecting
the
SLA
numbers
at
this
time
it
might
be
worth
adding
a
custom
test
to
confirm
that
that's
not
the
case
in
the
future,
but
this,
mr,
doesn't
do
that.
So
what
we've
done
here?
We
take
the
SLA
policy.
A
A
C
A
That
being
said,
there
is
a
lot
in
this
model
that
was
useful,
especially
these
values.
So
this
is
a
field
that
sounds
like.
Is
this
else
SLA
metric
for
business
hours
or
not
either?
I'm
sorry.
Did
this
ticket
come
in
on
business
hours?
So
do
we
care
about
business
hours
or
regular,
like
calendar
hours
and
this
hours
here
and
I
misspoke
these
cap
hours
here
are
actually
a
mist
over
its
minutes.
A
It's
actually
at
it
now
so
don't
forget,
then
the
metric
is
the
number.
The
priority
is
the
priority
attached
to
the
ticket
and
then
the
term
it
is
what
the
the
SLA
is
I
think.
So,
okay,
then,
after
that,
the
only
change
to
the
ticket
model
is
adding
me:
has
emergency
SLA,
boolean
truthful
or
not
a
boolean,
we
add
the
ID.
Originally
it
was
a
boolean.
A
We
change
it
to
media
I
changed
it
to
me
the
ID,
because
we
join
to
get
kind
of
those
other
metrics
that
those
of
that
other
metric
information
in
a
join
down
stream.
So
we
look
at
the
Zendesk
tickets
model.
This
is
where
the
bulk
of
the
work
here
was
done,
the
XF
model,
what
changed
are
kind
of,
so
there
are
a
couple
pieces
one
previously
we
were
taking
first
to
apply
time
from
a
couple
different
places
and
that
failed
to
incorporate
business
hours
versus
calendar
hours.
A
Now
that
we're
going
to
use
the
SLA
policy
to
tell
us
whether
or
not
it
needs
to
be
business
hours
or
calendar
hours,
we
needed
both
of
those
times
brought
into
here.
We
added
a
reference
to
SLA
policies
and
we
currently
only
care
about
first
reply.
Time
base
that
the
ticket
that
we
got
from
talked
me.
A
We
pull
an
organization
text
since
that's
the
criteria
for
premium
ultimate
gold,
silver,
and
then
here
we
so
we
take
the
existing
ticket
except
ball.
Now
we're
going
to
join
to
the
SLA
policies
table
on
the
SLA
policy,
ID
from
the
SLA
policies
table
to
the
policy
provided
in
either
the
emergency
SLA
or
the
premium
ultimate
bold
messily,
and
we're
matching
on
the
priority,
because
the
SLA
tickets
have
different
metrics
on
whether
it's
priority
high
medium
low
independent
of
the
tier
of
the
product
that
you're
getting
or
the
tier
of
support
here.
A
B
A
So
late
right,
a
couple
different
things
and
I
was
able
to
get
some
of
them
in
double
buckets.
If
you
go
through
the
history
you'll
see
like
this
is
actually
two
rebus
joins
previously
where's
like
on
this
equals
this,
and
this
equals
this
or
this
equals
this,
and
this
equals
this
and
that's
not
the
numbers
closer,
but
it's
still,
they
can
get
it
right.
A
B
A
B
A
Yeah
yeah,
the
other
reason
I
did
it
this
way,
and
this
hasn't
been
merged,
so
you
know
feel
free
to
do
it
any
way
that
you
think
is
best
is
that
I
was
trying
to
fit
this
previous
model
of
this
was
ticket
was
support,
SLA
met
of
the
true/false
so
that
we
didn't
have
to
change
anything
downstream.
Yeah
I'm,
not
sure
that
that's
gonna
be
possible.
B
A
So
this
is
pretty
straightforward.
It's
just
saying
when
that
policy
metrics
business
hours.
True,
then
use
the
business
our
reply
time
when
it's
false
isa
calendar
our
reply.
Time
use
that
as
first
reply
time
and
then
pipe
first
reply
time
into
the
metrics
target
number
Nick,
it's
less
than
or
greater
than
as
whether
or
not
that
was
met,
and
then
include
the
SLA
title,
which
is
the
name
emergency
fold.
That's
part
of
what
we
get
from
doing
this
join.
A
So
this
model,
as
it
currently
stands,
does
so
I
did
add
the
additional
SLA
thing
to
the
sources.
I
am
alone
at
Lourdes,
but
as
it
currently
stands,
I
did
not
have
to
change
that
primary
key
test
to
the
tickets
@xf
model.
All
the
additional
changes
to
the
schema
Diana
are
introducing
the
new
SLA
policy
I'm.
Also.