►
From YouTube: Areas of Focus - 2021-03-25
Description
Areas of Focus - 2021-03-25
A
A
A
A
So
like
ci
cds,
there
was
1049
replies,
I'm
saying,
there's
20
days
working
days
in
a
month,
the
actual
statistical
average
for
a
year
is
22,
but
I
don't
want
to
have
to
deal
with
it.
That's
just
weird.
Most
days
have
20.
and
then
because
ci
cd
is
technical.
It's
five
replies
needed
per
day
and
then
one
for
the
weight.
Here's
l
r,
which
is
14
25,
replies
20
days
and
then
5
times.
2
is
10..
A
A
A
A
So
we
actually
only
need
what
equates
to
point
two
of
an
agent
or
twenty
point.
Twenty
six
percent
of
our
team
and
the
reason
for
that
is,
it's
non-technical.
Those
are
often
handled
with
macros.
If
they,
if
the
point
two
of
an
agent
sent
ten
replies
a
day,
we're
done
like
it'll
kill
every
one
of
those
tickets
and
we
don't
have
to
worry
about
them.
A
But
then
you
can
jump
to
something
like
I'll.
Just
use
instant
management.
Okay,
so
we
need
about
26.9
of
the
team.
That's
because
there's
a
lot
of
those
tickets
that
would
equate
currently,
with
our
current
team
numbers,
to
about
20.59
agents,
sending
five
replies
a
day
using
this.
It
kind
of
adds
up
to.
As
of
current,
about
76,
we'll
call
it
77,
because
we
there's
no
such
thing
as
half
a
person
about
77
agents
which
gives
us
about
a
10
agent
gap
which
is
decent
for
our
pto
or
working
other.
A
You
know
working
projects
and
stuff
like
that.
It
also
has
some
baselines
that,
when
I
mentioned
this
to
like
when
I
mentioned,
like
the
l
r,
oh
10
replies
a
day
to
the
people
working
the
l
r
q,
they
laughed
at
me
because
they're,
like
yeah,
we
send
more
than
that
like
cool.
This
equation
is
basically
saying
this
is
kind
of
our
bare
minimum.
A
So
I
feel
like
this
gives
us
a
little
more
wiggle
room
and
also
gives
us
percentages
of
the
team.
So
as
we
grow,
we're
not
you
know
having
to
say.
Oh
it's
this
much
of
an
agent.
I
just
put
that
number
there
for
raw
calculation.
You
kind
of
help
me
out
figure
make
sure
that
the
end
number
wasn't.
You
know
88
people
and
be
like
okay.
Well,
then,
we
have
a
problem.
A
A
So
I
don't
think
that's
too
much
to
really
for
us
to
expect
and
then
looking
at
this
equation,
there's
basically
three
ways
I
see
to
edit
the
numbers
one's.
If
we
ask
for
more
replies
per
day,
that
would
mean
we
need
less
agents,
but
I
also
feel
like
that's
going
to
boost
stress
on
an
agent
a
lot,
especially
if
we
get
those
too
high.
I
mean
we
could
easily
say
cynthia
send
100
replies
a
day,
yeah
that'll,
probably.
A
I
also
saw
where
we
could
decrease
the
number
of
replies
per
day,
but
the
problem
with
that
is,
if
we're
sending
less
replies,
we
would
technically
need
more
agents
to
still
hit
the
numbers
we're
hitting
now
and
then
the
other
one,
which
is
the
really
hard
one
to
achieve,
but
the
ultimate
one
we'd
want
to
is
to
decrease
the
number
of
replies
needed
to
solve
tickets.
By
doing
that,
we
actually
need
less
agents,
so
that
that'd
be
the
great
thing
to
aim
for,
but
that's
also
one
of
those
things.
That's
like
right.
A
B
B
Yeah,
so
that
that
fits
well.
The
other
thing
I
was
thinking
is
you
mentioned
when
we
do
it.
When
I
did
a,
we
did
a
rough
staffing
model.
We
took
a
percentage
of
time,
so
we
actually
used
22
days
and,
like
you,
finance
pushed
it
to
20
days,
but
we
used,
you
know
adjusted
like
75
utilization,
80
utilization,
that
type
of
thing
so
that
that
took
into
account
some
training
some
days
off.
That
type
of
thing
yeah,
which
you
know
from
the
model
you
showed,
looks
pretty
pretty
pretty
close
right.
B
We've
got
87
folks,
we've
this
model
says
76,
so
I
think
the
adjustment
is
is
really
around
the
replies
and-
and
I
expect
that
the
the
replies
you've
got
you've
kind
of
established
has
been
taken
based
on
data
across
the
team
and
some
some
semblance
of
average
or
median
or
whatever
right.
So,
if
that's
what
it
takes
to
solve
tickets,
that's
what
we
should
be
looking
at
right.
What
does
it
right?
What
does
it
take?
D
A
Yeah,
I
think
what
I've
got
here
is
more
reflective
of
a
the
staffing
model,
we've
kind
of
always
used
lee
helped
me
out
with
that
of,
like
here's,
how
we've
done
staffing
I'm
like
okay,
interesting,
I'm
gonna
use,
try
to
use
some
of
that.
What
I'm
doing
it's
based
on
this
is
how
many
replies
we're
needing
to
solve
all
these
tickets
historically
or
you
know,
average,
because
obviously
more
tickets
means,
but
in
theory
the
number
of
replies
has
stayed.
A
A
It's
also
one
of
those
things
of
yeah.
This
is
crazy,
math,
brain
jason
and
not
everyone's
going
to
respond
to
look,
here's,
the
math
and
the
numbers.
I
think
it's
also
important
that
we
be
ready
to
explain.
Okay,
here's
why
we
have
the
numbers
it's
to
justify
this
concept
and
to
make
sure
we're
not
about
to
shoot
ourselves
in
the
foot.
B
Well,
yeah.
I
think
that
some
of
the
assumptions
are
based
on
data-
that's
historic
right,
so
we've
taken
data
from
what
it's
actually
taken
to
solve
tickets
and
technical
situation
yet
etc,
etc,
etc.
So
if
you
state
in
the
assumptions,
then-
and
nobody
really
argues
with
the
assumptions-
it's
difficult
to
argue-
with
the
results
right
so
and-
and
you
know,
I
know-
leave
pretty
intimate
with
the
the
model
we've
been
using,
but
it
really
is
fairly
simple
in
that
it
only
takes.
We
originally
only
take
tickets
created
right.
B
A
Yeah
no,
but
when
you're
when
you're
seeing
those
numbers-
that's
not
per
region,
that's
that's
all
of
us
in
a
day.
So
theoretically,
that
does
mean
like.
Oh,
we
need
10
agents
for
cicd.
Theoretically,
we
could
have
you
know,
apac
be
all
10
of
those
agents.
We
really
wouldn't
want
to
do
that
because
that's
the
only
times
they're
going
to
suffer
if
we
do
it
like
that,
but.
B
A
A
On
average,
that's
not
an
assumption.
I
pulled
the
areas
of
the
areas
based
on
each
region
and
assign
them
to
this.
Is
the
percent
this
region
encounters
and
give
or
take
a
percentage
point?
They
were
all
pretty
much
the
same
so
unilaterally
we
are
seeing
based
on
our
you
know.
Our
data
yeah
customers
use
git
lab,
like
customers
use
git
lab,
whether
it's
a
mayor,
a
pack
or
a
mia
like
make.
A
Yeah,
which
makes
sense
to
me
it's
like
right,
you're,
not
gonna,
only
see
geo
customers
in
amer,
you're
gonna
see
them
everywhere.
So
I
think
I
think
what
we've
got
here
is
a
good
kind
of
starting
point
and
also
what
I
like
about.
This
is
the
way
to
make
this
look
better
to
make
it
where
we
need
less
agents
is
right.
We
make
it
so
we
need
less
replies
which
could
mean
figuring
out
automation
to
help
solve
some
of
that
it
could
mean
just
finding
out
how
to
help
agents
solve
tickets
with
less
replies.
A
Even
if
it's
hey
take
the
extra
five
minutes
to
check
your
stuff,
you
know
check
your
reply.
Make
sure
you've
got
everything
answered
down
to,
let's
figure
out
tooling,
that
you
need
to
kind
of
build
this.
I
think,
by
separating
out
the
team
by
separating
out
the
areas
of
focus
we
kind
of
are
able
to
get
more
granular
on
okay.
So
we
see
that
26
is
instance,
management.
Okay.
Why
are
there
so
many
tickets
for
that?
A
B
Bucket
of
tickets
yeah,
I
I
totally
agree.
I
think
it
helps
pinpoint
the
things
we
talk
about
in
in
helping
engineers
troubleshoot
better
right
or
find
the
answers
better
within
the
product
and
if
you're
focused
in
on
the
areas
that
are
taking
the
top
percentage
of
replies
and
effort,
then
then
you're
keying,
in
on
how
you
can
be
very
more
more
much
more
impactful
on
areas
and
not
spreading
across
everything.
To
try
and
be,
you
know,
provide
a
universal
tool
for
every
type
of
area.
A
A
You
expect
to
see
it
like
right,
there's
a
way
to
calculate
how
many
agents
we
need
the
only
thing.
I
fear-
and
I
fear
this
based
on
our
historical
attempts.
This
sets
kind
of
a
baseline
of.
We
expect
five
replies
per
day
from
you,
focusing
on
this
area
or,
however,
it
is
split
across
when
you're
doing
multiple
areas,
and
I
fear
that
sometimes
the
team
sees
that
as
a
very
negative
just
because
they
see
this
individualized
metrics,
whereas
that's
really
not
what
we're
trying
to
achieve
here.
A
What
we're
trying
to
achieve
here
is
making
it
so
you're
less
stressed
and
can
focus
on
an
area
that
you
are
a
actively
interested
in
learning
or
b
are,
you
know,
have
mastery
and
these
tickets
are
nothing
to
you
anyway,
but
I
do
think
like
wording
and
communication
is
going
to
be
very
important
when
we
get
ready
to
make
this
issue,
because
it's
very
easy
to
look
at
the
numbers.
I've
crunched
and
sit
and
look
at
it,
like
oh
look,
jason's
just
trying
to
put
individualized
metrics
on
us.
B
Well,
I,
I
think,
that's
a
valid
concern,
but
I
think
we've
dealt
with
it
in
the
past
of
you
know.
What
we
try
to
do
is
model
what
we
need
not
not
measure
people
by
that
model
right
right.
So,
in
the
past
we
used
certain
number
of
tickets
per
day
and
that
generated
a
certain
number
of
tickets
per
month,
and
we
knew
people
were
blowing
that
out
in
certain
areas
and
others,
but
we
weren't
measuring
people
on
those
we
were.
B
B
E
E
This
is
how
many
we
have
right
now
in
terms
of
people
per
region
and
then
in
each
region
we
should
have
a
certain
percentage
of
those
people
kind
of
focused
in
these
different
areas,
rather
than
even
talking
about
like
we
I
mean,
certainly,
I
think,
using
the
number
of
replies
in
the
number
and
trying
to
calculate
the
number
of
replies
needed.
A
number
of
agents
or
whatever
is
good
as
a
model
for
creating
those
percentages,
but
I
think,
for
the
purposes
for
our
purposes,
in
talking
about
okay.
E
A
Yes,
I
am,
I
think,
that's
yeah.
I
think
that's
why
I
like
that.
You
and
tom
pushed
me
towards
focus
on
the
percent,
not
on
the
number
of
agents.
I
think
that
was
a
good
move
to
do,
and
that's
I'm
glad
I
did
it
that
way,
because
I
think
this
works
out
a
lot
better.
I've
got
the
raw
agent
numbers
in
there
just
for
the
sake
of
saying,
assuming
we
use
this
right
now.
A
A
I
think
what
we've
got
here
is
a
pretty
good
like
this
is
a
decent
enough
equation
that
I
can
figure
out
kind
of
how
to
get
into
explore,
probably
with
ilia's
help,
so
that
we
can
have
something
like
this,
which
becomes
a
dashboard
which
is
pretty
easy
for
us
to
check
into
and
say
right
as
long
as
we're
as
long
as
we're
seeing
either
the
numbers
are
pretty
much
the
same
or
you
know.
Oh
look.
Cicd's
jumped
up
like
10
percentage
points.
A
A
A
To
be
fair,
I
started
thinking
about
like
if
I
took
the
logarithmic
and
I
was
like
wait.
No
stop
just
stop
like
I
really
started.
Looking
I'm
like,
oh,
I
could
take
the
log
of
this
of
the
standard.
Deviation
like
no
just
stop.
Don't
do
this,
just
stop
what
you're
doing,
there's
no
way
you're
gonna
present
to
a
team,
an
equation
that
has
the
word
log
in
it,
and
people
are
good,
like
people
will
turn
their
brain
off.
They're
like
just
know,.
A
C
I
think
the
thing
is
too,
when
we're
messaging
this
to
people
and
excuse
me
very
deep
voice,
it's
it's
as
much
about
giving
them
the
reassurance
that
there's
some
science
and
some
data
behind
this
and
the
option
is
there.
If
you
want
to
see
the
maths
behind
it,
rather
than
going
here's
all
the
mess
to
prove
that
we've
done
it.
You
know,
I
I
don't
even
think
that's
necessary.
C
You
know
it's
good
that
we
can
go
absolutely
if
you
are
really
concerned
about
it,
because
I
I
think
the
other
thing
to
remember
with
the
support
engineers
is
that
their
perception
of
what
they're
doing
can
be
quite
different.
Like
eleanor,
I've
had
a
look
at
several
of
the
people
doing
eleanor
the
reality
is
at
most,
the
average
they're
doing
is
13
responses
a
day.
So
it's
not
that
much
above
10
but
they're
also
doing
a
bunch
of
internal
tickets.
So
for
them
it
feels
like
a
truckload
more
and
to
be
fair.
C
There
is
one
or
two
people
who
are
doing
double
that,
but
because
they're
doing
internal
tickets,
which
is
incorporated
in
these
stats
by
virtue
of
the
fact
that
they're
doing
these
right
now
plus
internal
tickets,
so
that
is
incorporated.
It's
just
not
numeric.
If
you
know
what
I
mean,
it's
not
something
that
we've
specifically
gone
and
added
in
there
directly,
but
it
will
feel
to
them
like,
oh
of
course,
I'm
doing
more
than
10
or
what
10
a
day
it's
like
yeah,
but
that's
figured
out.
Does
it
am
I
making
sense.
A
C
A
A
C
E
The
first
time
with
you
again
flesh
out
the
process
and
whatever
else
and
then
yeah
after
that
it
could
be
rotational.
It
could
be
just
volunteer
bases
and
yeah
until
we
figure
out
like
a
specific
way
to
do
that,
I
think
it
would
make
sense
that
support
ops
manager,
which
is
you
know,
obviously
you
would
at
least
be
the
dri
again
just
to
make
sure
it
gets
done,
not
necessarily
that
you
would
do
all
the
work.
D
I
agree
with
that
and
I
think
that
for
to
make
it
easier,
especially
around
time
zones,
I
can
do
it
with
jason
initially
and
then
probably
for
this
next
round.
I
could
do
it
with
jane,
so
it's
not
json
all
the
time
and
then
it
will
give
us
the
time
to.
You
know
find
which
gaps
might
be,
for
when
jason
is
not
there
all
the
time
situations,
and
then
we
can
work
on
a
rotation
after
that.
I
think
that
will
work
and
I'm
more
than
happy
to
help
there.
A
How
do
we
enforce
that
people
really
need
to
update
the
ticket
metadata
every
time
they
work
a
ticket?
And,
honestly,
I
think
this
points
back
to
the
triage
concept
of
like
we
need
to
be
triaging
tickets,
properly,
making
sure
they're
in
the
right
form
making
sure
they
have
all
the
right
metadata
feel
filled.
A
This
is
actually
a
pretty
consistent
problem.
Ops
hits
because
what
happens
is
someone
doesn't
do
it
and
the
next
person
doesn't
do
it?
The
next
person
will
do
it.
Inevitably,
somebody
goes.
Why
is
this
all
messed
up
and
I'm
like
because
no
one's
done
it
like,
if,
like
it
doesn't
just
magically
happen,
I
do
think
doing
as
much
magic
as
possible
to
get
as
much
of
that
automated
as
we
can
is
helpful,
but
there
are
gonna,
be
parts
of
this
that
just
they're
gonna
require
human
eyes.
A
I
think,
honestly,
this
comes
down
to
a
communication
thing,
maybe
even
looking
at
our
current
workflows
to
make
sure
that
they
strengthen
the
concept
of
the
ticket
really
needs
to
be
as
accurate
as
possible,
not
only
for
the
case
of
areas
of
focus,
but
also
for
zendesk
automations
other
people.
Looking
at
the
ticket,
metrics
potentially
hiring
you
hate
it.
Like
an
example,
I've
used
is
like
you'd
hate
to
have
a
manager.
Tell
you
oh,
we
only
need
two
l
r
people,
because
the
metadata
says
that
that's
what
we
need,
so
it's
really
important.
A
I
think,
honestly,
this
is
just
going
to
be
a
communication.
Re-Emphasis
of
hey
the
tickets
are
our
single
source
of
truth
for
customer
it
for,
like
you,
know
our
support
information.
We
really
need
to
re-emphasize
and
strengthen
that.
We
have
to
have
that
data
correct,
especially
since
part
of
our
workflow
does
say:
look
at
past
tickets.
Well,
if
pass
tickets
aren't
accurate,
then
you're
actually
just
perpetuating
false
information.
C
I
think
there's
two
aspects
to
that.
I
think
one
I
don't
think
there's
a
strong
message
on
that
and
onboarding
like
on
on
when
people
are
first
learning
and
when
they're
eager
to
to
absorb
all
the
new
things
about
how
to
how
to
do
this
at
get
lab,
there's
not
a
huge
emphasis
on
metadata
and
tickets,
and
so
then
that's
one
aspect
of
it
is
making
sure
it's
there
as
people
start,
but
then
we
also
need
to
do
like
we
did
as
we
rolled
out
dot
com
emergencies.
We
had
to
do
a
refresher.
C
We
did
a
refresher
module
for
people
to
go
right.
You
need
to
do
this
training
module
now
it
wouldn't
be
a
training
module,
because
it's
not
a
big
enough
message
for
that,
but
we
need
to
get
through
all
of
the
existing
people
to
go.
Let's
add
this:
as
a
you
know,
it's
a
it's
one
of
the
priorities
you
need
to
do.
I've
done
it
with
like
a
couple
of
people
and
one-on-ones
where
I've
gone.
Actually,
you
need
to
establish
personal
workflows
where,
when
you
work
on
tickets,
there's
a
few
fundamental
things
you
do.
C
You
know
you
make
sure
it's
got
an
org,
you
make
sure
that
the
form
is
correct,
and
you
know
that
message
is
not
ingrained
in
people,
so
I
think
it
is
going
to
be
a
matter
of
working
out
how
best
to
get
that
to
the
current
the
current
group
of
people
who
are
working
tickets
because
they're
also
the
ones
that
are
training,
others
and
encouraging
them
and
honey.
You
know
driving
that
message
home.
E
Yeah
yeah,
I
I
definitely
think
it's
like
part
of
like
automating,
you
know
with
problem
types,
it's
very
difficult
just
from
like
words
that
people
type
in
to
determine
what
type
of
problem
it
really
is,
and
I
mean
we
sometimes
work
on
tickets,
where
initially
it
looks
like
it's
filed
in
the
right
place.
But
then
you
know,
as
you
dig
into
it
more,
you
realize.
Oh,
it's
actually
a
problem
with
this
and
you
actually
end
up
having
to
change
the
problem
type
later,
which
I
think
is
fine.
E
What
what
I've
noticed
is
that
a
lot
of
you
know
a
lot
of
our
customers?
Don't
file
it
properly,
which
is
the
reality,
but
then
yeah
that
you
have
these
tickets
that
are,
you
know,
have
obviously
been
responded
by.
You
know:
support
engineers
and
they're
just
not
filed
properly,
and
if
we're-
and
if
we're
you
know
resourcing
and
looking
at
training
and
all
this
other
stuff
based
on
these
numbers,
then
it's
definitely
important
that
we
get
it
right
jane.
I
don't
want
to
spend
actually
too
much
time
on
this.
E
I
wonder
if
we
should
just
create
an
issue.
I
don't
know
if
there's
anyone
in
particular
in
the
group
who
wants
to
take
this
on
or
if
there's
anyone
that
you
can
think
of,
that
would
be
that
is
potentially
already
doing
similar
work.
That
would
want
to
take
this
on.
If
there's
any
ideas,
please
voice
them,
otherwise,
I'm
happy
to
create.
A
I
think
a
big
part
of
helping
communicate
this
is
it
will
really
help
their
own
workflows.
To
do
this,
I
get
pretty
frequent
questions
of
why
this
automation,
just
fire
five
replies
into
a
ticket,
I'm
like.
Why
was
it
five
replies
in
before
we
associated
an
organization
like
that's?
Why
it
did
that
and
that's
because
we
built
things
under
the
this
is
what
we're
supposed
to
do
right.
Things
act
really
weird.
When
we
go
against
what
we're
supposed
to
do
and
then
when
the
question
is
well,
why
did
it
do
that?
A
I
because
we
never
assumed
a
cat,
a
situation
where
we'd
get
that
far
into
a
2fa
ticket
without
associating
an
org
and
then,
for
some
reason,
have
already
sent
the
challenges,
which
was
a
case.
I
had
brought
up
to
me
today
and
I'm
like
wait,
so
we've
already
done
the
challenges
and
we're
on
verifying
them.
They're
like
yes,
I'm
like.
Why
are
you
just
now
associating
them,
though?
That's
really
like?
A
I
don't
know
what
to
do
with
that,
like
I
don't
know
how
to
tell
zendesk
to
be
good
on
that
part,
because
it's
like
that's
not
supposed
to
happen
at
all
yeah.
I
think,
like
it'll,
really
help
in
the
emphasis
of
like
this
makes
zendesk
work
better
for
you.
We
build
stuff
based
on
good
data.
Unfortunately,
as
we
have
seen
in
the
past,
not
all
data
is
good.
C
I
don't
know
how
we
do
that
in
ayman,
knowing
that
there
isn't
a
collective
team
meeting,
but
having
that
five
minute,
video
that
gives
the
message
we
know
everyone's
got
the
same
message:
it's
really
hard
to
make
sure
that
everyone's
reading
and
comprehending
a
written
issue.
So,
let's
yeah
I'm
just
suggesting
we
pivot
a
wee
bit
and
go
let's
attack
it
a
slightly
different
way.
What
are
you
smoking
about?
Jason.
A
So,
instead
of
that,
it's
like
every
five
minutes
and
automation
runs
when
you
don't
expect
it
to,
and
I
don't
know
why
it's
funny,
but
I
just
like
a
picture
of
zendesk
crying
felt
like
came
into
my
head
and
I'm
like
that
would
be
pretty
funny
yeah.
I
think
something
short
and
sweet
and
to
the
point
that
we
can
easily
play
for
the
teams
would
be
useful.
A
E
So
people
can
do
it
async,
that's
one
way
to
do
it.
The
other
way
is
to
we
could
put
it
in
the
support
we
can
review
and
then
either
have
an
issue
where
people
are
checking
out
their
names
or
do
what
tom
a
did
one
day,
which
is
to
have
a
survey
where
people
click
on
it,
and
then
that
gives
us
a
list
of
who
actually
watched
it
or
or
you
know,
acknowledged
that
they
they
watched
it
and
read
it.
E
C
I
I
I
specifically
didn't
suggest
support
week
in
review
because
of
tom's
survey.
You
wouldn't
have
seen
cynthia,
but
it
turns
out
the
results
were
28
of
people
actually
clicked
on
that,
and
I
know
a
lot
of
those
people
would
have
been
managers.
So
I
have
spoken
to
others
who
said
oh,
I
did
read
it,
but
I
must
have
skimmed
read
that
part.
So
so
yeah,
I'm
just
conscious
that
we
actually
have
another
challenge
there
unrelated
that
we
need
to
try
and
yeah
I'm
doing
a
little
bit
of
an
advertising
program
for
support.
A
I
mean
we
all
remember,
I'm
sure
we
all
remember
those
tests
that
are
like
read
all
these
instructions
and
then
blah
blah
blah
like
the
last
instructions,
like
just
put
your
name
on
the
paper
and
sit
there
do
not
do
anything
above
and
as
as
cute
as
those
were
when
I
was
little
I'm
an
adult
now,
if
I
got
one
of
those
things
handed
to
me,
it'd
be
like
I
don't
have
time
for
this,
and
I
just
like
throw
it
away.
I'd
be
like
no
yeah.
I
I
like
the
idea
I'll.
A
I
can
I'm
more
than
willing
to
be
the
dri
in
the
communication,
part
of
it,
since
I'm
sure
the
video
that
we
make
will
I'll
probably
assist
with
since
showing
things
under
the
zendesk
could
might
help
emphasize
the
problem
of
like
here's.
How
you
set
up
a
trigger
there's
all
these
options.
It
gets
really
complicated,
really
quickly,
yeah
yeah,
I
think,
and
I'm
pretty
sure,
someone's
currently
working
on
touching
on
the
onboarding
part.
D
D
A
A
Cool,
can
you
can
you
link
it
into
the
dock?
For
me
since
you're
that
efficient
yeah?
Honestly,
I
think
those
are
our
big
hurdles
to
kind
of
overcome
right
now.
There's
the
self-managed
knowledge
gap,
but
I
think
part
of
that
is
like
we're
already
kind
of
tackling
that,
with
what
some
of
the
other
managers
are
doing
and
part
of
the
like
workflow
pages.
Revamp
is
also
helping
on
that
part
of
what
I
like
about.
The
update-a-thon
issue
I
made
is
I've.
A
Had
people
be
like
I
didn't
know,
some
of
these
pages
exist,
I'm
like,
but
now
you
do,
which
is
awesome,
because
that
was
my
response.
When
I
went
through
the
entire
thing
was,
I
didn't
even
know
some
of
these
pages
existed
yeah,
I
think
that's
kind
of
our
big
hurdle,
the
other
one
is
going
to
be
a
question
I
want
to
pose,
and
I
want
you
all
to
kind
of
think
about
and
we'll
discuss
when
we
get
back,
which
is
for
implement
implementing
this.
A
A
A
E
I
do
also
want
to.
I
think
it
would
be
helpful
to
whether
it's
just
in
a
spreadsheet.
We
can
always
move
it
to
like
the
support
site
later,
but
as
a
first
iteration
just
take
the
percentages
of
the
different
areas
plop
in
the
number
of
people
we
have
per
region
and
then
kind
of
get
an
idea
of
like
how
many
people
per
region
for
each
region
would
we
be
looking
at
for
each
area
just
to
kind
of
give
everyone
a
sense
of
like
well.
E
You
know
how
many
like,
where?
Where
would
we
be
with
that
now?
Based
on
like
the
list
of
expertise,
I
think
part
of
it
is
going
because,
like
at
least
in,
in
my
view
of
things,
if
for
the
most
part,
even
if
like
some
adjustment,
might
need
to
be
done,
if,
for
the
most
part,
we
already
actually
have
the
people
we
need
in
the
different
areas,
then
it's
going
to
be
just
it's
going
to
be
a
zendesk
view
change,
but
that's
kind
of
it
right,
like
you're,
not
really
going
to
be
changing.
E
What
people
work
on
and
and
you're
not
going
to
be
drastically
changing
how
they
work
necessarily
because
we're
still
going
to
have
the
sla
views
we're
still
going
to
have
the
the
frt
views
right.
This
is
just
giving
them
extra
views
to
kind
of
focus
on
their
expertise
areas,
and
so,
if
we
already
have
generally
the
numbers,
we
need
it's
going
to
be
a
lot
less
change
than
we're
talking.
Even
just
talking
about
it
right,
it's
going
to
seem
like
a
lot
less
change
than
talking
about.
E
A
Yeah,
that's
the
reason
I
said
it's
kind
of
a
homework
question
thought
is
because
I
don't
feel
like
there's
a
right
or
wrong
answer
to
this.
I
feel
like
it's
just
a
matter
of
discussing
all
the
various
aspects
of
it
and
then
all
of
us
kind
of
deciding
this
is
what
we're
going
to
move
forward
on.
These
are
the
things
we
talked
about:
here's
the
pros
cons
and
all
this
stuff.
It's
part
of
our
communication.
A
Let
me
kind
of
implement
this
because
I
feel
like
if
we
just
come
out
with
oh
we're
doing
some
of
them
somebody's
going
to
go.
Why
our
answer
shouldn't
be?
No,
that's
often
an
answer.
I've
had
for
why
we've
done
something
in
the
past,
mostly
because
I
don't
know
that's
a
legitimate
answer
sometimes,
but
for
this
one
we
probably
shouldn't
have
the
legitimate
answer,
but
I
don't
know.
A
C
A
C
B
A
A
E
A
I
might
have
to
reach
out
to
you
to
help
me
figure
out
how
some
skill
sets
translate
into
various
categories.
It's
fine
yeah,
but
yes,
I
will
have
that
made
by
our
next
30
minute
meeting
and
honestly
that
I
don't
think
it'll
be
a
discussion
point
as
much
as
it'll
be
like
here.
It
is
look
at
it
cool.
Well
then
I
will
let
you
all
go
thanks
for
attending
great,
seeing
all
of
you
have
a
great
weekend
week,
rest
of
your
month,
whatever
it
is
to
you
fun
movie,.