►
From YouTube: Support - Metrics Analysis Workgroup - 2020-08-18
A
Get
started
hi
all
welcome
to
the
metrics
analysis,
work
group
not
to
be
confused
with
working
group
not
to
be
confused
with
other
groups
that
may
be
working.
A
This
is
a
new
and
special
term
that
we
may
change
later.
So
in
our
first
meeting
today,
we
probably
will
we'll
follow
the
agenda,
but
there's
gonna
be
some
things
that
we
won't
look
at
because
we
haven't
decided
what
those
things
are.
A
But
the
general
approach
I
want
to
take
here
is
like
take
a
look
at
our
metrics.
Take
a
look
at
our
hypotheses,
find
data
to
prove
like
to
either
support
those
or
to
falsify
those,
and
at
the
end
of
the
day
we
should
figure
out
some
actions
that
will
help
move
those
things
as
a
result.
A
So
I
have
some
persistent
link
items
above,
but
I
actually
wanted
to
ask
you,
gentlemen:
what
should
we
be
looking
at
like
what
are
the
kpis
we're
most
concerned
about
and
we
can
have
infinity,
but
I
just
wanted
to
make
sure
we're
all
looking
at
the
same
thing
reporting
on
the
same
thing.
Every
week.
B
B
Maybe
c
set
first,
but
then
you
know
we
if
we
can
kind
of
figure
out
the
mechanism-
and
you
know
cadence,
of
what
we
look
at,
but
those
should
come
out
of.
I
would
expect
the
software
we
can
review,
because
it's
a
it's
a
weekly
view.
We
could
make
it
monthly
thing
as
well.
There
are
if
we,
if
we
want
to
look
at
it
holistically,
then
there
are
a
list
of
pis
and
kpis
and
that
are
kind
of
generated
by
sisense
as
well.
B
We've
tried
to
match
those
things
up,
but
you
know
those
are
the
ones
that
are
in
the
handbook
publicly
facing
as
well.
So
I
would
start
with
frt
and
sn
csat
or
sf
and
then
so
as
to
not
bite
off
more
than
we
can
chew.
B
Initially,
that'll
potentially
give
us
a
cadence
of
what
we
need
to
look
at
or
how
we
look
at
it.
A
In
the
past,
we,
like
you
had
mentioned
in
our
key
review
like
requester,
wait
time
and
total
time
to
resolution
had
been
also
trending
up,
and
we
wanted
to
dig
in
those.
Is
that
something
you
want
to
cover
in
this
or
assuming
that,
like
rss,
frt
and
nrt
are
going
to
shape
those
enough.
B
I
I
think,
the
latter
that
they'll
shape
them
enough.
B
B
Yeah,
because
I
anticipate
that
you
know
requester
wait,
time
will
be
caught
up
in
frt
and
nrt,
for
example.
Total
resolution,
obviously,
is
the
whole
gambit.
So
if
we're
improving
in
both
of
the
first
two,
it
may
not
specifically
address
total
time
to
resolution,
but
it
should
address
the
requester
wait
time
if
we're
focused
on
the
top
three,
at
least
that's
my
perspective.
A
C
B
B
One
of
the
areas
we
want
to
look
at
is
median
first
response,
and
is
that
trending
up
does
the
trend
be
down,
but
that
would
be
an
indicator
potentially
where
we
would
have
to
look
at
and
where
we
would
go
to
look
for
more
detail
of
the
trend
that
makes
sense,
because,
when
we
think
of
frt
right,
it's
a
percentage
of
time
that
we
meet
the
sla.
B
So
you
know
trending
up
or
down
is
is
great,
but
what
we
end
up
needing
to
look
at
is
well.
Are
we
just
not
getting
to
the
vast
majority
of
them
or
whatever?
So
you
have
to
kind
of
then
get
into
the
deeps
of
like
median
median
reply
time,
for
example,
is
that
trending
up
or
trending
down,
and
then
you
start
to
get
into
indicators
of
now,
we've
missed
on
a
couple,
but
we
had
a
small
volume
and
that's
what
that's?
What
messed
with
the
percentages,
for
example,.
C
C
C
Yeah,
it's
in
the
in
the
dashboard
support
metrics,
I've
added
it
so
under
each
sla
right
now,
I'll
just
share
my
screen.
There
is
a
median
graph
of
the
response
time,
so
we
have
median4.com
self-managed
nl
and
oh,
I
need
to
change
the
name,
but
yeah.
We
have
the
median
time
to
respond.
Sorry,
this
is
time
to
resolve.
C
A
Okay,
do
what
is
our
single
source
of
truth,
like
which,
what
graph
we're
going
to
look
at
every
week
for
asset
for
frt
sla
and
for
nrt
sla,
because
I
I
can,
I
could
guess,
but
I
guess,
there's
probably
multiple
ways
of
pulling
this
since
I
just
want
to
make
sure
that
we're
synced
up
with
we're
all
looking
at
the
same
thing.
Every
time.
C
The
one
that
I've
configured
is
the
one
under
the
asset
tab.
Now
this
is
my
responsibility.
Can
you
see
my
screen
by
the
way,
because
I'm
not
sure
it's
sharing
the
way
yeah,
we
can
cool.
So
the
logic
here
I
will
document
this.
This
is
part
of
my
okrs
for
this
quarter
to
make
sure
it's
in
the
handbook,
but
these
are
basically
not
security
related,
so
not
account
related
just.com
and
self
managed
paying
customers
as
set.
This
is
under
the
asset
tab
there.
That
is
on
a
monthly
basis.
C
Now
I've
always
avoided
adding
the
current
month
in
these,
so
it
doesn't
show
august
because
it
might
kind
of
skew
the
results
on
partial
information
and
I've
shown
the
information
here
under
our
support.
We
can
then
review,
but
maybe
this
is
something
that
we
want
to
change.
So
my
question
to
you
is:
should
we
add
august,
or
should
we
leave
it
in
support?
We
can
review.
C
A
I
mean
yeah,
certainly
asset.
I
can
see
like
august.
First,
we
have
one
ticket,
it's
bad,
it's
zero
percent
and
that's
not
like.
We
don't
actually
care
about
that
yet,
but
for
frt
nrt
is
the
data
changed
in
the
same
way.
C
Again
that
I
I
put
in
support,
we
can
review,
but
I
can
also
add
so
in
support
we
can
review.
We
have
the
the
kind
of
rolling
couple
of
last
weeks
that
I
assume
that
that
was
the
the
right
approach
so
support.
We
can
review
more
granular
and
the
regular
one
are
the
previous
months,
but
we
might
yeah.
B
I
think
something
so
so
when
we
talk
about
it,
the
way
I
look
at
it
is
these
these
reports,
whether
it's
that
dashboard,
the
support,
dashboard
or
the
weekend
review,
is
kind
of
our
indicator
to
take
action
right.
So,
if
we're
looking
at
past,
like
we
looked
at
july
in
the
first
week
of
august,
that's
too
late
to
really
effect
july,
for
example.
So
I
think,
in
order
to
identify
are
we
do
we
have
a
trend
that
we
need
to
go
attack?
B
C
A
B
C
I
think
I
do
sense
a
bit
of
sprawl
in
this
dashboard,
so
the
original
intent
was
to
go
away
from
insides
because
it
was
moving
away,
but
also
to
create
something
more
clear
right
now
we
have,
I
don't
know
10
10,
11
tabs
there.
I
think
it
prevents
for
some
visibility
because
nobody
has
the
time
to
go
there.
I
was
thinking
of
creating
a
a
new
dashboard,
so
we
can
look
at
something
which
is
specifically
the
main
ones
asset
sla
support.
We
can
review
and
then
have
a
secondary
dashboard
with
the
other
things.
C
Does
that
make
any
sense,
and
also
another
question
would
be.
I
was
thinking
of.
Do
we
want
to
break
the
tabs
in
this
new
reorganized,
dashboard
pair
group,
so
selfmanage.com
lnr
account
or
we
want
to
have
tabs
that
are
flt
nlt
asset,
which
kind
of
grouping
we
want
to
maintain
there,
and
do
we
even
need
to
change
what
we
currently
have.
C
B
Yeah,
I
think
I
don't
know
I've.
Always
I
looked
at
it
as
all
those
are
great
because
at
some
point
you
want
to
look
at
the
top
level
and
you
say
well
top
level
looks
great,
and
then
you
dig
in
and
say
well,
but
we're
not.
You
know
we're
not
doing
so
well
in
this
category
or
something
right.
So
you
need
those
associated
categories
to
kind
of
then
zero
in
on.
B
Where
do
I
need
to
go
focus
and
realizing
that
even
trying
to
zero
in
on
that
area
could
impact
other
areas
because
you're
using
the
same
people
for
all
of
us
right,
so
you
go
and
say
hey.
This
is
a
priority,
then
that
kind
of
changes,
the
potential
dynamic
of.
What's
going
on
again,
depending
on
what
the
cause
is.
So
I
I
you
know
the
way
I
look
at
it
is.
B
If
we
point
to
what
we
have
existing
that
the
working
group,
this
work
group
focuses
on
to
identify
trends
and
then
take
action
when
we
say
this
tab,
this
tempest
tab
and
we
have
that
consistently.
B
We
can
either
just
keep
it
that
way
or
create
a
work
group.
Dashboard
and,
like
you
know,
use
those
things
same
thing.
So
we're
looking
at
the
same
data,
but
not
have
to
be
confused
by
all
the
various
tabs,
and
then
I
think
those
then
go
into
which
groups
are
performing
unsatisfactory
or
not
to
par,
not
to
target
or
whatever.
As
a
as
a
filtering
mechanism,
rather
than
a
first
first
stab.
A
Sounds
like
we've
come
full
circle.
Are
we
gonna
build
a
dashboard?
Are
we
gonna
look
at
the
same
persistent
things
each
week
I
would
favor
building
a
dashboard
specifically
for
this
just
so
we
have
one
persistent
link
that
we're
always
looking
at
and
we
don't
have
to
like
thinking
of
the
recording
sharing
one
dashboard,
taking
a
look
at
the
individual
components
of
that
rather
than
clicking
around
and
saying
just
look
at
this
part
seems
a
little
bit
cleaner.
C
A
Cool
the
next
item
typically
would
be
status
on
the
hypothesis
action
items
above
so
like
as
we
build
these
out,
then
we
can
assign
them
out
as
two
individuals
to
gather
that
data.
Take
a
look
at
and
report
on
that
data
and
whether
or
not
it's
consistent
with
the
hypothesis.
A
Since
we
don't
have
very
many
yet
then
we'll
we
can
look
at
building
some
of
those
out
a
little
bit
later.
I.
D
Answering
questions
that
are
kind
of
like
a
hypothesis,
which
is
what
does
the
queue
look
like
for
the
team?
How
does
work
look
like
for
the
team
and
for
that?
D
We
really
need
a
lot
more
granular
information,
so
I
kind
of
have
been
experimenting
with
collecting
very
granular
data
based
on
scripting
the
zendesk
api,
and
I
can
kind
of
show
you
what
I've
done
with
my
initial
exploration
and
let
me
drop
you
a
issue
link
as
well
as
where
I've
kind
of
documented
some
of
this
I'll
just
share
my
screen
here
in
a
moment.
D
Yeah,
so
this
crazy
graph
is
actually
what
our
work
in
the
self-managed
with
soaq
looks
like
throughout
a
single
day.
This
was
from
my
thursday
last
week.
It
kind
of
starts
from
1am
utc
from.
D
13Th
of
august
all
the
way
to
1am
utc
14th
of
august,
so
the
green
line
is
actually
the
total
number
of
tickets.
In
that
queue
it
kind
of
goes
up
and
down.
I
can
look
at
axis
these
blue
jagged
lines
and
red
and
yellow
those
are
actually
the
average
sla
for
the
next
five
tickets
to
breach
the
sorry
next
10
tickets
to
bridge
and
the
dotted
lines
are
actually
the
average
soa
for
the
next
five
tickets
to
bridge
and
the
purple
bars
below
are
the
number
of
responses
we
send
out.
D
D
So
if
you
kind
of
look
at
this,
we
can
see
that
there
are
quite
a
number
of
periods
throughout
the
day
where
the
average
sla
for
the
next
five
tickets,
the
bridge,
actually
dips
very
low
below
four
hours,
all
the
way
to
below
two
hours.
D
So
if
you
look
at
the
different
color
lines,
so
this
blue
line
actually
correlates
to
the
apac
hours
for
customer
emergencies.
The
red
line
actually
correlates
to
emir
hours
for
custom
event
sheets
and
the
yellow
line
actually
correlates
to
the
aimer
hours
for
custom
emergency.
So
using
this,
you
can
kind
of
get
a
feel
for
what
the
different,
I
guess,
shaves
kind
of
look
like
I.
I
don't
have
any
firm
conclusions
out
of
this
data
yet
because
this
is
just
a
single
day,
I
think
we'll
need
repeated
observations
to
really
get
close.
D
But
one
thing
that
kind
of
strikes
me
is
that
we
can
kind
of
see
that
I
think
the
ticket
volume
is
actually
okay,
because
by
the
end
of
each
shift
we
kind
of
recover
or,
at
the
start
make
sure
if
we
kind
of
recover
to
a
place,
that's
good,
I
think,
what's
really
hitting
us
is
that
the
distribution
of
work
isn't
very
our
distribution
effort,
isn't
very
even
throughout
the
day.
So
this
is
I'm
not
sure
you
can
see
this,
my
cousin,
but
this
is
about
1
0pm.
D
Let
me
see
if
I
can
actually
draw
something:
let's
see
yeah,
so
this
line,
which
I'm
drawing
yeah
I
can't
draw
straight
anyway.
This
line
is
about
1
pm
utc,
and
if
you
just
look
at
the
purple
bars,
you
can
start
to
see
that
the
amount
of
the
density
of
responses
start
to
decrease.
After
about
this
line-
and
you
can
also
see.
D
That,
after
this,
I
think
the
s
the
average
sla
kind
of
increases,
I
think
that's
because
a
team
gets
the
queue
to
a
good
sort
of
position
and
then
they
kind
of
just
let
go
of
it
for
a
bit
and,
as
you
can
see,
the
ticket
volume
increases
eventually
the
the
average
actually
goes
down
as
well
until
it
we
kind
of
pick
up
in
the
middle
of
what
looks
like
the
aimer
time
zone
so
about
this
area,
I'm
not
sure
what's
going
on
here,
but
I
suspect
it
could
be
like
a
time
zone
hanover
problem,
similar
to
what
we
are
seeing.
D
You
know
at
the
end
of
the
start
of
apec
but
yeah.
I
I
don't.
D
Form
any
firm
conclusions
based
on
just
the
day's
data,
but
I
suspect
things
like
this
would
actually
reveal
more
insight
than
what
we
can
through
the
zendesk
explorer
dashboards.
The
only
problem
is,
I
actually
haven't
figured
out
if
this
is
valuable
enough
for
me
to
keep
keep
trying.
So
I
mean
yeah,
that's
just
what
I
have
to
share
just
coincidental.
I
happen
to
be
working
on
this.
C
D
Yeah
now
so
one
per
minute,
two
per
minute,
that's
one
where
we
reach
three
per
minute
over
here:
yeah
yeah.
So
these
lines
like
these
lines
and
these
ones
sorry
this
dotted
one
yeah.
These
are
the
average
average
sla
for
the
next
five
tickets
to
bridge
for
the
dotted
lines
and
10
next
10
tickets
to
bridge
for
the
solid
lines
so
yeah.
C
Okay,
so
you-
and
with
this
we
are
calculating,
how
loaded
is
the
queue
right?
Is
that
how
bad
the
situation
is
supposedly
in
the
sls.
D
Yeah
yeah,
correct,
okay.
That
was
what
I
wanted
to
try
to
get
to,
because
if
you
are
soa
or
if
you
are
kind
of
a
support
engineer
that
works
from
the
top
of
the
queue
yeah,
if
if
the
top
fuel
tickets
are
constantly
breaching
yeah,
you
kind
of
feel
like
the
cues
are
really
bad
for
you.
So
I
wanted
to
try
to
find
a
measurement
that
captures
that
that
feeling,
I
guess.
C
Yeah
well,
this
is
good
stuff.
I
mean
some
of
this.
We
can
definitely
get
in
explore,
but
some
of
this
not,
I
think
it
does
correlate
someone
to
median
response
times,
because
if
the
median
response
times
do
increase,
then
we
would
obviously
have
lots
of
more
breaching
tickets
or
getting
to
breach
in
the
cube.
But
this
is
great
information
about
your
observation
of
the
morning
of
eastern
time
and
evening
of
emea.
C
We
can
see
it
in
the
ticket
volume
and
you
can
also
see
it
there.
This
is
the
most
loaded
time
of
our
day,
so
the
afternoon
of
email,
the
2pm
and
the
morning
of
east
coast
9
a.m.
It's
it's
always
historically,
the
most
loaded
part
of
the
day,
so
that
might
be
related,
but
I'm
sure
there's
more
information
together
from
there.
Do
you
mind
if
we
schedule
a
kind
of
our
chat,
maybe
this
week,
so
we
can
look
at
this
later
and
see.
D
Create
something
cool
my
next
step
for
this
would
actually
be
trying
to
load
this
into
like
something
like
influx
db
or
something
just
so.
I
don't
have
to
manually.
Do
the
number
crunching
but
yeah
happy
to
set
a
chat
and
see
what
you
can
do.
A
Here
thanks,
I
saw
that
yesterday
in
the
issue.
It's
exciting
stuff,
I'm
interested
in
the
like
the
number
of
replies
per
minute.
I
think
that
it'll
be
interesting
to
see
kind
of
like
where
our
engineer
density
is.
I
think
we
could
probably
guess,
based
on
people's
locations,
but
it'd
be
nice
to
see
that
backed
up
by
the
actual
work
being
done.
A
Does
a
time
exist
when
we
can
all
meet?
I
think
that,
as
we
develop
our
hypotheses
and
start
looking
at
data,
we
can
get
more
async,
but
I
do
want
to
have
like
a
consistent
time,
I'm
suggesting
weekly,
where
we
can
take
a
look
at
and
report
on
the
data,
but
I
also
don't
want
you
to
have
to
stay
up
till
like
bajillion
o'clock
with
me
or.
D
A
B
D
Earlier,
no,
I
think
this
time
it's
good,
so
yeah.
B
Yeah,
I
wanted
to
touch
on
one
piece
that
I'm
not
sure
how
to
get
the
data,
but
lyle
kind
of
mentioned
it
in
in
density
of
available
staff,
and
we
talked
about
the
handoff
periods
of
afternoon
ema
early
morning
mayor
afternoon,
mayor
early
morning,
apac,
and
I
don't
know
that
we've
we've
got
kind
of
a
gut
feel
of
where
we
have
people,
but
that
that
feel
also
assumes
that
everybody's
online
all
the
time
right.
So
it
would
be
it
would
be.
B
We
need
to
anticipate
that
and
in
order
to
stay
up
on
slas,
because
that's
that
type
of
stuff
will
also,
I
think,
stress
out
sla
hawks
when
they've
got
nobody
to
turn
to
in
a
particular
time
frame.
Right,
I
don't
know
how
best
to
get
that
data.
You
know.
Obviously,
bamboo's
the
source
of
truth
for
where
we
have
people,
but
that
doesn't
necessarily
equate
to
the
times.
People
are
working.
C
C
We
have
an
x
amount
of
tickets
coming
in
something
in
that
sort
and
saying
we
need
these
amount
of
engineers
to
to
be
able
to
respond
to
these
amounts
of
tickets,
and
then
we
can
kind
of
say
in
each
hour
of
the
day
or
within
each
region.
We
need
to
have
at
least
these
amount
of
people
available.
B
C
So
I
can
try
to
gather
information
about
the
distribution
of
different
ticket
types
per
hour
of
the
day
together
with
incoming
ticket
volume,
but
I
mean
the
biggest
question
I
have
in
my
mind,
is
how
much
an
engineer
can
update
on
a
given
day.
So
let's
say
we
have
20
engineers
how
many
tickets
can
they
ultimately
update?
Because
we
don't
want
to
say
to
people,
you
can't
go
on
pto,
because
we
don't
have
enough
people
and
that's
something
that
I
yeah.
I
don't.
I
don't
even
know
how
to
approach
that.
B
Yeah,
so
for
for
me,
it
you
know,
probably
the
the
worst
it
oversimplify,
but
to
me
it's
either
the
law
of
averages.
So
we
build
a
staffing
model
and
the
staffing
model
to
various
pieces
have
come
back
and
said.
Well
we're
overstaffed
right,
my
well.
If
we're
overstaffed,
then
we
shouldn't
be
having
these
sla
problems
so
right.
B
So
if
that's
the
case,
if,
if
we're
not
overstaffed,
are
we
adequately
staffed
or
understaffed
in
certain
regions
and
do
we
adjust
what
we're
staffing
to
from
a
model
perspective
and
do
it
more
granularly
to
regions
so
right
now,
it's
you
know
we're
just
taking
the
swag
of
you
know:
40
60,
20
kind
of
an
approach
in
regions
that
somewhat
correlates
to
the
times
of
the
ticket
creations
right
and
saying
that
that's
good
enough.
So
now
I'm
questioning
is
that
good
enough?
Do
we
need
to
go
to
the
next
layer
or
layers.
C
I
guess
the
the
granularity
here
might
also
require
looking
at
the
different
groups.
So
specifically,
we
had
this
700
influxing.com
for
june
july,
and
so
we
dropped
on
the
on
asset
and
sla
and
also
on
lnr,
specifically,
which
is
right
now
at
700
tickets
as
well.
So
it's
a
fifth
of
our
tickets
are
in
elena
and
they
are
suffering
they
are
60
to
70
percent
flt
and
nlt
and
dot
com
as
well
specifically
for
self-managed.
We
are.
The
slas
are
quite
good
they're
at
95,
98
kind
of
persistently.
C
So
maybe
that's
also
a
consideration.
Maybe
it
means
we
need
to
move
along
faster
with
tom's
area
of
focus
idea
and
to
aggregate
both
groups
possible
that
removing
the
free
ticket
support
would
help
the
dot
com.
A
I'm
sorry
I
mean
we
can.
We
can
definitely
move
into
into
that
section,
so
we
I
do
want
to
be
mindful
of
time.
I
only
scheduled
40
minutes,
so
we
actually
only
have
about
seven
minutes
left,
but
this
part
is
something
that's
very
async-able.
A
I
was
I
thought
of
some
of
these,
as
I
was
making
dinner
last
night,
so
we
can
just
write
them
down.
What
we
can,
I
think,
probably
the
assignment
for
this
week
is
to
come
up
with
different
hypotheses
put
them
in
this
document,
and
if
you
already
know
what
data
we
need
to
look
at
then
go
ahead
and
put
that
put
what
that
data
is
and
if
you
get
excited,
go
for
it
assign
yourself
one
of
these
add
some
data,
and
we
can.
We
can
do
that
as
quickly
as
you
want.
A
The
one
thing
that
I
think
is
harder
to
kind
of
async
talk
about.
Is
our
exit
criteria
like
when
do
we
want
to
disband?
When
will
we
have
succeeded
in
what
we're
trying
to
accomplish.
B
Well,
I
think
I'll
think
about
it.
One
of
them
to
me
of
the
top
of
the
head
is
the
criteria
to
regroup
right?
Is
we
identify
these
thresholds
are
hit
for
this
amount
of
time
we
need
to
regroup
it
or
a
work
group
needs
to
regroup,
to
go
out
and
identify
right,
or
the
next
criteria
is
when
these
thresholds
are
hit.
B
A
B
And
I
think
the
other
we
talked
about
it
early
and
just
kind
of
went
back
and
forth
and
dashboards
are
going
to
get
created
and
ilia
is
going
to
put
his
incredible
mind
together
with
all
these
dashboards.
But
one
of
the
extra
criteria
is
we
have
that
consistent
thing
to
go
back
to
when
if
we
do
see
a
trend
based
on
those
thresholds
of
the
first
exit
criteria,
right
that
these
things
are
reusable
for
each
of
these
situations,
to
one
identify
it
and
then
to
take
action.
D
Yeah,
I
think
I
have
the
same
thoughts
as
tom
here,
which
I'm
I'm
just
thinking.
Maybe
one
of
the
exit
criteria
should
be.
We
have,
you
know,
identified
a
few
matrix
which
are
more
actionable
on
them
on
more
short-term
basis.
In
terms
of
you
know,
maybe
from
week
to
week,
we
actually
are
able
to
have
some
kind
of
lagging
indicator,
even
better,
leading
indicator
that
indicates
to
us.
D
We
need
to
take
some
kind
of
action
so
yeah,
I
guess,
if
you
want
to
generalize,
it
is
to
kind
of
reduce
the
latency
I'll
find
a
matrix
which
will
help
us
reduce
the
latency
in
which
we
start
to
take
action.
If
that
makes
sense,.
A
A
B
Flag
identifies
take
these
actions
right
and
you
know,
and
initially,
if
those
were,
if
those
were
red
flagged
in
the
manager
sinks
on
a
weekly
basis,
then
we
could
discuss
actions
in
those
managers,
but
it
could
be
on
an
hourly
basis
as
well
right,
something
happens
in
apac
and
a
red
flag
goes
up
then
john
and
wayming,
and
jane
and
fuji
all
have
to
kind
of
figure
out.
Okay.
We
need
this
to
happen
so.
A
A
Okay,
I
will
put
those
together
in
a
merge
request
and
we
can
kind
of
discuss
a
little
bit
more
in
there.
I
think
that
sounds
like
a
good
start.
Any
closing
thoughts
before
we
disband
is
everybody's
next
action's
clear.
I
want
you
to
take
a
look
think
about
hypotheses.
A
A
Alrighty
I'll
I'm
going
to
upload
this
recording
to
youtube
and
or
unfiltered
and
making
an
unlisted
video
I'll
make
an
mr
summarizing
this
meeting
and
make
the
meeting
repeat.
Oh
sorry,
actually
I
you
said
it
blaming,
but
I
missed
it.
Is
this
this
time
is
okay
or
would
you
prefer
an
hour
earlier?
Oh
yeah.
This
time
is
okay
for
me,
okay,
perfect
alrighty!
Thank
you.
Folks,
see
you
next
week,
thanks
y'all.