►
From YouTube: 6 03 When to Close
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So,
generally
speaking,
you
want
to
consider
you
may
not
be
ready
to
close
the
ticket
if
they
haven't
said
that
it's
all
taken
care
of
if
they,
if
it's
not
clear
whether
they're,
fully
satisfied
with
the
resolution.
Remember
the
cheesy
example
from
a
few
days
ago
of
customers
saying
oh
yeah,
it's
working,
okay,
that
might
be
enough
of
a
trigger
to
say.
A
But
in
some
circumstances
you
don't.
So
that's
very
much
situational
right,
but
in
that
situation
be
sure
that
you
are
resolving
all
issues,
especially
with
a
long
running
ticket.
You
finally
get
something
resolved.
There
may
have
been
something
that
you
set
aside
for
a
while,
because
the
other
part
was
more
important
and
it
took
so
long
and
so
much
work
to
get
there
to
get
that
one
thing
resolved.
You
forget
there
was
something
else.
A
A
Do
we
agree
that
we've
resolved
everything
and
we
should
close
the
ticket,
and
that
was
pretty
rough
phrasing
right
there.
That's
not
the
way,
I'd
want
to
say
it
to
the
customer.
It
is
it's
sort
of
bullet
points,
but
that's
that's
what
I
think
we
want
to
try
to
get
agreement
on.
We
can't
always
get
it.
Sometimes
the
customer
closes
the
ticket
on
their
own.
A
B
So
I
guess
my
question
is
like
I
can
definitely
agree
that
we
should
kind
of
be
in
control
of
when
it's
solved
like
like
that.
You
know
we
I
I
think
we
should
feel
like
we
can
be
the
one
to
close
it
as
long
as
it's
clear
or
sorry
salt
to
take
it
out.
If
it's
clear
that
there's
nothing
else,
that
support
can
action
on,
because.
B
Actually,
even
if
we
try
to
explain
it
nicely
more
than
once
that
we
have
a
lot
of
customers
who
are
not
used
to
the
way
that
gitlab
works
and
the
way
that
gitlab
support
works,
where
we
clearly
state
that
if
we've
created
a
gitlab
issue
and
especially
if
the
development
team
is
engaging
in
there,
we
still
sometimes
every
so
often
have
a
customer.
That
just
says
I
don't
want
you
to
close
the
ticket.
B
Hey
I
see
the
development
team
is
engaging
with
you
in
the
public
issue.
You
know
if
there
is
any
information,
that's
confidential,
that
needs
to
kind
of
go
back
and
forth.
We
can
either
do
it
through
the
ticket
or
we
can
find
a
way
to
do
that,
so
the
development
team
can
see
it
or
you
know
whatever,
but
but
like.
If
the
gitlab
issue
is
not
closed
merged
fixed,
they
don't
want
us
to
close
the
support
ticket
and
I
think
those
are
you
know
there
are
some
cases.
B
There
are
other
cases
too,
where
support
just
cannot
action
any
further
for
security
reasons
or
legal
reasons
or
privacy
reasons.
Sometimes
I
think
this
is
again
more
so
true
in
dot-com,
but
there
are
cases
where
the
customer
will
be
totally
dissatisfied
and
we
actually
know
we
can
guess
that
if
they
fill
up
the
s
that
it's
going
to
be
bad,
but
we
cannot
compromise
our
security
or
privacy
just
because
the
customer
is
unsatisfied.
A
I
need
to
find
a
way
to
express
succinctly
here
it
I
may
be
relying
too
heavily
on
the
idea
that
what
you
see
in
the
materials
is
our
you
know
is
the
general
case,
and
that
not
only
does
it
depend,
but
there
are
exceptions
to
what
to
what
we're
looking
at
those
may
be
even
less
of
an
exception
and
more
of
a
you
know,
common
occurrence
right.
This
happens
all
the
time,
so
the
short
answer
would
be.