►
From YouTube: Area of Focus Workgroup - 2021-03-11
Description
Area of Focus Workgroup - 2021-03-11
A
A
Right
on
so
just
to
follow
up
with
some
of
the
things
we
discussed
last
time,
it
had
been
asked
if
I
could
get
like
total
number
of
replies
and
average
number
of
replies
on
the
metrics
dashboard.
I
did
get
those
added
on
there.
Luckily
wasn't
near
as
difficult
as
I
thought.
Once
I
figured
out
how
to
make
the
dashboard
look
right.
A
That
was
that
was
the
most
fun
part
about
that,
but
quickly
I
talked
to
ilya
for
about
30
seconds.
He
went.
Oh
click,
these
three
things
and
I
was
like
oh
okay,
cool,
so
I'll,
go
ahead
and
share
my
screen:
real,
quick
and
just
kind
of
go
over
what
we've
got
for
that
cool,
hopefully
you're,
seeing
the
dashboard
now.
A
So
some
of
the
replies
and
then
the
average
replies
per
ticket
and
percentages
put
that
into
what
percentage
of
our
queue
was.
These
various
categories-
but
yes,
I've,
got
this
now
where
each
one
of
them
is
showing
the
total
sum
of
replies
for
all
the
tickets
of
like
the
various
categories
and
then
the
average
number
of
replies
per
ticket
in
that
sum
of
tickets.
So,
just
looking
at
this
september,
2020
for
authentication
for
was
this
a
mayor.
A
C
True,
it
kind
of
depends
on
what
percentage
are
automated,
though
right
so
yeah
I
mean
yeah,
so
we
just
need
to
maybe
be
able
to
counterbalance
that
aspect
of
it
somewhere
down
the
line.
If
it's,
if
everything
is
under
you
know,
10
are
automated,
then
there's
no
worry,
then
you're
taking
the
right
approach,
in
my
view,
so.
A
Yeah
and
I'll
work
with
ilya
next
before
our
next
meeting
just
to
see,
if
you
can't
help
me
figure
out
how
to
get
that
in
there
to
see
if
it
drastically
changes
the
numbers
or,
if
we're
looking
at
yeah,
it
slightly
modified
them.
But
the
average
replies
are
pretty
much
the
same
kind
of
deal
but
yeah.
A
So
we've
got
each
of
the
regions
and
then
the
all
region
has
all
of
them,
and
then
this
nifty
little
chart
at
the
bottom,
which
will
let
you
kind
of
see
the
average
frt
at
nrt
or
sorry,
the
average
frt
and
the
average
request
your
wait
time
for
each
of
the
categories
over
a
three
month
span.
It's
excluding
the
current
month,
just
because
the
month's,
not
over.
A
So
what
we
were
seeing
on
all
of
that
data
was,
it
was
doing
its
thing
and
then
this
month
would
drastically
drop
because
we're
not
all
the
way
through
the
month,
and
you
can
click
through
the
various
categories
or,
if
you
really
like
confusing
yourself,
you
can
click
all
of
them
like
that
and
then
not,
in
my
opinion,
be
able
to
read
very
much
but
yeah.
So
this
is
kind
of
just
getting
that
on
the
metrics.
A
A
I've
got
that
in
place.
I
put
down
some
of
the
basic
questions
that
I
think
we
talked
about
wanting
to
answer
and
I
tried
to
answer
some
of
them
myself.
Just
using
like
my
own
kind
of
this
is
my
thought
process.
My
logic
I
think
going
in
detail
of
discussing
this
stuff
would
be
beneficial
to
us.
I
think
that's,
probably
what
we're
kind
of
left,
with
figuring
out
from
this
stage
is
we
know
the
the
barrier
to
getting
this
kind
of
to
go
live
fully.
A
Is
the
training
aspect
of
closing
that
gap
between
sauce
and
self-managed?
We
know
that
ronnie,
weiming
and
vg
have
things
they're
doing
to
help
with
that.
So
I
think
what
we
want
to
kind
of
get
prepared
and
ready
is
great.
How
do
we
answer
some
of
these
questions
that
we're
bound
to
get
on
day,
one
or
you
know
even
maybe
day,
50
and
stuff,
like
that?
A
So
I
think
kind
of
going
over
these
would
be
a
good
use
of
our
time
to
kind
of
try
to
figure
out
here's.
What
we're
thinking
is
our
first
iteration
here's,
what
our
logic
is,
and
then
we
can
kind
of
start
playing
around
with
figuring
out
what
documentation
is
needed.
What
do
we
need
to
update?
How
do
we
communicate
this
change
out
stuff,
like
that?
A
A
A
Cool
so
I'll
kind
of
go
over
the
questions
and
what
I'll
do
is
if
I've
answered
it
I'll
say
what
my
answer
was
and
explain
why
I
thought
that
way
and
then
I
figured
we
can
discuss
and
figure
out.
If
you
know
we
like,
oh,
we
don't
like
that.
Let's
try
something
else
or
yeah.
That
sounds
fine
move
on
the
first
kind
of
thing
I
figured
is
determining
the
number
of
agents
per
category
I
feel
like,
especially
for
managers.
That's
going
to
be
a
big
overall
question
of
right,
so
we've
got
this
thing.
A
How
are
we
going
to
make
sure
we
have
enough
agents
per
category
and
all
that
fun
stuff?
When
I
looked
at
this
honestly,
what
I
saw
in
my
head
was
yep.
This
looks
like
a
math
formula,
that's
honestly
kind
of
how
I
tackled
this,
so
I
kind
of
put
two
different
formulas
in
place.
One
is
okay,
so
if
we
use
a
baseline
metric
like
five
replies
a
day,
this
is
what
it
would
look
like.
A
A
Yeah
and
honestly,
what
I
ended
up
doing
is
yeah
the
numbers.
Look
great.
We
need
way
less
agents
to
do
number
of
solves
a
day.
We're
also
then
expecting
agents
to
do
a
ton
more
replies
a
day.
It
doesn't
feel
very
good.
It
feels
like
it's
a
burnout
inducing
thing
so
using
the
baseline
of
like
five
replies
a
day
which
I
feel
like
is
a
pretty
achievable.
A
You
know
goal
could
basically
be
the
the
sum
of
the
tickets
for
the
last
quarter
and
then
the
average
number
of
replies
for
those
tickets
for
the
last
quarter,
and
then
you
divide
it
by
five
times
the
number
of
days
in
a
quarter
which,
hopefully
that'll
be
kind
of
our
constant
of
you
know,
take
365.2425
if
you're
not
familiar,
that's
the
actual
mathematical
number
of
days
in
a
year.
What
that
is,
is
that's,
how
it
equates
to
leap
years
and
leap
seconds.
A
It's
really
weird,
but
and
essentially
dividing
that
by
three
tells
us
that's
the
average
number
of
days
in
a
quarter.
The
reason
we
use
an
average
number
of
days
in
the
quarter
is
things
like
the
you
know.
The
things
like
quarters
with
february
are
really
weird
on
number
of
days,
but
things
but
like
the
ones
that
have
november
and
december
in
them,
those
are
going
to
be
ones
that
have
two
days
that
have
or
sorry
december
and
january
have
two
days
of
31
one
day
of
30.,
so
it's
gonna
kind
of
bounce.
A
A
Four,
which
will
make
my
math
equation
slightly
wrong
on
this,
but
I
think
it's
okay,
because
the
overall
I
think
the
overall
numbers
from
my
math
will
at
least
kind
of
demonstrate.
The
point
I
was
going
for
so
to
use
an
example
this
using
the
amer
ci
cd.
So
if
somebody
like
ronnie's
like
how
many
people
do,
we
need
doing
cicd
tickets,
we
can
take
the
number
from
the
previous
quarter.
A
A
A
C
Certainly
there
are,
there
are
response,
is
done
on
weekends,
I
mean
we
know,
greg
works
on
weekends.
We
know
some
folks
work
coco
weekend,
that
type
of
thing,
but
there's
a
traditional
sort
of
20
or
22
work
days
per
month
that
models
use.
So
you
can
work
that
into
a
quarter
and
what
that
might
be,
whether
you
choose
20
or
whether
you
choose
22
my
view
is
it
gets
to
be
good
enough
right
and
close
enough.
C
The
other
question
I
have
is
around
the
five
responses,
and
does
that
need
to
be
more
variable
based
on
the
type
or
are
we
just
using
kind
of
a
level
set
across
all
ticket
types?
So,
for
example,
is
five
responses
sufficient
for
a
ci
cd
issue
and
there's
five
too
many
for
a
sas
account
issue
as
an
example.
B
I've
been
looking
at
ticket
baselines
quite
a
bit
with
my
team
lately,
because
I've
got
people
doing
all
the
current
three
areas
of
focus
and
they
are
wildly
different.
So
my
self-managed
people
it's
about
21
to
22
per
week,
whereas
my
sas
people
it's
more
like
80
a
week.
So
it
is
actually
wildly
different
depending
on
the
type
of
ticket
you're
working
on.
C
C
Yeah,
I'm
trying
to
I'm
trying
to
figure
out
from
an
area
focus
perspective
right
because
what's
the
what's
the
granularity
so
and
that's
when
you
know
we
can
be
very
general
or
we
can
try
to
be
a
little
more.
I
think
general
on
the
days
and
a
little
bit
more
variable
on
per
area
of
focus.
What's
the
average
or
median
or
whatever
you
want
to
call
it
right
or
what
not,
what
you
want
to
call,
but
what
you
want
to
calculate
because
obviously
they're
very
different.
C
A
A
The
reason
I
just
did
it
kind
of
general
with
five
replies
is
what
I
kind
of
use
with
the
average
number
of
replies
of
okay.
If,
on
average
it
takes
3.67
replies
to
per
ticket
for
all
the
tickets
we
got
last
quarter
for
ci
cd
is
the
example
that
would
mean
on
average
that's
how
many
replies
each
ticket
needed
to
close
out
be
solved.
No
more
replies
needed
on
it.
A
A
A
Some
of
them
require
way
less
replies
to
solve,
like
sauce
account,
but
account
for
a
huge
chunk
of
volume,
because
there's
a
lot
of
them.
That's
what
I
ended
up
think
we'd
end
up
seeing
is
we'd
end
up
having
our
averages
would
look
a
little
weird
and
it
would
be
not
valid
for
some
of
the
harder
tickets
that
do
require
more
and
the
best
way
to
look
at
that
is
cicd
needs.
3.67,
average
replies
sauce
account
needs
two.
D
A
So
I
know
s
statistically
and
that's
using
pure
statistic,
logic
of
mathematics,
statistically
on
a
big
enough
scale
of
numbers,
your
mode
and
your
average
should
be
within
a
very
small
standard
deviation
of
one
another.
I
don't
know
what
they
are
in
this
case.
I
can
try
to
figure
out
how
to
how
to
get
that
next
floor,
but
I'll
need
to
work
with
ilia.
A
D
E
E
E
E
E
So
take
these
numbers
with
a
grain
of
salt,
I'm
just
going
to
quickly
share
my
screen,
so
you
can
see
what
I'm
talking
about
so
from
this
section
on
meeting
the
ticket
baseline
on
our
responsibilities.
Page
there's
reports
for
self-managed10.com,
because
this
was
only
meant
to
be
an
example
and
then.
E
E
E
E
I
would
generally
want
to
use
the
self-managed
numbers,
otherwise
we
could
pull
like
specifically
for
maybe
l
and
r
and
for
sas
accounts,
because
they
are,
they
can
be
quite
different
in
nature.
We
might
want
to
pull
numbers
specifically
for
how
many
replies
as
a
baseline.
We
expect
per
per
day
for
those
two.
A
B
A
B
A
I
think
what
helps
l
r
is
y'all
know,
as
l
r
does
not
use
preferred
region
like
just
because
it
may
say
a
preferred
region
of
apac
right,
but
l
and
r
is
going
to
kind
of
get
responses
as
they
get
responses
for
it.
So
I
think,
in
those
cases
it
might
be
being
balanced
out
by
just
the
global
team
is
working,
l
and
r,
not
just
apac,
is
you
know
specifically
only
doing
that?
I
think
it's
also
important
to
note
that
license
and
subscription
doesn't
necessarily
100
percent
mean
just
l
r
view.
A
C
A
E
E
But
I
think
you
know,
we've
always
recognized
at
least
that
that
the
sas
account
and
lnr
tickets
are
different
in
nature
in
a
lot
of
ways
than
the
other
areas
of
focus,
and
so
I
think
we're
calculating
how
many
replies
per
day
we
expect
out
of
accounts
and
lnr.
Specifically,
we
should
be
using
different
baselines.
A
I
I
fully
agree
because,
like
looking
at
this,
like
five
replies,
baseline
makes
sense
on
things
like
ci,
cd
and
authentication,
where
they're
very
technical
tickets,
it
does
not
make
sense
on
sauce
account
tickets.
I
could
very
much
see
someone
like
jane
not
being
happy
with
the
performance
of
somebody
who's
like
I
did.
Five
sauce
account
tickets.
A
I
did
five
replies
in
sauce
account
today,
it'd
be
like
so
what'd
you
do
with
the
other
seven
hours
of
your
day,
so
I
could
see
that
what
we
might
need
to
do
is
figure
out
the
baseline
per
category.
Just
looking
at
that,
I
think
that's
kind
of
what
I
wanted
to
do
with
just
the
math
equation
was
if
we
went
with
set
values
for
pretty
much
everything
we
could,
which
in
this
case
the
only
static
value
really
is
you
know
the
number
of
replies
a
day?
A
We
look
at
it
like
that,
and
I
think
it
helps
see
the
disparity
that
jane
and
you
know,
cynthia
are
pointing
out
of
right.
It's
saying
license
and
renewal
needs
eight
people,
but
we
definitely
don't
have
that
right.
They're,
probably
also
doing
more
than
five
replies
a
day,
which
is
accounting
for
that.
A
So
we
might
want
to
say
oh
well,
eleanor
we
want
10
replies
a
day
which
kind
of
changes
the
numbers
of
you
know
changes
the
values
for
that,
because
then,
instead
of
you
know
just
being
number
of
gay
working
days
times,
five,
it's
right
for
that.
One
it'd
be
number
of
working
days
times
10,
so
it
ended
up
being
600
instead
of
300,
which
would
drop
that
down
just
doing
math
in
my
head
to.
A
E
A
A
E
C
E
E
E
We
should
use
different
numbers
for
those
just
because
we
know
they're
less
technical,
but
in
terms
of
how
many
agents
we
might
need
in
any
given
area,
I
do
think
we
should
use
the
average
number
of
replies
per
like
for
each
area
of
focus
have
a
different
number
based
on
the
metrics.
That
jason
has
pulled.
C
I'm
thinking
of
it
more
in
in
terms
of
we
have
this.
This
model
that
just
does
kind
of
distributes
that's
simplified,
distributes
based
on
tickets,
created
right
and
it
distributes
people
into
regions
so
that
we
have
apac
amer
emea
and
we
get
a
distribution
of
people.
From
my
perspective,
this
sounds
like
we're.
Building
it
bottoms
up
to
say
these
area
focus
need
this.
Many
people
in
these
regions
versus
a
percentage
of
the
people
that
our
broader
model
says.
C
We
need
to
pull
together
and
I'm
the
big
concert
they're
going
to
come
way
out
of
balance
right,
and
so
the
question
is:
is
it
a
ratio
of
in
this
set
of
tickets
for
this
particular
region?
We
get
more
ci
cd,
we
get
more
sas,
we
get
for
this
whatever,
and
so
we
have
to
have
our
ratios
different
in
a
particular
region.
C
Or
do
we
have
you
know?
Do
we
have
the
same
ratios,
although
they
may
be
varied
right,
10,
ci,
cd,
5,
this
10,
this
in
in
in
different
regions,
I'm
just
trying
to
figure
out
what
it
is
we're
trying
to
outline
is
it
are
we
have
do.
We
have
the
right
areas
of
focus.
Do
we
try
to
do
a
staffing
model
based
on
areas
of
focus?
A
So
I
optimistically
think
the
answer
is
yes.
I
think
this
helps
illustrate
a
how
many
people
we
might
need
per
region.
Maybe
there
is
an
understaffing
issue
that
this
will
help
illustrate,
but
I
think
also
b,
like
you
said,
it
also
helps
illustrate
hey
apac,
I'm
noticing
you'll
get
a
lot
of
off
tickets.
You
should
have
this
many
agents
per
whatever
dedicating
100
of
their
time
to
that,
which
probably
would
equate
to
x
percentage
of
your
current
staffing.
C
A
A
A
C
E
So
you
know,
if
you
say,
okay
overall,
we
need
you
know,
maybe
50
percent
cicd
I
mean
that's,
that's
probably
way
bigger
than
an
hbc
20
caacd,
that's
probably
still
too
big,
but
you
know,
then
we
can
say:
okay
well,
20
of
what
resources
you
have
right
now
in
each
region
should
generally
go
towards
cicd,
because
I
remember
looking
at
it.
There
wasn't
much
difference
in
terms
of
the
percentage
at
least
of
tickets
that
we
were
getting
from
one
region
to
another
for
an
area
for
each
area
of
focus.
C
Yeah
that
that's
why
I
was
going
to
lost
cynthia
and
didn't
it.
For
the
few
years
I've
been
here,
we've
gone
from
a
kind
of
a
was
a
30
30
40
split
to
a
more
of
a
38
38
24
split
of
tickets
created
by
region
right,
and
so
it's
getting
closer.
But
it's
still,
you
know
heavily
focused
in
emea
and
amer
and
then
a
quarter
of
the
tickets
get
created
in
the
broad
span
of
apec
times
with
overlaps
in
both
directions.
So
yeah,
I
think
what
you're
going
as
globally.
C
E
E
Doing
it,
like
you
know,
we
we
talked
about
doing
it
by
percentage.
Do
we
want
to
do
it
by
ticket
or
replies?
If
we
do
it
by
replies,
then
I
think
we
do
need
to
await
l,
r
and
sas
accounts
a
little
differently,
so
that
that's
the
only
thing
is.
I
still
think
we
should
probably
take
percentage
of
replies,
but
then
that
we
need
to
somehow
weight
l,
r
and
sas
so
that
it's
a
lower
percentage
of
the
total
resourcing
that
we
need.
A
Yeah,
I
think,
let
me
use
kind
of
what
we've
talked
about
here,
to
figure
out
a
slightly
different
equation.
Essentially,
but
one
that's
using
this
is
the
percentage
of
ticket
creates,
but
also
finding
a
way
to
weight
each
ticket
based
on
the
average
number
of
replies,
because
I
think
that's
basically
what
you're
talking
about
cynthia's
rights
of
each
one's
coefficient
of
for
lack
of
a
word
coefficient
to
solve
is
different.
D
A
The
coefficient
to
solve
a
sas
account
ticket
is
lower
than
a
cicd
ticket
or
etcetera,
etcetera.
So
yeah,
I
think
we
can
essentially
use
the
average
number
of
replies
required
for
the
quarter
turn
that
into
basically
a
coefficient
and
use
that,
with
the
percentages
to
say
right.
This
is
what
the
actual
percentage
accounts
to
just
because
like
if
ci
cd's
20
of
our
tickets
right,
but
if
they
take
30
of
our
time,
we
want
to
make
sure
that
we're
allocating
that
correctly.
E
C
An
attempt
to
make
your
brain
hurt
when
you
start
talking
about
timing
right,
a
reply.
Isn't
a
reply,
isn't
a
reply.
Even
in
five
replies
right,
one
could
take
15.
One
could
take
two
hours
right.
So
at
that
point
you
start
then,
taking
into
consideration
a
length
of
time
to
actually
solve
a
ticket,
and
I
don't
think
we
have
the
granularity
to
understand
that
particular
place
or
that
particular
element.
So
everything
will
be
a
you
know
as
good
and
a
good
enough
estimate,
as
you
can
kind
of
imagine.
C
A
Yeah
I'll
I'll
pair
with
ilya
next
week,
because
he's
really
good
with
all
that
metrics
and
stuff
see
if
he
can't
help
me
figure
out
a
way
to
essentially
put
a
weight
to
each
kind
of
ticket
because,
like
you're
right
tom,
I
might
be
saying
right.
Cicd
needs
an
average
of
three
replies
to
close
right,
but
each
of
those
replies
probably
took
an
hour,
whereas
the
two
sauce
account
replies
that
were
needed,
probably
took
minutes.
A
So
let
me
take
a
stab
at
that,
because
I
don't
want
us
to
have
to
spend
all
our
time
talking
about
math
as
much
as
I
would
love
that
I
feel
like
we
probably
don't
want
to
do
that,
so
the
areas
of
focus
as
we
have
them
now
from
the
support
gamble.
What
would
happen
to
that?
My
thinking
is
those
would
be
replaced
by
this
instead
of
saying,
oh
I'm
sm
focused
or
I'm
sauce
account
focused
or
whatever.
It
would
be
right.
C
C
C
Okay,
yeah,
so
two
things
I
was
gonna
say
one
is,
I
think,
they're
just
as
an
fyi.
When
you
talk
about
team
yaml,
I
think
there's
an
an
ever
underway
to
to
kind
of
get
bamboo
tied
into
certain
areas
of
truth,
single
source
of
truth
for
areas
of
skill
from
an
engineering
department
perspective
so
down
the
line.
That
might
be
something
we
look
at.
The
second
thing
is
multiple,
so
hey.
A
A
Good
and
she
might
reply
back
with-
let's
start
with
one
and
see
how
you
do
with
that,
so
I
think
it'll
kind
of
vary.
If
somebody
like
cynthia's,
like
I
want
to
take
five,
I
wouldn't
challenge
it.
If
someone
who
it's
their
second
day
is
like,
I
want
to
take
five
and
be
like
I'm
gonna
challenge
you
on
it.
I
don't
think
you
get
like.
That's
that's
a
bad
idea.
You're
gonna
split
your
time
not
might
be
a
hindrance
to
you.
I
think
cool.
E
Sorry,
just
very
quickly,
I
think,
right
now
we
allow
like
onboarding
being
an
area
of
focus
right
now
too
as
well,
so
we
can
take
that
into
account
when
we're
you
know
looking
at
percentage
of
so
someone
like
once
they
actually
start,
even
if
they
only
have
one
area
of
focus,
isn't
technically
necessarily
100
of
that
aerial
focus.
They
would
be
potentially
onboarding
60
and
then
you
know
doing
an
aerial
focus,
40
percent
of
their
time
or
something
like
that.
A
I
think,
like
the
simplest
answer
for
how
to
factor
onboarding
and
all
this,
is
you
don't?
We
assume
a
person
who
is
onboarding
is
not
contributing
significantly
to
what
we
would
call
our
requirements
for
each
category.
What
that
does
is
it
doesn't
put
any
pressure
on?
You
know
joe
bob,
who
is
on
boarding
to
get
ramped
up
and
fast
enough
to
actually
start
doing
an
impact.
It
allows
them
to
focus
on
onboarding
from
what
I
recall-
and
I
don't
remember
who
it
was
I
paired
with,
but
somebody
is
looking
into
the
average.
A
A
If
it's
like,
oh
yeah,
on
average
they're
replying
to
tickets
in
a
week
cool,
we
probably
should
account
for
them,
but
I
think
that's
something
we
don't
have
to
quite
focus
on
yet
cool.
So
next
one
was
do
we
need
metrics
centered
around
performance
inside
category
should
focus
on
number
of
replies
or
solved.
I
just
put
based
on
the
above
conversation.
We
just
had
yep
they're,
not
the
same.
A
A
E
I
think
the
only
thing
we
need
to
factor
in
is
when
we
look
at
the
percentage
that
someone
who
is
learning
is
obviously
not
going
to
be
as
effective
as
an
expert.
So
if
we
need,
I
don't
know,
say
again,
let's
just
take
20
percent,
because
it's
an
easy
number
right
and
then
we
have
you
know:
fifteen
percent
being
like
or
even
ten
percent
being
filled
in
by
experts,
then
the
other
ten
percent.
If
they're
learning,
then
you
can't.
E
E
If
we
want
to
just
take
a
really
kind
of
you
know,
light
light
approach
to
it.
We
could
say:
oh
a
learner
is
on
average,
depending
on
where
they
are
in
their
learning
process.
Half
of
an
expert
so
then
to
fill
the
other
10.
You
need
two
learners.
I
mean
we.
We
could
just
kind
of
guesstimate.
That
way
like
a
learner
is
half
an
expert.
A
A
A
We
we
deal
with
it,
I
think
stuff,
like
crew
and
the
or
sla
hawk
or
whatever
the
various
regions
are
using.
I
think
that's
what
they're
good
for
is
they'll,
be
able
to
jump
in
and
help
with
unexpected
flood,
probably
unexpected
volume,
and
I
think,
set
volume-
will
impact
our
decisions
on
the
next
quarter
and
help
us
balance
that
out.
E
A
Cool
next
ones
I
kind
of
looked
at
was
the
number
of
categories
per
agent,
and
this
would
mean
how
many
areas
of
focus
can
one
person
have.
So
speaking,
just
on
the
zendesk
side,
six,
you
can't
have
more
than
six.
You
can't.
You
won't
see
all
the
views,
it
won't
work.
So
at
least
we
know
that
the
technical
limitations
of
it
is
six,
that's
the
max
you
can
be
in
at
one
time.
A
I
say
that
because
like
if
we
go
back
to
that
number
of
five
replies,
you
know
five
replies
per
day
if
you're
in
six
categories,
you're,
definitely
not
replying
to
one
of
them.
At
that
point,
you're
averaging
less
than
a
reply,
a
category-
and
it's
probably
like
right.
How
much
are
you
actually
helping
in
all
six
of
those
categories?
A
A
A
Yeah,
I
think
I
think,
we'll
just
kind
of
need
to
look
at
the
numbers
that
we
eventually
get
from
our
equations
and
all
that
and
kind
of
look
at
that
to
be
like
yeah,
that
that'll
help
us
determine
what
percentage
of
the
teams
needed.
How
much
do
we
actually
have
to
divide
that,
and
I
say
that,
because.
B
A
Well,
those
are
going
to
be
combined
like
that.
We're
not
going
to
keep
separating
sauce
and
self-made,
but
yeah
like
thanks
to
things
like
the
sla
hawk
or
the
the
corresponds
crew
and
stuff
like
that.
Just
because
no
one
in
a
region
is
an
expert
or
focused
on
that
category
doesn't
mean
the
ticket's
getting
ignored
like
at
the
end
of
the
day.
Yeah
the
sla
breach
things
about
to
breach
are
still
the
biggest
focus
so
like
at
the
end
of
the
day.
A
A
E
B
I
think
that's
the
sort
of
thing
that
can
be
handled
at
the
one-on-one
level,
with
the
manager
yeah
those
expectations,
the
onboardings,
I'm
I'm
really
cautious
of
not
being
overly
prescriptive
on
this
yeah.
If
we
say
right,
we
have
to
three
here
two
here,
one
here
six
here,
it's
like
really
what
happened
to
our
flexibility,
yeah.
A
Yeah,
I
think
we
don't
need
to
be
too
prescriptive
about
this.
I
think
offering
the
flexibility
is
important
here
cool.
So
how
often
should
we
you
know?
Basically,
now
we
come
to
the
rotation
period,
and
I
think
these
are
actually
pretty
easy
to
answer
of.
When
do
we
need
to
rotate
put,
you
know,
look
at
the
categories
and
determine
rotation.
Well,
if
our
equations
are
saying
quarterly,
the
answer
is
quarterly.
A
If
we're
looking
at
oh
volume
for
the
last
year,
then
it
would
be
in
theory
yearly,
but
I
feel
like
there's
no
way
we're
going
to
go
a
year
with
zero
changes
happening
to
experts
and
learning,
and
all
that
I
would
say
in
general,
though
like
oh,
I
want
to
change
talk
to
your
manager.
You
and
your
manager
can
work
it
out
kind
of
do
that
on
a
per
basis.
Let
the
manager
and
the
se
have
the
flexibility
to
do
that.
E
C
I
agree,
and
I
think
it's
a
these-
are
the
factors
that
would
influence
changes
across
individuals
or
teams
or
whatever
right
and
just
try
to
list
out
some
of
those
factors
it
could
be.
People
moving
into
different
teams
could
be
people
even
could
be
different
percentages
of
time
or
tickets
or
help
new
security
options
come
in
right.
We
have
to
add,
so
all
of
those
things
could
be
factors
and
now
things
adjust
for
you
all.
A
A
Don't
sentence
own
equation
or
formula,
I
think
I
think
it's
good
to
kind
of
let
it
be
fluid,
but
every
quarter
have
maybe
senior
managers
or
whatever,
whoever
it
is
that
wants
to
review
the
percentages
and
just
make
sure
hey,
I'm
noticing
this
shift.
We
might
want
to
make
sure
we
have
a
shift
of
people
focusing
on
that
as
well.
E
A
A
I
think
it'd
be
good
to
have
somebody
like
kind
of
you
know,
do
a
review
like
cynthia
said
and
then
maybe
publish
that
to
the
other
managers
and
be
like
here's,
my
thoughts
or
my
hypotheses
or
whatever,
because
I
guarantee
you
if
there's
numbers
and
metrics
someone's
going
to
want
to
do
it
cool
so
yeah
and
my
honest
vote
is:
if
they
want
to
change
the
area.
Focus
categories
shouldn't,
impede
it
as
long
as
it's
not
causing
a
major
coverage
issue
should
be
fine.
A
Generally
it'd
be
one
of
those
handle
per
manager
with
you
know,
manager,
sc
kind
of
level.
That
way,
if
cynthia's,
like
I
don't
want
to
do,
ci
cd
anymore,
all
cynthia's
manager
needs
to
do
is
make
sure
that's
not
going
to
cause
a
huge
problem
in
ci
cd,
and
if
it
is,
then
the
question
then
becomes
great.
What
can
we
do
to
enable
cynthia
to
leave
that
category
without
hurting
the
team,
and
I
think,
that's
kind
of
what
managers
are
supposed
to
be
doing-
is
figuring
out
how
to
remove
that
roadblock.
A
A
A
A
A
Maybe
if
you
have
any
thoughts
put
them
on
there
kind
of
help
fill
out
what
documentation
stuff
you
might
think
of
I'll
pair
with
ilia
to
figure
out
how
maybe
I
can
metrics
it
a
little
better
and
next
time
we
meet
up,
I
think
we'll
be
able
to
kind
of
go
over
it
again
and
be
like
we
agree
on
this.
Let's
go
ahead
and
commit
this
as
our
answer
to
this
and
then
start
working
out.
A
Our
official
like
this
is
what
it'll
all
look
like
document
and
then
we'll
have
that
to
be
able
to
go
to
the
manager.
You
know
the
rest
of
the
team
with
of
this
is
what
we're
thinking.
This
is
what
our
timeline
looks
like,
which
is
this
period
of
time,
is
to
close
that
sauce
self-managed
gap.
This
is
the
period
of
time
to
you
know
fully
implement
this
thing,
because
obviously
part
of
implementation
is
closing.
That
gap.