►
From YouTube: Support - Metrics Analysis Workgroup - 2020-09-15
A
Happy
tuesday,
folks
september,
the
15th
right
yes,
tomorrow
is
my
wife's
birthday.
I
should
know
this.
It
is
the
15th
metrics
analysis
working
group.
Every
time
we
take
a
look
at
the
persistent
link
items.
If
you
took
a
look
at
our
agenda,
it's
changed
quite
a
bit.
I
did
a
lot
of
work
yesterday,
getting
things
into,
hopefully
an
easier
to
read,
state
and
moving
things
out
into
issues.
Elia.
Do
you
want
to
take
us
through
our
dashboard.
B
Thank
you,
of
course,
donique
is
joining
as
well
right,
so
I've
made
a
few
changes
as
requested
actually
two
weeks
ago,
but
sorry
I
just
got
to
that
this
time
so
support
we
can
view.
Is
the
first
tab
there's
going
to
be
a
split
of
says,
general.
I
didn't
know
how
to
name
it
better.
So
I
just
named
it
says
general,
and
there
is
a
split
between
that
and
says
accounts.
A
C
A
D
D
A
B
Yes-
and
I
also
had
an
additional
hypothesis
that
it
might
be
related
to
how
we
are
managing
the
frt
hawks
specifically
in
sas-
that
that's
something
that
we
might
want
to
look
at
kind
of
on
a
more
immediate
basis
might
help,
because
in
self-managed
it
seems
to
be
helping
quite
a
lot
and
dot
com
will
never
really
introduce
the
coherent
policies.
Regarding
that.
B
B
D
E
B
B
Yes,
hopefully
joining
yeah,
the
zoom
call
in
case
they
need
assistance.
My
suspicion
is
that,
and
I
keep
hearing
it
anecdotally
from
individuals
that
they
don't
necessarily
know
how
to
handle
the
dot
com
fltq.
So,
even
though
that
we
have
asking
the
self-managed
to
deal
with
the
fot.com
queue,
I
don't
think
they
have
the
capacity
or
maybe
don't
feel
comfortable
and
having
even
one
person
available
there.
B
C
Okay,
so
I
think
we
it-
I
guess-
there's
probably
another
week
or
two-
that
we
can.
I
think,
confidently
see
the
impact
of
the
free
user
changes.
So
if
we
don't
see
improvement,
if
we
see
even
level,
then
I
think
we
got
to
relook
at
the
actual
staffing
are
the?
Is
the
crew
thing
being
tested
next
week,
or
is
that
still
under
discussion
of
timing.
B
C
C
B
C
Well,
yeah,
and
what
I'd
be
concerned
about
a
little
bit?
Well,
not
just
a
little
bit
that
I'd
be
concerned
about,
is
hiring
getting
them
on
board
and
then
seeing
the
drop
in
tickets
and
having
to
find
additional
work
for
them
to
do,
but
that
there
won't
be
l
in
our
work
for
several
more
months.
But.
A
Yeah,
it
seems
like
no
yeah
and
I'm
gonna
be
talking
with
that
data,
but
just
based
on
the
sean's
hiring
model,
it
looks
like
we
need
to
add
the
most
folks
in
emea,
and
so
I,
if
the
way
that
india
is
going
to
solve
that
problem,
is
support
crew.
Then
I
think
that's
great.
Let's
do
it
all
right
the
number
of
full-time
engineers
we
would
need
to
add
in
america.
A
I
think
in
the
americas
is
like
one
and
a
half
which
I
think
we're
basically
already
doing
just
with
folks
getting
onboarded
between
three
of
our
newer
staff
members
who
are
already
doing
the
hybrid
so
wayman
do
you
know
off
the
top
of
your
head?
How
many
folks
you
like
in
sean's
model,
you
would
need
to
add
to
sas.
A
A
A
We'll
work
on
that
through
the
managers
think
item
number
two.
I
created
a
project
to
pull
out
the
investigation
notes
from
the
stock,
so
you
can
take
a
look
at
the
issues
in
there.
I
I
linked
them
also
above
in
the
hypotheses.
I
did
make
a
cut
line
where,
like
we
had
added
some
additional
ones
that
we
weren't
taking
a
look
at
yet
so
if
we
want,
I
can
create
issues
for
those
as
well.
A
I
just
thought:
let's
get
the
ones
that
were
actively
working
in
there
and
then
we
can
add
some
more
later.
I
also
added
a
board.
It's
not
supremely
amazing.
I
also
added
a
milestone,
which
is
also
not
supremely
amazing
as
a
view,
but
they
do
exist.
If
that's
how
you
prefer
to
consume
them
and
then
number
four,
I
have
a
request.
Can
we
change
the
meeting
time
for
this?
A
C
A
C
A
B
Speaking,
okay,
dashboard
updated,
we've
shown
new
hypothesis
dimension.
That's
the
efforty
inconsistency
between
the
groups,
I
mean
again
just
twitter.
It
yeah
and
self-managed.
We've
seen
significant
improvements,
introducing
the
dot
com.
Yes,
of
course,
they're,
not
loaded,
but
I
do
feel
that
introducing
a
kind
of
a
push
on
flts
and
end
of
this
specifically
com
might
give
us
some
alleviation
there
and
the
assignment
model.
So
I
had
a
call
with
greg.
Last
week
we
went
over
a
bit
of
information.
These
are
just
screenshots
of
a
few
reports.
B
Basically,
they
are
indicating
that
a
ticket
when
it
is
assigned
the
median
resolution
time
sorry,
the
median
nlt
times
for
it
is
lower,
so
the
ticket
is
assigned.
We
respond
to
them
quicker,
regardless
of
preferred
region
so
for
all
regions,
tickets
or
regional
tickets
as
well
get
a
lower
nrt
for
assigned
tickets.
This
is
regarding
the
hypothesis.
A
This
will
you
report
this
in
the
managers
meeting.
I
think
this
is
something
that
we
should
message
across
regions
and
teams
and
say
like
understand
your
resistance,
understand
the
confusion
between
how
to
handle
assigned
tickets
for
all
regions.
But
if
you
look
at
the
data,
it's
not
as
bad
as
it
feels.
D
I
just
want
to
mention:
I
quickly
had
a
look
at
the
just
the
frt
for
l,
r,
just
for
september
so
far
15
days
and
it's
an
83.4
which
is
massive
massive
increase.
So
the
thing
I've
been
feeling
is
yeah,
it's
definitely
showing
up
in
the
stats
so
yeah.
I
think
just
some
evidence
that
we're
on
the
right
track.
There.
A
A
B
A
Number
two
it
was
assigned
to
me.
We
closed
that
one
out,
we're
saying:
well,
I'm
I'm
moving
the
the
data
doesn't
support
that
hypothesis.
So
I
don't
have
to
talk
about
that.
One
number
three
folks
on
pto
over
summer
and
friends
and
family
days
who
cause
lags
and
performance
elia.
Do
you
have
anything
on
or
is
that
mine.
B
A
I
mean
at
least
generate
the
issue
of
develop
a
standard
way
of
handling
high
time
off
days
right
now,
it's
very
informal
right
and
we
try
and
take
a
look
at
the
past
data
when
we
remember
there's
a
holiday
but
there's
definitely
an
improvement
that
could
be
made.
Is
that
a
follow-up
item
from
this.
C
I
I
think
so
I
think
it's
just
it's
document
what
we're
doing
to
track
and
to
schedule
and
how
we're
trying
to
improve
the
impact
of
how
we're
scheduling
against
what
really
happens
and
the
ticket
data
right.
There's
you
know,
yep
friends
and
family
day.
We
take
the
next
three
two
three
weeks
to
get
everybody
through
their
own
day.
We
have
two
to
three
day
three:
three
weeks
of
data:
to
try
to
sift
through
to
see
what
was
the
impact
of
that
day
right
and
that
has
to
it
has
to
go
again.
A
Pieces,
I
will
add
those
notes
to
the
issue
and
then
we
can
close
out
the
hypothesis
itself
and
create
some
follow-up
issues.
Number
four.
Our
staffing
isn't
spread
appropriately
versus
the
number
of
tickets
that
are
raised
or
will
reach
per
hour
we're
not
asking
folks
to
work
the
right
set
of
hours.
Ilia
do
you
have
an
update
on
that
one.
A
E
E
India
helped
me
with
getting
like
the
averages
and
standard
deviations.
So
thank
you
for
that.
Before
we
go
in,
I
want
to
emphasize
that
I'm
not
100
sure
that
the
data
is
correct
or
that
it
serves
as
a
proxy
measurement
for
stuffing,
but
it
seems
promising
so
major
caveat
there.
So
I'm
not
sure
if
you're
familiar
with
spark
lines,
but
the
thing
with
start
lines
is
that
the
important
thing
about
them
is
that
we
look
at
the
shape
of
the
curve
and
not
the
actual
numbers
itself.
E
E
So
you
can
see
that
basically,
there
are
high
number
of
breaches
in
the
early
hours
of
apec,
which
doesn't
surprise
me
because
there's
a
known
gap
in
terms
of
com
coverage
and
then
it
kind
of
picks
up.
I
think
this
is
about
1
pm
utc,
so
I
think
this
serves
as
a
decent
proxy
measurement
for
maybe
staffing
issues,
but
at
the
very
least
it
tells
us
where
pin
points
are
in
terms
of
tickets,
not
being
addressed.
E
So
just
to
give
you
an
illustration
of
why
it's
important
that
we
look
at
the
shape
of
the
curve,
and
we
also
need
additional
data
to
sort
of
give
context
to
that.
If
you
look
at
the
self-managed
one,
you
can
kind
of
see
it's
pretty
spiky,
but
look
at
the
percentages.
Definitely,
though
so
in
actual
fact,
I
don't
think
there's
much
optimization
we
can
do
for
self-manage.
E
E
Again,
I'm
not
sure
about
the
valid
validity
of
the
data,
but
what
we?
What
I
plan
to
do
is
that
this
actually
gives
us
a
slightly
more
responsive
view
of
how
performance
is
doing,
and
this
is
basically
week
by
week
and
what
I've
done
is
I've
filtered
ticket
beaches
that
occurred
during
apac
hours,
so
you
can
kind
of
see.
E
The
idea
here
anyway,
is
that
as
managers,
you
can
look
at
this
and
then
get
a
feel
for
yeah.
You
know:
is
our
team
doing?
Well,
and
what's
the
trend
looking
like
so
for
self-managed
frt-
and
you
know
next
response
both
are
looking
okay
but
yeah,
I
mean,
I
think
we
know
that
com
isn't
doing
too
well
and
we
can
also
see
that
downward
trend
in
frt
as
well.
E
So
the
problem
with
both
of
these
right
now,
the
sparklines
and
this
slightly
more
responsive
dashboard
that
I'm
building
and
we'll
be
testing
out
in
the
next
few
weeks
is
that
well,
it
gives
us
knowledge
that
there
is
a
problem
yeah.
It
doesn't
tell
us
what
we
can
do
about
it.
So
that's
that's
something
yeah,
I'm
still
figuring
out
so
yeah.
That's
that's
my
latest
view
here.
C
This
is
great
because
I
think
this
takes
what
we've
very
loosely
done
is
just
took
creation
times
of
tickets
and
associated
staffing
in
those
creation
times
per
region.
What
we
haven't
done
is
shifted
into
regions
into
the
region
itself,
where
we
need
to
hire
to
be
more
efficient
and
more
performant.
If
you
will
so,
I
think
if
we
took
the
combination
of
this
data
and
said
okay
well,
what
locations
should
we
focus
hiring
on?
A
Shifts
or
even
just
different
activities
at
different
hours
so
like,
for
example,
in
the
past
in
amer
west,
we
we
had
a
sort
of
like
the
last
hour
of
your
day,
was
clear
out,
breachers
and
give
apec.
You
know
clear
out
the
red
so
that
apac
has
wakes
up
happy,
even
if
we
had
something
like
that.
While
we
look
for
staff
like
this,
this
exposes
where
we
need
to
do
that.
E
A
D
Well,
I
think,
actually,
maybe
we've
we've
gone
to
a
place
where
we
can
say
there
is
an
impact
and
we
could
say
that
this
percentage
of
size
work
that
we
that's
reasonable
to
say
that
that's
taking
away
a
percentage
of
source
work
that
could
have
gone
to
the
sask
queue.
So
I
almost
want
to
say
this
is
true
to
a
degree
and
we
can
throw
the
percentage
out
there.
D
We
can
say
eight
percent
or
I
can
maybe
we
can
dig
in
deeper
and
I'm
not
sure
what
else
there
is
to
look
at,
but
maybe
getting
more
months.
Yeah.
From
my
point
of
view,
I
feel
like
we
have
something
here
where
I'm
comfortable
to
say
there
is
an
impact
to
a
degree.
It's
not
massive,
but
there
is
an
impact.
So
I
don't
want
to
say
this
is
completely
false.
D
So
my
I
guess
where
I'm
at
is
okay,
it
looks
like
there
is
an
impact,
but
how
much
more
do
we
want
to
know?
Do
we
need
more
information
about
exactly
what
that
impact
is?
Do
we
want
to
do
anything
with
the
sus
percentage
yeah?
I
feel
like
it's
it's
usable
and
if
we're
not
going
to
use
it
then
yeah
we
can
close
it
out,
but
I
do
feel
like
there's
something
there.
It's
not
completely
false.
A
C
D
C
Yeah,
I
just
I
think,
there's
there's
an
element
of
we
prioritize
the
whatever
you're
coming
back
and
looking
into
what
we
need
to
do
right.
We're
going
to
appreciate
that
yep
we
take
resources.
We
rob
peter
to
pay
paul
peter's
going
to
suffer
right,
so
it's
just
a
matter
of.
Is
it
a
black
guys
or
the
hangnail?
C
A
D
D
A
Number
six
is
mine,
wait
is
it.
Where
are
these?
I
don't
know
where
these
things
came
from.
Yes,
it's
mine,
okay,
if
rtx
spending
more
time
and
needs
org
is
causing
a
different
performance.
I
don't
have
any
update
on
this.
One
number
seven
is
closed
out
as
not
supported
us
federal
has
not
had
a
significant
effect
on
our
overall
metrics
and
where
are
we
in
the
agenda.
A
A
A
Okay,
so
our
exit
criteria-
number
three
all
right
number
two
is
like
create
a
dashboard
that
exposes
metrics
good
targets
good,
but
what
actions
get
triggered
when
things
go
down?
That's
what
I
would
like
to
talk
about
for
just
maybe
a
couple
of
minutes
and
figure
out
how
we're
going
to
tackle
that
piece
of
our
exit
criteria,
so
wang
wingming,
you've
already
built
something
where
I
think
your
intention
is
to
trigger
some
action
when
things
go
down.
A
E
Yes,
it's
a
bit
so
the
reason
why
I
built
this
that
dashboard
that
I
showed
earlier
is
because
in
apac
we're
trying
or
going
to
try
an
experiment
where
we
just
remove
the
sla
hot
roll
entirely
and
we're
doing
that
of
necessity.
Just
because,
because
of
rotation
because
of
stuffing
rotations
are
pretty
wild
and
we
want
to
give
more
flexibility
back
to
the
team
in
terms
of
being
able
to
swap
shifts
and
stuff.
E
The
other
use
for
this
dashboard
is
so
that
the
managers
can
kind
of
look
at
it
and
also
know
that
yeah
things
may
have
degraded
to
a
certain
point
where
we
find
it
unacceptable,
and
you
know
we
kind
of
need
to
end
the
experiment.
At
the
same
time
it
it
does
give
managers.
An
idea
of
things.
Are
you
know
trending
downwards,
or
things
are
looking
poor
this
way,
but
yeah?
The
question
is
even
when
we
look
at
that.
E
What's
the
action
we
can
take,
so
that's
something
that
I
haven't
quite
figured
out
quite
yet.
I
know
that
we've
discussed
this
at
team
meetings
and
the
ideas
that
the
team
have
are
that
you
know
when
things
look
rough,
they
have
certain
actions
they
can
take.
You
know
initiate
a
crash
session
or
start
pairing
stuff
like
that.
E
I'm
not
sure
how
scalable
that
is
in
terms
of
like
actions
we
can
take
because
yeah
it
kind
of
there's
a
lot
of
team
initiative
involved
there
right
now
and
I
guess
individual
initiative
and
it's
not
very
well
defined,
so
I'm
guessing.
If
we
do
run
the
experiment,
maybe
we
will
get
a
better
idea
of
what
those
actions
might
be
and
I
have
a
feeling
that
it
will
probably
have
to
be
engineer
driven
rather
than
manager
driven
anyway,
but
yeah.
B
What
kind
of
numbers
are
we
thinking
of
because
tom
last
time
he
mentioned
somewhere,
95
and
3
93
is
the
red
line,
but
we
also
have
right
now:
95
percent
for
asset
and
effort
and
85
percent
as
the
red
line.
So
do
we
want
to
maybe
start
with
assuming
that
the
red
line
that
we
have
is
a
red
line
for,
after
which
we
want
to
start
acting
or
do
we
want
to
define
different
numbers?
B
A
B
A
I
was
going
to
say
that
that's
sort
of
I've
been
trying
to
capture
some
of
the
questions
and
that's
sort
of
the
question
in
my
mind
is
like
when,
and
how
often
are
we
looking
at
this
data
like?
Are
we
looking
at
it
hour
by
hour
and
providing
guidance
to
engineers
for
how
they
might
organize
their
workday
to
optimize
these
metrics?
Are
we
taking
a
look
at
it
week
by
week
and
taking
actions
at
the
weak
scale
like
what's
the
unit
of
time,
where
we're
taking
action.
B
B
E
E
E
E
It's
kind
of
looking
at
the
trend
like
the
short
term
trend
versus
the
longer
term
trend
and
deciding
you
know,
do
we
need
to
take
action
now
and
I'm
not
sure
if
the
action
is
going
to
be
as
simple
as
let's
investigate
or
the
action
is
gonna,
be
something
like
hey
team.
We
really
need.
We
really
need
to
do
something
here
so
but
yeah,
I
think,
in
terms
of
if
you're
talking
about
times
where
intervention
might
be
necessary.
I
think
we
do
need
to
monitor
it
week
by
week.
B
I
think
you
and
I
may
be
talking
and
please
correct
me
if
I'm
wrong
about
the
same
idea
just
in
different
directions,
so
you're
suggesting
let's
monitor
the
weekly,
and
I
agree
with
you
that
I
guess
the
question
is:
should
we
actually
act
on
the
weekly
or
should
we
act
on
the
monthly
or
quarterly?
I
mean.
E
Oh
yeah,
so
I'm
saying
yeah,
I
I
think
we
are
talking
about
the
same
thing
and
I
do
agree
with
you
as
well
that
let's
not
have
knee-jerk
reactions.
So
my
what
I'm
thinking
is
that
we
review
things.
We
do
review
something
on
a
weekly
basis,
but
we
also
need
to
bear
in
mind
the
the
longer
term
trend,
which
is
why
in
the
dashboard,
there's
a
weekly
view
and
there's
also
a
28-day
view,
so
that
you
know
we
we
we
don't
just
look
at
this
week
and
go
yeah.
E
I
mean
I
don't
know,
hit
hit
the
emergency
button
and
you
know
cause
a
lot
of
panic.
When
actually
you
know
things
are
fine,
maybe
next
week
things
will
be
well,
so
I
think
we
kind
of
need
to
look
at
both
the
short
term
as
well,
as
maybe
a
mid
to
longer
term
view
and
look
at
it
holistically
together.
Otherwise,
yeah
we
will
probably
not
we'll
probably
not
be
able
to
get
the
best
results.
If
we,
if
we
look
at
either
in
isolation,
that's
what
I
feel
so
far.
A
A
If
everybody
does
that,
and
it's
not
completely
changing
everything
that
we
do,
but
as
we,
if
we
look
at
sort
of
like
the
month
and
quarter
in
aggregate
like
if
we're
resource,
starved,
all
of
our
metrics
are
going
to
start
going
down,
then
we're
gonna
have
to
look
at
either
more
efficiency
or
more
hiring,
and
so
it
it's
sort
of.
I
think
it's
at
both
end.
A
It's
providing
a
cl
sort
of
a
single
pane
of
glass
that
engineers
can
look
at
and
understand
what
actions
they
should
like
how
they
should
organize
their
work
during
the
week.
Maybe
that
means
putting
a
side
project
a
little
bit
on
back
burner
just
because
we
want
to
make
sure
that
we're
bumping
something
up
this
week.
A
A
E
Yeah,
I
actually
wanted
to
to
just
put
it
out
there,
so
I
think
going
back
to
your
original
question,
which
is,
we
might
have
this
pane
of
glass
which
tells
us
something
but
yeah.
What
are
the
actions
that
we
take?
I
think
we
don't
really
have
a
good
idea
of
what
that
toolbox
looks
like
right
now
and
I'm
not
sure
if
this
is
the
right
group
to
sort
of
talk
about
that
but
yeah
I
I
don't
think
we
have.