►
From YouTube: Support Metrics Analysis Workgroup - 2020-08-25
Description
Discussing approach, hypothesis and desired results.
A
Happy
tuesday,
folks,
it's
meeting
number
two
of
the
metrics
analysis
work
group
group
title
pending,
I
have
started
recording
and
so
the
first
thing
on
the
agenda
is
to
look
at
the
persistent
links,
but
one
of
the
action
items
last
week
was
to
develop
persistent
links.
Elia,
do
you
have
any
update
on
the
dashboard
that
you're
gonna
make.
B
Yes,
it's
the
first
link.
Let
me
show
my
screen
please,
so
we
can
have
it
recorded
as
well.
So
I
haven't
shared
this
across
the
board.
I've
just
shared
this
with
you
so
far,
because
it's
a
definitely
work
in
progress.
I
did
an
a
literal,
mvc
iteration
here
as
we've
discussed,
and
I
have
a
few
questions
about
how
we
want
to
progress
it
from
here
so
as
agreed
up
grouped
them
into
sas
self-managed
and
lnr.
Everything
is,
of
course
applicable
for
changes.
B
I've
added
kind
of
a
red
line
for
the
asset,
so
the
first
one
I
decided
to
present
was
asset
again
we
can
discuss
this
frt
nlt
sell
for
self
manage
same
for
lnr
and
we
have
here
the
support
we
can
review
dashboards
that
we
had
and
one
separate
for
lnr
yeah.
That's
that
that's
kind
of
the
first
iteration.
Obviously
I
have
a
few
questions
about
a.
How
should
we
present
what
else
should
we
add
there
and
yeah?
If
you
can
see
my
questions
there
in
the
talk.
B
Basically,
we're
talking
about,
do
we
want
to
add
ttr
there?
Do
we
want
to
add
frt
median
nrt
median?
Do
we
want
to
add
incoming
ticket
volumes,
because
I'm
thinking
that
these
are
relevant
ones
that
we
might
want
to
see
in
our
main
dashboards?
That
being
said,
we
obviously
have
these
in
the
secondary
dashboard
as
well.
So
it's
just
a
matter
of
deciding.
Do
we
want
to
support
kpi?
I
want
to
be
visible
with
these.
C
My
gut
says
to
shrink
the
scope
to
what
we
want
to
look
at
most
importantly
now
and
then
consider
adding,
as
we
start
to
identify
and
take
action
on
those
pieces,
because
once
I
start
thinking
about
ttr,
I
start
thinking
about
segmenting
ttr
into
you
know
how
many
percentage
tickets
in
this
time
frame
and
and
so
median
doesn't
necessarily
get
us
that
way.
So
I
just
assume
we
probably
look
at
that
separately
after
we
after
we
focus
on
the
the
top
top
areas
that
we
would
start
to
talk
about
already
frt
and.
C
Support
we
can
review
tab
that
provides
the
kind
of
overarching
team,
that's
at
team,
frt,
right
and
then
individually.
So
I
wonder
if
we
can
move
that
to
the
first
tab,
not
just
from
kind
of
it
says:
here's
here's
the
big
picture
and
then
here's
how
it
breaks
down
and
self-managed.
Here's
how
it
breaks
down
into
dot
com
like
you've,
got
it
in
the
first
couple
of
tabs.
C
B
C
B
I
mean
the
idea
is:
is
that
generally
they
are
both
the
same
people,
so
it's
the
same
group
in
effect,
but
these
are
two
completely
different
ticket
forums
and
potentially
in
the
future,
says
general
without
all
the
free
stuff
is
going
to
be
very
much
kind
of
issues
bugs
and
the
admin
stuff
is
still
very
much
pure
admin.
So
I
don't
know
if
we
want
to
take
that
route.
B
F
Yeah,
so
I
was
reviewing
our
kpis
as
well
talking
through
the
team
meeting.
I'm
sorry,
I
kind
of
realized
one
thing
that
I'm
unclear
about:
I'm
not
sure
if
it's
because
I
missed
the
first
part
of
the
meeting
last
week,
he
said
I'm
not
too
clear
on
what
exactly
are
we
looking
at?
So
we
have
a
number
of
hypotheses
that
are
that
have
been
listed
on,
but
they
don't
quite
map
directly
to
a
question
statement.
F
E
B
F
But
it's
within
range
of
the
target
so
for
that
in
particular,
are
we
actually
trying
to
identify
what's
the
normal
band
for
this
matrix,
so
we
don't,
I
guess,
alert
unnecessarily
and
then
for
com.
It's
quite
clear
that
response
times
are
trending
downwards.
The
asset
trend
is
flat
as
well,
but
it's
definitely
not
making
range
of
our
target
so
we're
trying
to
identify
why
these
response
times
are
turning
down
and
are
we
trying
to
determine
what
we
need
to
do
and
therefore
measure
to
get
closer
to
our
asset
target
yep?
B
A
A
So
I
think
there's
going
to
be
a
a
set
of
actions
that
are
more
long-term,
like
resource
appropriately.
Have
a
good
staffing
model
make
sure
that
we
have
enough
people
working
this
class
of
tickets
and
then
there's
going
to
be
some
developing
like
the
developing
the
graphs
and
sort
of
like
the
playbook,
where
it's
like.
This
doesn't
look
good.
Look
at
this.
Do
this.
C
Yeah,
I
called
second
that
file.
I
think
it
it
boiled
down
to.
We
can
look
really
good
at
a
very
top
level,
but
then
have
I
identify
problems
in
subsets
of
what
we're
doing
and
and
need
to
figure
out.
What
does
that
triggering
look
like
right
and
without
going
into
the
detail
so
for
now,
what's
kind
of
initiated?
This
is
the
downward
trend
on
sas.
Frt
I
mean
below
below
90,
I
think,
is
a
secondary
trigger,
I
would
say,
below.
93
of
target
would
be
initial
trigger.
C
C
The
total
look
of
supports
for
performance
to
keep
kpis
as
a
as
a
global
team
right,
because
that
percentage
just
doesn't
it
doesn't
impact
the
overall
percentage
enough.
I
would
say
similarly
with
with
sat,
is
you
know
if
we
start
trending
down
that's
a
trigger?
If
we
trend
down
and
maintain
underneath
93,
I
think
that's
another
trigger,
and
so
you
know,
then
you
start
to
look
at.
C
What's
underneath
that
right,
so
first
wave
I'll
just
kind
of
realize
what
I'm
thinking
the
first
wave
is
you
look
at
it
in
total,
so
yeah
yeah
we're
doing
great
as
a
as
a
as
a
global
team,
and
then
you
look
at
the
tabs.
How
are
we
doing
in
self-managed
great
we're
doing
self-managed
how
we
doing
in
dot
com?
C
I
think,
as
you
as
you
peel
it
apart,
the
the
data
becomes
more
refined,
so
yeah
we
look
at
dot
com
and
we
say
okay.
Now
we
got
to
go
look
at
where
you
know
what
what
are
the
segments?
What
are
the
pieces
and
parts
within.com
that
are
influencing
the
total,
because
I
remember
back,
you
know
in
the
not
too
distant
past
we
were,
you
know,
not
getting
basically
sufficient
enough
csap
surveys
from
gold
customers,
so
you
know
one
bad
csat
out
of
10
and
you
know
we
only
got
10
so
that
we
are
90.
C
A
F
A
F
F
So
would
these
three,
I
guess
questions
be
how
we
frame
how
we
think
about
the
hypothesis
that
we
are
working
through
as
well
as
how
we
generate
hypothesis
or
are
there
other
questions
that
should
be
top
of
mind
that
that
have
not
yet
been
put
down
because
yeah
I
mean
my
policies
are
all
designed
to
answer
a
question
and
I
kind
of
realized.
We
don't
have
those
questions
explicitly
put
down
if
you
get
one.
A
D
C
E
C
E
F
A
A
E
A
Are
you
seeing
the
metrics
analysis,
doc,
yep,
okay,
good,
normally,
there's
the
green
bars
and
those
just
have
not
are
not
on
there?
Okay.
So
our
guiding
questions
are
usual
bands
for
frt
and
rt,
and
sat
trying
to
identify
why
they're
trending
down
and
determine
what
we
need
to
do
and
therefore
measure
to
get
closer
to
95.,
so
hypothesis
number
one
was
ticket.
Volume
was
too
high
to
consistently
achieve
frt.
A
This
is
a
half
try.
I
didn't.
I
honestly
didn't
try
very
hard
to
answer
this
because
we
hadn't
assigned
anything
out
well,
not
because
we
hadn't
seen
anything
out
yet
just
because
I
wanted
to
take
a
look
at
the
data.
So
I
took
a
look
at
frt
performance
for
selfmanagement.com
and,
like
we
may
noted
earlier,
for
self-managed
we're
pretty
consistent
across
the
board
well
above
target.
A
So
my
conclusion,
without
looking
at
volume,
is
that
we
have
enough
engineers
to
manage
to
achieve
consistent.
Freq
performance
for
com
were
below
target
since
october
last
year,
which
was
a
bit
of
a
shock
to
me
actually
embarrassingly,
and
so
my
conclusion
there
is
that
there's,
probably
not
enough.
This
doesn't
seem
like
too
well
of,
but
I
think
there's
probably
some
more
analysis
we
could
do
here,
but
continuing
on
if
nobody
else,
nobody
has
anything
to
say
about
that.
A
C
E
A
F
C
D
C
Right
then,
that
may
influence
your
ability
to
do
a
first
replay.
So
you
know
it's
first,
it's
kind
of
first,
let's
look
at
how
how
far
off
are
we
missing
the
the
first
reply,
time
right
and
then
bring
that
back
down
say?
Is
that
because
of
the
volume
of
replies
we're
having
to
do
and
all
these
other
tickets
we're
missing
the
the
first
one.
B
B
A
C
C
B
Well,
I
think
it's
a
worthwhile
exercise
to
try
to
pinpoint
tickets
that
are
taking
maybe
longer
I
I
know
for
an
l
r
as
a
fact
that
we
managed
to
identify
a
few
types
of
tickets
that
take
way
too
long.
For
instance,
they
escalated
tickets
to
sales,
or
so
what
I'm
trying
to
say
is
that
we
can
break
down
the
ticket
types
to
specific
problem
types,
and
maybe
we
can
lean
some
information
from
there.
A
C
Up
from
a
ratio
perspective
right,
if
tickets
aren't
influenced
by
customers
going
on
pto
or
whatever,
and
they
kind
of
remain
consistent,
the
more
people,
and
because
we
have
fewer
people
in
general
that
are
sas
focused
that
that
number
will
definitely
impact
the
ratio
of
people
to
ticket
availability
and
again,
especially
if
we
go
into
specific
regions
and
find
that
there's
only
two
people
and
one
person's
on
you'd
be
lost.
50
percent
of
the
people
looking
at
sas
tickets
as.
B
C
D
B
A
A
A
B
A
B
C
Yeah,
I
would
roll
it
in.
I
think
it
would
be
eventually
useful
to
let
people
know
in
the
executive
world
that,
when
we,
when
we
put
these
things
together,
you
know
support
wants
to
participate,
but
it
just
basically
becomes
a
pto
some
other
day.
It's
not
really
it's
just
weird
and
here's
the
impact
to
it.
F
I
I
think
this
is
slightly
different
in
that,
so
I've
been
kind
of
investigating
this
separately
before
this
working
group,
and
I
am
starting
to
see
data
that
suggests.
Maybe
we
have
the
right
well,
we
have
the
capacity
it's
just
not
evenly
distributed
throughout
the
day.
I
suspect
in
every
region,
support
engineers
kind
of
take
the
foot
off
the
pedal
towards
the
end
of
their
day
and
that
results
in
a
nasty
situation
during
the
region.
F
We
are
not
looking
at
overall
the
pc;
instead,
we
are
looking
at
even
if
we
do
have
the
availability.
What
is
that
distribution
of
the
availability
spread
over
our
coverage?
I
suspect
it
might
not
be
evenly
distributed,
and
then
we
end
up
with
with
hot
spots,
where
breaches
are
more
likely
to
happen
anyway.
That's
my
theory.
A
B
B
C
Youtube
sorry
trying
to
find
my
right
screen
rebecca.
I
got
my
one-on-one
rebecca
she's
texting
me
too.
So
I
mean
I
don't
know.
I
leave
that
the
the
team
I
mean
it
does
put
a
visual
together
to
you
know
what
we're
what
we
need
to
look
at
rather
than
saying.
Well,
we've
got
our
target
listed.
Let
me
see
where
it's
at
and
does
it
associate
to
the
trigger,
so
I
think
it
does.
From
my
perspective
it
does
visualize
it
better
so
that
we
can
see
it
so
yeah.
A
So
what
we're
doing
right
now
is
we're
going
through
the
hypotheses.
Women
gave
us
some
guiding
statements
and
we're
taking
a
look
to
see
if
they
match
up
with
sort
of
the
purposes
for
the
group,
and
then
the
next
thing
we'll
do
is
actually
assign
these
out
for
folks
to
investigate
and
report
on
right
now
we're
on
number
five
and
I
hypothesized
that
adding
lnr
has
drawn
resources
away
from
the
rest
of
the
queues
that
haven't
been
renewed
or
replenished
is.
A
G
I
guess
we
can.
We
can
actually
go
and
check
the
figures.
We
can
go
and
look
at
the
people
who
are
working
in
the
queue
and
maybe
just
seeing
what
form
of
tickets
they're
doing
so
even
if
they're
saying
they're
doing
50
is,
is
that
accurate
doesn't
matter
if,
if
they're,
maybe
doing
more
eleanor
than
the
race,
but
it
would
be
good
to
know
that
hey
actually
sixty
percent
of
the
tickets
that
they're
doing
are
actually
eleanor
and
only
forty
percent
is
for
for
the
other
queue.
G
So
we
actually
can
get
the
data
on
this
so
yeah.
I
do
think
that's
that's
very
valid.
To
get
some
people
I've
seen
they
say
they
are
they're
busy
ramping
up
on
eleanor.
So,
even
though
the
goal
is
to
get
to
50
50
they're
still,
maybe
like
80
percent
in
the
other
queue
and
just
20
in
eleanor,
so
I
think
it
would
be
good
to
get
some
real
numbers
on
that
and
just
see
where
people
are
at
yeah.
B
B
B
G
I'm
just
thinking
public
replies,
and
I
they
even
say
internal
comments
are
things
that
take
time
and
a
lot
of
people
that
are
getting
up
to
speed
in
illinois
would
leave
comment
internal
comments
instead
of
public
replies,
and
that
is
time
that
they're
spending
investigating
and
then
leaving
the
comment.
So
I
think
it's
it's
fair
to
say
that
they're,
if,
if
you're,
taking
10
minutes
or
so,
to
investigate
and
leave
a
comment,
that's
still
work
that
your
time
you're
spending
on
eleanor
instead
of
the
other
queue.
G
So
it
makes
sense
for
me
to
for
us
to
take
that
into
consideration.
You
know
when
we're
working
on
how
much
time
is
someone
spending
on
which
queue.
I
think
that's
just
to
answer
the
question
of
that.
The
hypotheses
that
cues
haven't
been
replenished,
so
it's
taking
away
from
from
those,
and
I
I
want
to
say
yes,
that
is
the
case.
But
to
what
extent,
I'm
I'm
not
sure-
and
I
think,
looking
at
public
replies
and
internal
comments,
even
as
a
measure
of
someone
spending
time,
could
could
be
useful.
A
That's
a
good
note
number
six
I
was
saying
frt
hawks
spending
more
time
on
needs
or
ticket
is
causing
a
different
performance.
This
is
a
common
complaint
from
frt
hawks
the
common
complaint
from
frt
hux
that
needs
our
tickets,
like
the
workflow,
is
quite
different
than
actually
answering
the
tickets
and
it's
time
consuming
and
there's
a
lot
of
them.
A
I
think
what
they're
saying
is
is
that
we
wouldn't
even
look
at
the
needs
or
tickets
until
we
have
the
ones
that
already
have
orgs
and
so
they're
spending
enough
time.
Getting
the
first
replies
out
that
needs
org,
isn't
even
a
consideration
because
we're
we're
looking
at
the
ones
that
have
orgs
already
then
adding
the
orgs
after
the
fact
is
that
right.
A
A
B
B
The
sla
I'm
not
I'm,
not
sure
if
the
sla
there
is
not
well,
I
might
check
for
ticket
tax,
but
again,
I'm
not
sure
if
the
sla
starts
counting
from
the
beginning
of
the
ticket
or
from
when
you
edit
the
tag.
So
it's
possible
that
when
you
add
the
tag,
it
only
starts
calculating
sla
from
once
you've
organized
it.
I'm.
F
My
question
is:
is
there
a
way
to
actually
measure
this,
the
the
phenomena
where,
when
you
change
text
or
where
you
change
well,
when
you
associate
a
organization
it
breaches
right
away,
because
I
mean
anecdotally,
there
have
been
people
who
are
newer
to
meet,
who
have
been
doing
this
and
they
don't
realize
that
this
is
happening.
So
it's
not
just
about
engineers,
managers
but
kind
of
looking
into
this
is
when
then
they
associate
and
then
oh
it
reached
by
8
hours
right
away.
B
A
A
A
Is
that
true?
I
think
it
seems
true,
but
it
might
be
nice
to
measure
the
effect
catalan
had
one
in
number.
Eight
moving
to
ticket
assignment
has
created
an
environment
where
essies
aren't
incentivized
towards
global
metrics.
I
should
have
actually
linked
the
slack
thread
where
this
was
discussed,
because
it
was
a
much
larger
thought,
but
the
idea
was
that
people
are
very
focused
on
the
tickets
that
have
assigned
to
themselves
and
aren't
as
aware
of
like,
what's
going
on
site
yeah,
that
it
would.
B
F
A
B
A
A
Hypothesizing
that
engineers
are
spending
most
of
their
time
on
tickets,
to
sign
it
themselves,
so
in
the
how
to
work
on
tickets,
workflow
I
forget
is
that
the
right
name
for
it
anymore
names
are
hard,
but
we
suggest
that
engineers
should
keep
a
balance.
50
of
replies
should
be
on
tickets
assigned
to
yourself.
50
should
be
on
tickets
that
are
either
that
are
assigned
to
other
people,
and
so
my
guess
is
that
similar
to
number
eight
is
that
folks
are
not
striking.
That
balance.
We're.
E
A
A
As
long
as
you
get
back
with
the
customer
tomorrow,
and
if
you
focus
your
time
on
somebody
else's
ticket,
that's
going
to
breach
soon
that's
going
to
cause
our
metrics
to
go
up
like
because
that's
those
are,
I
would
assume
tickets
that
haven't
had
the
communication
that
explains
sort
of
like
what
what
the
state
of
the
ticket
is.
What's
going
on,
it's
customers
who
are
wondering
what
what's
happening,
but
I
mean
it
yeah.
A
I
think
that
there's
there
it
if
everybody
is
perfectly
selfish
and
takes
on
only
their
capacity
and
answers
their
ticket
within
sla
times.
Every
time,
then
that
system
works
and
if
we
have
total
chaos-
and
everybody
only
looks
at
the
next
most
urgent
thing,
then
that
would
that
could
also
work
and
it
did
work
in
a
much
smaller
team.
B
B
B
F
A
B
G
A
A
B
A
If
there
is
any
kind
of
conclusion,
whether
it's
positive
negative
or
needs
more
data
like
that's,
where
we
want
to
get
to
on
each
of
these
by
the
next
time
we
meet
cool
our
exit
criteria.
I
updated
in
our
handbook
working
page
I'll,
do
another
update
today,
but
just
I
want
to
remind
everyone
what
they
are,
because
actually
I
forgot
what
they
are.
A
A
So
exit
criteria
is
defining
conditions
under
which
this
work
group
will
be
reformed.
We
still
have
not
done
any
of
that,
create
a
dashboard
that
exposes
metrics
and
targets
that
will
trigger
actions
on
part
of
the
support
team,
we're
probably
like
40
there.
I
think,
as
a
result
of
ilia's
work
and
document
common
hypotheses
and
exposed
data
to
support
and
refute
them.
That's
what
we'll
be
working
on
over
the
next
couple
of
weeks.
Are
there
any
other
exit
criteria
that
we
should
consider
that
have
come
up
as
a
result
of
today's
discussion.