►
From YouTube: Areas of Focus Workgroup - 2020-12-03
Description
Areas of Focus Workgroup - 2020-12-03
A
A
If
you
have
better
ideas
by
all
means
change
it
up,
our
main
objectives
are
going
to
be
to
coalesce,
sauce
and
self-managed
into
you
know
one
group
in
zendesk,
because
as
much
as
we
love
to
talk
about
how
much
we're
the
same
team
as
long
as
zendesk
keeps
saying,
if
we're
not
that's
kind
of
gonna
have
to
be
how
it's
always
kind
of
viewed
it
also
over
complicates
a
lot
of
our
routing
in
a
lot
of
our
stuff.
When
we're
basically
like
no.
C
A
A
Well,
supportops
is
a
team
now,
and
I
have
two
free
views,
so
we
actually
do
have
the
bandwidth
and
time
to
do
this,
so
I
would
like
to
get
both
of
these
things
accomplished,
so
that
we
can
get
routing
and
all
that
fun
stuff
kind
of
fixed
up
sauce
is
in.
Like
the
the
link
where
we
talked
about
this,
I
will
find
it.
I
promise
it's
somewhere
buried
in
my
gmail
box.
A
A
A
I've
learned
about
self-managed
happened
in
ops
as
a
manager,
mainly
from
talking
to
cynthia
and
lyle,
as
I
tried
to
build
things
for
them,
so
I
have
a
huge
just
gap
of
my
knowledge
of
what
exactly
is
the
overlap,
another
kind
of
barrier
that
we
might
see.
That's
like
technical
ability,
it
might
be
opinion
or
feelings.
A
A
A
D
Like
that's
another
big
difference,
so
one
of
the
things
that
I
hope
we
can
do
is
figure
out
some
ways
that
we
can
coalesce,
even
just
the
workflows
where
we
can
make
sm
a
little
bit
closer
to
self-managed.
So
I
opened
up
an
issue
a
few
weeks
ago
about
using
gitpod
to
do
some
of
that.
Like
we
already
have
log,
we
already
have
the
support
uploader.
If
we
turn
off
attachments,
then
that
means
that
we
can.
E
There's
a
few
kind
of
very
sorry
excuse
me
half-formed
thoughts.
I've
got
and
some
considerations
of
some
things
that
we
need
to
just
be
mindful
of,
for
example,
the
impact
on
what
does
this
do
for
our
various
on-call
rotations,
so
they're
currently
focused
on
sas
or
for
c-monk
and
self-managed
for
customer
emergencies?
E
So
we
just
need
to
be
mindful
of
that
as
we
coalesce
what
you
know,
what
the
end
goal
is.
What
does
that
mean
for
on-call
rotations
as
well
and
on
the
what
you
were
saying
lyle
about,
for
example,
the
logs
and
the
different
way
we
do
them?
I
keep
having
this
thought
about
like
a
rosetta
stone
and
it's
what
I've
talked
about.
My
with
my
people,
who
are
doing
a
blended,
onboarding
approach,
kind
of
going
right.
We
need
locks.
A
Cool
so
yeah
the
on
call
one
I
wanna
I
wanna.
I
have
an
idea
on
that
one
in
long
since,
because
me
and
lyle
have
been
you
know,
just
slamming
our
heads
against
the
wall
figuring
out
rotations
and
how
to
make
sure
they
don't
overlap,
is
a
huge
struggle
because
of
the
current
way
we
do
things
I
feel
like
the
perk
of
coalescing
is
because
we
don't
have
to
separate
that
we
can
kind
of
get
the
rotations
where
every
rotation
has
the
same
number
of
people
on
it.
A
But
just
kind
of
like
a
thought
of
that
of
if
they're
coalesced,
then
we
could
have
self-managed
doing
cmoc.
We
can
also
have
you
know
the
sauce
people
also
helping
in
like
frt
and
sla.
So
the
perk
of
that
is
by
no
longer
having
to
separate
those
rotations.
We
can
actually
make
them
kind
of
uniform
in
size
to
make
sure
that
nobody's
frt
and
on
call
in
the
same
week,
because
we're
trying
to
we're
trying
rotations
with
various
different
sizes
of
people.
F
Yeah
so
obviously
I
mean
there's
going
to
be
a
transition
as
well
as
an
end
goal
right,
and
I
do
think
it's
important
for
everyone
who
either
like
I
think,
maybe
every
individual
or
manager
needs
to
speak
every
individual.
But
basically,
if
someone
doesn't
already
have
experience
working
in
one
or
the
other.
F
They
would
need
to
basically
take
at
least
a
portion
of
the
onboarding
for
the
other
side.
So
speak
right.
So
if
you're
someone
who's
completely
sauce
focused,
then
maybe
you
should
do
the
self-managed
specific
part
of
the
onboarding
and
vice
versa,
and
I
do
think
it's
important
to
understand
the
context
around
things
like.
F
Even
where
do
you
get
logs?
And
what
do
you
have
to
keep
in
mind
that
is
kind
of
different,
so
actually
ronnie
kind
of
requested
this
for
me,
but
I
had
written
an.
I
tried
to
write
kind
of
like
the
tl,
dr
version
of
what
you
need
to
know
specifically
for
com.
That's
part
of
the
dot
com
onboarding,
but
also,
I
think,
just
a
really
good
reference
for,
for
that.
F
Don't
have
one
for
self-managed,
but
I
think
what
we
could
I
mean:
there's
there's
different
ways:
we
could
do
this
either
we
could
write
a
separate
one
for
self-managed,
or
we
could
kind
of
put
all
this
information
in
one
page,
but
then
kind
of
call
out.
Okay.
This
is
how
it
works
in.com,
and
this
is
how
it
would
work
in
self-managed.
F
F
C
I
think
the
whole
the
whole
goal
that
we
want
to
get
to
has
three
angles:
one:
how
we
on
board
new
people
to
be
hybrid,
two,
how
we
make
people
who
working
dot
com
work
with
self
madness.
I
mean
how
we
make
them
feel
comfortable
and
then
how
we
do
the
other
side,
which
is
how
we
make
spanish
comfortable
with
dot
com.
C
So
this
is
the
tool
use
it
get
familiar
with
it,
get
familiar
with
the
features
of
the
tool
when
they
jump
to
some
tell
sales
manage.
What
I'm
trying
to
do
is
something
that
greg
is.
This
has
been
helping
me
with
is
training
them
not
into
this
is
how
you
install
in
docker.
This
is
how
you
install
in
from
source
or
omnibus.
No,
it
is
more
as
in
the
difference
like
okay
in
logging.
This
is
how
you
do
it
here.
C
Maybe
you
will
not
have
it
so
take
it
from
here
or
do
this
or
do
that.
So
I
believe
those
are
the
the
three
challenges,
but
I
believe
it
will
be
easier
as
a
first
angle
to
work
how
to
get
dot-com
people
into
sales
manage,
because
I
think
the
other
way
around
will
present
would
be
more
confusing,
because
I
at
least
I
see
the
dot
com
as
the
general
and
source
manager,
the
specific,
and
I
think
it
will
be
more.
It
will
be
easier
to
work
with
dot
com
people
to
get
into
something.
D
Conceptually
I
agree,
but
sas
staffing
has
been
the
bigger
challenge,
and
so
there's
some
need
to
make
sure
that
we're
covering
our
sas
tickets,
like
with
enough
people
so
yeah,
if
we're
starting
from
zero
totally.
I
definitely
agree,
but
we
have
to.
We
have
to
operate
in
the
environment
we
have
do.
You
have
a
way
to
help
with
that.
A
A
I
can
tell
you
from
my
experience
as
a
senior
when
I
was
self-managed
focused
my
greatest
weakness
and
how
could
it
test
this
was
gitlab.
I
could
do
almost
anything
until
it
was
like
a
question
about
merged
trains
and
then
I'm
like.
I
have
no
idea.
I
have
no
context
on
merge
strings,
so
I
do
think
teaching
self-managed
to
learn
how
to
work
with
gitlab.com
how
to
work.
A
A
F
I
know
james
is
working
on
at
least
evaluating
whether
auditor
role
is
enough.
I
know
that
a
lot
of
the
self-managed
folks
already
do
have
an
admin
account
from
the
dot
com
emergency
rollout.
So
it
kind
of
it's
it's
kind
of
interesting,
because
we
used
to
keep
saying
like.
Oh,
we
shouldn't
be
giving
everyone
in
support
in
admitting
account,
but
we
we
kind
of
aren't
out
right
like
we're
rolling
it
out
slowly.
So
not
everyone
does.
F
But
you
know,
in
a
couple
months,
more
than
half
of
the
self-managed
team
is
going
to
have
it
so
do
they
have
ask
access
already,
probably,
should
they
stay
having
admin
access?
Maybe
not
so
that's
what
james
is
looking
at
with
auditor
role
and
how
how
much
that's
going
to
be
limiting,
but
I
think
maybe
we
need
to
go
back
to
lyle's
question
of
at
least
that
is
in
the
dog
about
how
do
we
want
to
scope
this,
because
what's
interesting,
is
that,
despite
the
fact
that
you
set
up
these
two
objectives,.
F
And
there
are
only
two
objectives,
obviously
from
the
discussion
that
we've
had
we're,
there's
so
much
stuff
kind
of
related
to
it
and,
like
you
know,
there's
all
these
tangents
that
we
could
go
into,
and
maybe
we
should
start
back
with
your
objectives
and
say:
okay.
If
we
want
to
implement
this
in
zendesk
today,
we
want
to
change
the
views
so
that,
instead
of
by
product,
they
are
by
problem
type.
A
A
A
We
have
to
do
that
now,
because
the
ticket's
either
about
sauce
or
self-managed.
I
think
we
just
need
to
get
more
granular
with
it
get
a
little
more
specific
where
it's
like.
This
is
a
geo
ticket.
It
should
go
to
people
with
geo
knowledge
or
people
in
the
geo
group
or
whatever.
It
is.
However,
we
want
to
implement
this.
A
I
think
to
get
them
coalesced
in
zendesk.
That's
kind
of
what
we
need
to
do
is
like
cynthia
said:
okay
figure
out.
How
are
we
going
to
separate
the
tickets
by
problem
type
by
product
stage,
et
cetera,
et
cetera
and
that'll
help
us
get
it
so
that
it's
not?
This
is
a
sauce
ticket.
This
is
a
self-managed
ticket.
It's
this
is
a
geo
ticket.
This
is
a
merge
train
ticket
or,
however
granular
we
want
to
get
with
that.
B
That's
kind
of
the
direction
I
would
think
is:
let's
start
with
the
areas
of
focus,
break
up
what
we
think
those
are
identify
and
cynthia
talked
about.
You
know,
taking
the
training
and
here's
what
you
do
with
itself
managed
here's
what
you
do
in
its.com
and
you
apply
those
to
the
areas
of
focus,
and
so
we
start
out
and
say:
okay,
well,
here:
here's
what
we
think
the
areas
of
focus
are,
and
I
want
to
kind
of
stay
away
from
what
the
implementation
in
zendesk
is.
Maybe
there's
some
specific
things.
B
What
are
the
sas
and
what
are
the
self-managed
specifics
if
you
will
right
associate
onboarding
to
those
types
of
things,
but
as
you're
as
you're,
identifying
the
areas
of
focus-
and
you
say:
okay?
Well,
what's
missing
right?
What
do
we
have?
What
tickets
do
we
have
from
com
that
don't
fit
these
areas
of
focus?
B
How
would
we
adjust
and
that's
how
would
we
adjust
our
onboarding?
How
would
we
you
know
just
general
education
from
people
that
are
already
on
board
right?
I
think
I
think
kind
of
flipping
it
on
inside
and
getting
to
a
point
where
everybody
agrees.
These
are
the
high
level
areas
of
focus
and
it
covers
90
of
any
ticket
we
ever
get
whatever.
That
percentage
might
be.
F
Well,
I
do
think
that,
if
we
are,
I
mean-
I
think,
for
you
know
like
tons
of
there
could
be
exceptions
for
certain
things.
Right
so
so
say,
authorization
authentication
is
pretty
similar,
regardless
of
right
of
you
know
the
like
permission
issues,
it's
the
same
right
like
and
ci
runners,
all
those
are
very
similar,
so
we
could
say
like
okay,
you
know
there
are,
I
mean,
obviously
again
we
could.
You
know
we
could
go
kind
of
go
all
day.
F
F
So
but
I
think
all
the
other
problem
types,
even
tom
a
did
say
that
they
need
to
be
reviewed
and
revised,
and
so
I
think
that
this
would
partially
be
an
opportunity
to
help
kind
of
figure
out
what
might
need
to
change
around
problem
types
if
we
do
want
to
do
it
by
area
focus,
but
I
I
you
know
like
you
say
I
think
we
can
just
have
exceptions
and
there's
going
to
be
certain
problem
types
that
are.com
only
right.
You
know
things
like
the
ci
minutes
purchase
that
we
were
just
talking
about
today.
F
C
It's
a
good
question:
is
there
a
way
in
standards
that
we
can
create
different
forms
for
people
to
create
their
tickets,
but
if
the
ticket
gets
sent
to
the
send
you
the
same
view,
because
that
way
we
can
ask
for
the
self-managed
specific
and
then
the
dot
com
specific
like
for
the
customer.
They
will
have
a
difference,
but
for
for
us
we
will
not
have
one
well.
F
That's
that's,
I
think
I
mean
jason
can
talk
to
this
a
bit
more
if
he
wants
because
he's
more
familiar
with
zendesk,
but
like
so
right
now
our
views
are
separated
by
product,
at
least
the
gitlab
support
one
so
ignoring
lnr
for
for
the
time
being
right,
so
it's
separated
by
com
and
self
manage.
But
what
you
could
do
is
say
no
we're
going
to
have
a
view
for
each
problem
type.
So
the
view
will
just
pull
it
based
on
the
problem
type.
So
you
have
a
view
for
authentication
and
authorization.
C
A
A
We
can
actually
make
every
for
every
view,
not
care
about
the
form
at
all
which,
to
a
degree,
is
what
we
would
end
up
kind
of
doing.
It
sounds
like
obviously,
if
they
say
security,
it's
still
going
to
go
to
the
security
view,
and
the
easiest
way
to
do
that
is
the
form.
Is
security
but
yeah,
that's
actually
relatively
simple.
To
do
several
of
our
views,
like
needs,
org
tickets.
Go
to
that
view,
and
it
does
not
care
about
the
form
other
than
it's,
not
security
ar
professional
services
or
l
r.
A
A
C
Because
what
I
was
thinking
is
initially,
maybe
we
can
just
create
the
forms
and
we
ask
for
the
specific
for
his
free
site
and
then,
depending
on
what
it
has
on
the
form
you
will
go
to
the
view
that
has
the
knowledge
area
I
mean.
I
know
it
would
be
some
work,
but
it
wouldn't
you,
whereas,
as
you
were
mentioning,
it
would
not
be
that
much
and
you'll
be
an
easy
way
at
least
to
approach
it
initially
at
least.
A
Yeah-
and
I
think
part
of
doing
this-
is
the
ability
to
simplify
our
forms
a
bit
not
have
to
have
one
for
sauce.
One
for
sauce
account
one
for
self-managed
one
for
other.
I
really
dislike
the
other
view.
That's
probably
gonna
die
when
email
support
dies,
but
part
of
being
able
to
simplify
these
views
is
the
customer
will
have
a
better
experience,
because
we
won't
have
to
have
that
awkward
conversation
if
you
selected
the
wrong
form,
so
we
moved
you
over,
but
now
we
don't
have
any
of
the
information
we
need
to
troubleshoot.
A
So
here's
all
the
stuff
we
need.
So
I
think
that's
something
that
we
can
get
beneficial
out
of
this
a
beneficial
result
that
can
come
out
of
this
is
we
can
simplify
these
forms
to
be
way
more
specific
and
also
they're,
pretty
customizable.
So
if
you
know
we're
doing
authentication
tickets
and
cynthia's
like
look
every
time,
we
have
to
ask
for
this.
Okay,
we
can
go
edit,
the
form
to
say
well
we're
going
to
start
asking
for
this.
A
A
We
could
get
to
it,
but
we
just
we
never
really
have.
So
I
think
that's
something
we
can
also
kind
of
do
with
this
to
make
it
so
that
the
first
reply
the
customer
gets.
Isn't
we
need
these
logs?
We
need
this.
We
need
this.
We
do
this,
it
can
just
be
hey,
so
this
seems
to
be
the
problem.
Can
you
try
this.
D
I'm
tapping
all
over
the
place.
I
don't
know
I
actually
I
just
kind
of
duplicate
the
point
that
I
had
before,
but
I
I
think
it
would
be
worth
stepping
back
out
a
little
bit
and
figure
out.
What's
the
scope
of
what
we
want
to
accomplish
in
this
work
group
or
put
another
way
like
what
are
our
exit
criteria,
how
do
we?
How
do
we
know
when
we
don't
have
to
talk
to
each
other
anymore,
I'm
I
know
what
you're
going
to
link
to,
but
I
think
that
we
could
do
like
a
little.
A
Bit
also
yes
they're
there,
but
they're,
just
as
vague
as
the
objectives
at
the
top
of
this
dock
yeah.
I
do
think
we
could
kind
of
get
the
exit
criteria
a
bit
better.
I
think
setting
up
the
areas
of
focus
sounds
like
it
will
accomplish
the
coalescing
as
well.
So
it
sounds
like
our
biggest
thing
is
to
set
up
the
first
iteration
of
areas
of
focus.
It
sounds
like
that's
our
that's.
A
D
A
Yes,
it
was,
I
think,
coming
from
the
problem
side
where
it
might
be
too
specific
and
then
figuring
out
how
to
categorize
those
might
be
the
easiest
way,
that's
kind
of
like
what
I
did
with
like
what
I'm
doing
with
like
the
zendesk
mapping
is.
I
I
put
everything
that
was
there
on
the
dock,
and
then
I
said
okay,
so
I
think
that
might
be
the
easiest
way
to
do
it.
D
It's
just
never
used
it's
very
it
from
the
customer
side
like,
I
think,
we're
all
making
that
face,
because
it
would
be
beautiful
if
we
could
do
it,
but
from
the
customer
side
like
we
get
confused
and
we're
experts
in
gitlab,
like
what's
the
difference
between
verify,
ci
and
verify
cd.
When
I
have
a
problem
with
my
pipelines,.
E
E
F
F
It's
a
different
group,
even
if
it's
the
same
problem
at
the
root
anyways.
I
think
that,
in
order
to
capture
that
information
in
a
separate
issue,
we
might
want
to
consider
whether
that
should
be
required
for
solving
right.
So,
if,
if
a
support
engineer
is
trying
to
solve
the
ticket,
then
they
need
to
specify
which
product
stage
or
group
it's
related
to
and
it
might
be
related
to
more
than
one,
but
they
need
to
when
solving
in
our
market.
A
That
way,
we
don't
have
this
ambiguous
of
like
oh,
what
this
seems
to
fit
five
different
criteria.
We
can
go
at
the
higher
level
and
say:
we've
decided
authorization
tickets
go
to
this
product
group,
and
you
know
there
will
always
be
edge
cases
of
like
right,
but
this
is
actually
this
group,
even
though
it's
a
ticket
about
this,
it's
like
great.
A
We
want
the
edge
cases
we
want
them
documented,
so
we
can
figure
out
how
to
kind
of
tackle
those,
but
I
do
think
that's
like
further
down
the
line,
because
I
can
tell
you
even
using
git
lab.
As
long
as
I
have
I
don't
know,
the
product
stage
is
well
enough
to
put
tickets
on
them
like
the
second,
I
get
one
that's
about
like
I'm
setting
up
omnibus.
I
don't
know
where
to
put
that
ticket
anymore.
I
don't
even
know
where
it
goes.
F
A
And
there
there's
a
theoretical
future
where
there
is
a
yaml
file
that
we've
requested,
that
contains
every
group
and
the
stage
that
it's
in
and
then
we
can
automate
in
zendesk
updating
tags
or
whatever
we
need
to
for
it.
But
I
do
think
that's
going
to
be
like
a
future
endeavor
after
we
get
things
nice
and
organized
into
categories,
as
we
currently
have.
A
A
A
A
B
B
Then
not
common
that
makes
sense
right
and
then,
with
that
we
can
start
opening
it
up
as
well
and
saying:
listen,
it
doesn't
matter
if
it's
health
manager
sas
these
the
customers
have
these
have
these
problems
that
fit
into
these
categories,
and
until
we
get
clear
on
what
those
categories
are,
we
won't
be
clear
as
towards
that
we
can
be
successful,
coalescing
right
in
all
of
the
pieces
that
go
along
with
the
coalescing
and
say
yeah.
Our
suspicions
are
correct.
C
B
A
I'll
pull
some
of
the
past
issues
and
see,
if
there's
anything,
we
can
salvage
from
them,
but
a
lot
of
them
were
like
they
got
halfway
through
and
they're
like
this
is
impossible
and
I
don't
have
the
bandwidth.
Okay,
so
I'll
see
what
I
can
salvage
from
the
past
attempts,
because
I
myself
made
this
attempt
two
years
ago
and
it
was
like.
I
don't
have
the
bandwidth
to
do
this.
F
In
the
objective
itself,
where
jason
wrote
areas
of
focus,
I
linked
that
to
the
current
issue
that
tom
a
had
opened,
that
kind
of
outlines
a
bunch
of
things,
including
the
different
problem
types
and
whenever
he
pulled
the
table
a
list
of
how
often
those
problem
types
are
being
used.
So
I
think
all
of
like
having
everyone
in
the
group
review
that
as
well,
would
probably
be
helpful
just
to
kind
of
have
a
better
understanding
of
his
idea
of
how
areas
of
focus.
A
A
There's
also
the
account
ones,
so
we
can
pull
those
as
well
into
this,
because
I
I've
at
least
my
attempt
has
been
to
make
it
where
anyone
can
work.
The
sas
account
tickets,
so
yeah
I'll
as
an
action
item
I'll
make
sure
to
pull
new
metrics
for
the
problem.
Types
for
self-managed
sas
and
sas
account.
A
F
D
E
On
that
note,
can
someone
just
I'm
missing
something
here?
Can
someone
paint
for
me
at
the
end
of
this?
What
does
a
day
in
the
life
of
a
support
engineer,
look
like
like
when
they
come
into
zendesk
and
I'm
just
thinking
about
the
impact
on
slas
as
well?
Can
someone
just
help
me
understand
what
that
will
look
like
once
we've
implemented
this.
A
Yes,
so,
based
on
what
me
and
tom
had
talked
about
a
while
back,
the
vision
is
we'll
have
kind
of
the
standard
like
this
is
your
needs
organ
triage,
but
this
is
whatever
standard
views
that
everybody
would
have
access
to.
We
would
then
have
group
based
views
for
experts
in
various
regions,
authentication
goha,
and
they
would
have
a
view
that
just
pulls
those
tickets
based
on
the
areas
of
focus
that
they
can
work
on
and
kind
of,
get
nailed
out
knocked
out
a
little
quicker
because
they
have
that
experience.
They
have
that
knowledge.
A
We
also
envision
this
being
a
great
way
to
train
somebody.
Who's
like
I
want
to
get
better
kubernetes
great
we're
going
to
put
you
in
the
kubernetes
areas
of
focus
and
then
you'll
see
all
those
tickets
somebody's
saying.
Oh
I'm
doing
this
module.
You
should
probably
join
that
areas
of
focus
group.
Then
that
way
you
can
see
those
tickets.
A
So
I
think
this
is
kind
of
like
a
supplemental
thing
that
experts
in
the
various
regions
would
use
to
assign
tickets
to
themselves,
and
then
they
would
go
back
to
working
from
their
my
assigned
view.
In
theory.
What
we
would
see
is
that
we
have
all
tickets
going
into
some
category
some
area
of
focus.
A
F
I
mean
I
wouldn't
I
would
still
imagine
for
each
engineer
to
still
have
like
the
kind
of
general
needs
assignee
from
your
region
or
all
region
tickets.
This
would
kind
of
be
for,
like
hey,
are
just
all
the
tickets
that
are
unassigned.
Currently,
you
know
if
you
want
to
pick
one
up
or
whatever
it
is.
F
Like
10
percent
of
it's
a
topic
I
like
not
don't
really
know
about,
but
I'm
willing
to
just
kind
of
take
it
on
and
run
with
it,
and
then
you
know,
but
most
of
the
tickets
right,
especially
if
you're,
not
working
crew
or
whatever.
You
would
be
kind
of
looking
at
those
areas
that
you're
focused
on
either
you're
an
expert
in
or
that
you're
trying
to
learn
more
about
it.
A
Yeah,
I
do
like
the
idea
of
we
have
one
single:
this
is
our
tickets
with
sla
view
it
has
all
the
tickets
they're
not
separated,
because
they're
this
assassin
is
self-managed.
We
don't
have
to
worry
about.
Oh
well,
the
frt
or
the
nrt
of
sas
is
going
down.
It's
like
nope,
that's
that's!
The
nrt
of
support
is
going
down.
We
can
stop
separating
these
out
and
then
be
like
because,
honestly,
when
I
look
at
those,
it
feels
almost
like
a
blame
game
of
well
rsrt's.
A
You
know
our
nrt
is
going
down
and
sas
is
the
one
who's
lower.
So
it's
their
fault.
It's
like
no,
it's
our
fault
as
they
support
org
we're
not
helping
them
enough.
That's
kind
of
where
we
should
honestly
be
in
my
opinion
is
supports.
Nrt
is
this.
We
already
take
the
nrt
of
all
of
our
little
separations
and
say
this
is
our
nrt
right.
We
should
stop
separating
them
out,
though
we
should
say
this
is
an
nrt.
We
need
to
focus
as
a
team
on
improving
this.
B
I
was
just
going
to
add
to
that
there
is,
there
is
going
to
be
a
need
to
separate
reporting
by
customer
segment
when
we
start
reporting.
You
know
those
things
so
that
we
can't
lose
sight
of
that.
I
appreciate
and
yeah.
I
don't
think
I've
ever
seen
it
as
a
blame
game.
I
think
it's
trying
to
identify
their
cause,
so
we
can
identify
whatever
workload,
but
it
is
one
team
we're
all
kind
of
all
in
this
together.
B
That's
kind
of
the
the
generate
genesis
of
the
crew
right
is
to
get
it
even
more
focused
on
one
team
approach
to
everything
right
or
at
least
the
ticket
initially.
So,
but
you
know
as
we
go
through
all
this
there's
still
going
to
be
this
sales
segmentation
of.
Are
we
dealing
with
our
sas
paid
customers?
Are
we
dealing
with
our
self-managed
paid
customers
and
we
want
to
be
able
to
represent
that
to
some
extent,
but
also
let
them
know
that
everybody's
working
on
everything,
basically
so.
A
Yeah
and
complete
talked
with
elia
in
depth
about
how
we're
doing
our
metrics,
none
of
them
are
based
on
views.
None
of
them,
none
of
them,
are
based
on
forms.
We're
using
things
that
are
important
like
this
is
a
gold
customer,
their
sales
segmentation.
Is
this
we're
using
actual
data
from
salesforce
for
our
reporting
we're
using
the
data
that
we
have
synced
from
salesforce
and
zendas
for
our
reporting?
So
luckily,
no
matter
how
we
coalesce
it,
unless
we
seriously
screw
up
slas,
we'll
still
be
good
for
being
able
to
separate
out.
A
A
A
Yeah,
I
would
say
what
we've
got
for
a
task
list
right
now.
We've
got
a
wild
linkedin
issue
where
we're
already
kind
of
talking
about
the
barriers
for
coalescing.
So
that's
good
I'll
review
that
and
kind
of
work
out
of
that,
but
I
do
think
good
homework
for
all
of
us
is
to
start
trying
to
determine
those
areas
of
focus.
I
think
focusing
on
the
problem.
Types
is
good
as
a
starting
point
of
these
are
the
problem
types.
A
I'm
gonna
get
those
metrics
kind
of
pulled
over
somebody
just
added
to
read
the
areas
of
focus
issue
that
tom
a
made
way
back
when
definitely
agree.
It's
got
a
lot
of
information.
Tom
put
a
lot
of
heart
into
it,
but
I
think
that's
a
good
task
list
for
us
to
have
for
the
next
time,
but
I
would
definitely
say
yeah.
We're
gonna.
A
Do
this
async
that
way,
we're
not
limiting
ourselves
to
when
we
can
work
on
this,
it's
yeah,
so
everybody
kind
of
work
on
trying
to
figure
out
the
areas
of
focus
and
the
next
meeting,
we'll
kind
of
look
at
what
everybody
has
and
see.
If
we
can't
combine
things
or
separate
things
out
more
if
needed,
I
think
once
we
got
everything
kind
of
categorized,
we
can
figure
out
how
to
take
these
categories
and
then
start
figuring
out
how
what
implementation
or
you
know,
all
that
would
look
like.
F
A
F
A
Yes,
yeah,
I
I
was
already
gonna
kind
of
throw
those
on
there
of
like
I'm,
adding
these
by
the
end
of
the
month,
they're
very
important,
and
it's
a
contentious
issue
that
keeps
getting
brought
up
of.
Where
did
people
talk
to
us
about
their
ci
minutes,
because
that's
a
heart
that
was
a
hard
question
to
answer
until
I
was
like
we
make
a
new
field,
that's
what
we
do
did
lal
raise
his
hand.
Did
we
just
send
all
those
people
to
talk
to
lyle?
Now.
A
Cool
but
yeah
I'll
I'll
get
all
the
areas
for
self-managed,
sauce
and
sauce
account
and
the
ones
that
are
coming
that
I'm
gonna
be
adding
in
in
the
near
future
and
I'll
put
all
of
those
under
the
problem.
Types
I'll
do
that
by
before
I,
you
know
leave
for
the
day
today
and
then
we
can
kind
of
start
working
from
there.