|
Post #1
02-09-2005, 08:45 AM
dmf
Site Member (inactive)
We are a software manufacturer that delivers
products via our self-run/owned ASP. Our customers are small to medium
size medical offices.
We recently put in a private chat-server so the front desk could communicate
with the doctor without knocking on the exam room door (doctor has wireless
portable at all times).
The chat is also used for tech support since we monitor servers all day.
What this has done:
- fewer phone calls
- even fewer emails
- more support questions
- average support question resolved faster
1a) If they have to call, I just lost time, had to say hello, how are
the kids.
1b) I tie up a phone line, like to keep them open for sales calls.
2a) If they email, no telling how fast response will be - does not solve
time critical issues, ie: what is this error msg that is on my screen?
3a) Support is now much easier to contact - so lessor issue questions
are asked, when a user went months thinking to themselves they would ask
the next time they called for something else. Now they ask.
4a) the average problem is resolved VERY quickly, usually we see the chat,
shadow a user session, look, review, resolve ... do what we are trained
to do without having to hear user go on and on about an issue we know how
to resolve in 20 seconds
I love our self-run chat server, users love the communications with
their own staff and directly with support department, worth every penny!!!
I now use that as a sales tool - shows how on the ball we are with support,
directly on-line.
Dan Frieling
__________________
Daniel M. Frieling, President
e-MedRecords, Inc.
dmf@compukid.com
(973) 726-4444 opt 5
Post #2
02-09-2005, 03:43 PM
Dave45000
Newsletter/Forums Member
would say that if I had to answer the phone,
I have a chance to increase this customer's loyalty to the product and
company. It's part of the enactment chain. It's part of retention marketing,
and it really bonds the customer to the product, particularly if you have
an expertiese development opportunity. It's not really about solving a
problem. It's about having a relationship.
If I have to use email, I do not ask. I have never had a satisfying resolution
via email. It doesn't matter is your company is great and gets right on
it. Other companies have taught me not to bother.
If I have to use technical support, something is very wrong. If I don't
get an immediate answer addressed to me specifically at my competence level,
then there's a good chance that the call is a waste of time. If the email
arrives tomorrow, I will have already deinstalled your software and called
a competitor, market power or not.
I hate self support. My issue is never covered and it takes all day to
find a phone number if that is even possible.
Software companies are supposed to provide working functionality and whatever
it takes to get it working. All these means of allocating costs to the
customer may not show up in hard accounting numbers, but CIOs have long
felt that IT wasn't delivering, and these costs allocations are why. When
the costs don't show up in the hard numbers, they are still felt and they
are pure waste from the customer's perspective.
Over focus on cost is killing the software industry.
David Locke
Post #3
02-09-2005, 04:25 PM
Charles Mills
Principal Moderator
You know, Danny, I had the same thought but I
didn't say it. That person on the other end of the phone line is not "lost
time," s/he's a customer. Ask 'em how the kids are. Then ask them
how they're using your product, etc., etc.
__________________
Charles
CharlesMillsConsulting.com
StrategicDueDiligence.com
Post #4
02-09-2005, 06:39 PM
DaveBrown
Moderator
Let me chime in on the side of Mr. Frieling.
A lot of companies are struggling with trying to figure this out. He seems
to have found a formual that works for him. The fact that his customers
are 'carrying a wireless portable' and we're talking chat, not email...sounds
like a good combination. The fact that customers are communicating more
frequently seems to indicate that they like the service. It may not work
for everyone...but that's why this is difficult. There is no cookie-cutter
solution that works for everyone! The true test would be a thorough customer
satisfaction survey and loyalty measurement...but it seems to me that he's
on the right track. When I first read his post, my thought was "I'd
like to do a case study" to understand the full picture. You may have
a model that would work for others.
__________________
Dave Brown
President
Support Center University
303-494-4932
dave.brown@SupportCenterU.com
Post #5
02-10-2005, 01:12 PM
dmf
Site Member (inactive)
Chat is a good method, from the sales angle as well
Good responses to my post about our use of the chat system. The chat system
is the 'quick/easy' way to get support without the need to pick up a phone.
I still ask how the family is, I still tell customers new beers they should
try.
Imagine you are a doctor, you are in the middle of doing an exam, and you
can't remember how to do something you don't do very often ... you aren't
about to say to your patient that you will be right back, you have to figure
out how to use your computer. No, you hop on the chat, without the patient
knowing and ask support a question in real time.
The chat does not replace the phone, it augments it. We still get phone
calls, just WAY WAY WAY fewer, and that makes us happy.
If we want to promote our new product, or just call to see how things are
going, we either make phone calls, we know all of our customers quite well;
we can post to our chat forum about new features that are being released;
we can direct messages to specific groups of people, like the owners of each
practice whose software/data we host. And think about this, instead of 10
phone calls repeating the same thing; I have one nice chat with a doctor,
between patients, list all this new cool stuff we're working on, then copy/paste
it to the next doctor and chat with him/her. I don't have to keep repeating
myself, except for answering questions.
The customers LOVE the chat system, they say it makes support so much closer,
so much easier, the answer are in writing that they can then forward to another
user or print it out; they even know how to go back in their history to find
a post with directions on how to do something they again forgot how to do.
Customers feel greater loyalty with this system, they see us online just
waiting to hear from them all day long.
I'm sure the support we provide is much different than what others need
to; many systems with an error is just an annoyance, if a doctor can't get
to a patient's medical record right when they need to, that can be quite
a problem.
Regards,
Danny
__________________
Daniel M. Frieling, President
e-MedRecords, Inc.
dmf@compukid.com
(973) 726-4444 opt 5
Post #6
02-10-2005, 02:33 PM
Dave45000
Newsletter/Forums Member
So how do you serialize chat. Or, how do I get
an answer quicker on chat than on the phone? Does everyone just dive in
with several conversations going at once? How does this work?
And, what is the cost differential between phone and chat?
David Locke
Post #7
02-10-2005, 03:00 PM
dmf
Site Member (inactive)
Chat server
I host my own web servers so it was very easy to put up the chat server.
The cost was not that much for the software; and I have the ability to host
my own chats for support. I also host chat for other companies, and all users
can only see the ones in their group/company.
So the delivery side is very cheap.
Right now as our company grows, we only need one person monitoring chat
at a time. If a new msg comes in while working on another one, it is quickly
glanced, and a decision is made, is it critical or can it wait. Depending
upon what it says, it may be given priority, it may be put into REMIND ME
mode to remind me of this in 2 hrs, or I may write back saying I'm on another
chat, be back in touch shortly.
One real nice thing, I can be on the phone with one and solve a totally
unrelated problem via chat, so as long as you have tech people that can multitask,
the ability to do so is there.
I never did a true cost analysis difference, I just hate the phone ringing,
and since we put this in, support phone calls are down probably 70%, and
total support requests are up; but most of those are literally one minute
answers to things.
__________________
Daniel M. Frieling, President
e-MedRecords, Inc.
dmf@compukid.com
(973) 726-4444 opt 5
Post #8
02-10-2005, 03:32 PM
Charles Mills
Principal Moderator
Despite my little reminder that those people
are not lost time, they're customers, this does sound very cool, Danny.
Thanks for sharing. I liked your posts so much I made them into their own
thread -- hope I haven't confused anyone.
I'm surprised the take-up rate is so good -- doctors are supposed to be
notorious for being conservative and anti-keyboard -- but I suppose your
product tends to self-select the more technical and progressive doctors.
As you point out, more choices for support can't be bad. Different strokes
and all that. Dave doesn't like e-mail-based support; I love it (assuming
they answer the e-mail).
I wonder if the chat would work as well if you had 1000 licensees. (I
know, you're looking forward to that problem.) If there were five hired
support hands and twelve messages came in within two minutes of each other,
how well might they do. (Not a question that is answerable at this time.)
I also wonder how well it would work for a product whose users were not
professionals who placed a high value on their time. Would you have one
or two customers who just wanted to chat all the time, like teenagers with
cell phones and texting.
__________________
Charles
CharlesMillsConsulting.com
StrategicDueDiligence.com
Last edited by Charles Mills : 02-10-2005 at 03:39 PM.
Post #9
02-10-2005, 03:57 PM
DaveBrown
Moderator
Just to clarify that Charles is saying David "Locke" does
not like email, not Dave Brown ! I love it.
__________________
Dave Brown
President
Support Center University
303-494-4932
dave.brown@SupportCenterU.com
Post #10
02-10-2005, 04:09 PM
Dave45000
Newsletter/Forums Member
Dave, I've just never gotten good support via email.
My problem with technical support is that I usually know more than the tech
rep. This is an 80/20 issue. The tech rep can't know every feature or every
detail. With phone support, I know I've had days where just another voice
will calm me down enough that I can think through the problem. Chat and email
certainly can't achieve those kinds of results.
I can't imagine a two hour delay on a chat response. What am I supposed
to do for two hours while I'm waiting around. Do you know what its like to
have to wait until the west coast crowd gets to work when you are over on
the east coast. Its a very long wait. It's very agrevating.
I love email. It is my favorite communications platform. I don't chat. I'm
not a short message guy. And, phone is like another planet. Yeah, what did
I do before email, not much. Only my cell phone has me calling people more
often. And, the cell phone saves you on router maintenance. I don't have
a hard line anymore.
David Locke
Post #11
02-11-2005, 08:53 AM
TomSweeny
Moderator
I was skeptical about chat a few years back,
but our research shows that chat is beginning to take off. (I have used
it a few times for support myself). Chat based support accounts for a small
percent of total support cases today, but we have found an increasing number
of support organizations offering it and widespread customer acceptance
(a surprise).
The other interesting observation about chat is that it offers comparable
service levels to the phone (response time, abandon rate, session time,
etc.), where web and e-mail support generally provide terrible response
times and closure rates.
I think it is great when a company explores new ways to support customers,
but too many companies of late have tried to push customers away from the
phone to save money. Certainly there are situations where e-mail and web
support (posting cases to a secure support web site) provides a good alternative
to the phone. The key to success of e-mail, chat or other delivery channels
is to provide reasonable service levels.
Philosophically speaking... we need to remember that support is about
helping customers get the most from the products they purchase. Support
is (or should be) about creating and sustaining relationships. The way
we deliver support should enhance our ability to accomplish this mission.
My two cents.
__________________
Tom Sweeny
ServiceXRG
Helping companies achieve service excellence
tsweeny@servicexrg.com
Post #12
02-11-2005, 09:55 AM
dmf
Site Member (inactive)
From a tech guy, who uses chat, email and phone
In response to what to do when 5 techies get 15 messages; what do you
do when 5 techs have 5 phone lines going and everyone else is getting a
busy signal. There is no busy signal on a chat ... and sometimes, while
working on another problem, I can chat back 'do this', or 'I'll call you
in 5 minutes', or if it isn't time critical 'I'll let you know later on
today'.
I can cycle WAY many more support issues in a much smaller time frame,
can handle more than one at a time, no one is on hold, no one has a busy
signal. And most of all - customers are told that the chat is a convenience;
if they have a critical issue and their chat is not responded to immediately,
pick up the phone and call tech support.
Since I use VOIP (Vonage), I always offer to call the customer and not
have them call us.
Email is a great support tool for things that are not time critical. The
chats can be put away for a few minutes, hours, dealt with in real time,
etc., email is good to list out instructions of what to do, to discuss
future features, etc., that is not what support is to me.
Customers just love the fact they can type 'Hello' and get a response
from tech within seconds, and never picked up the phone. They don't like
picking up the phone as much as we don't like having to answer it, even
though we don't mind helping, we like that part. Just the more efficiently
the better.
Our chat system has several levels of communications: 2-way chat, live,
type a line and hit ENTER and it sends, open communication (conversation
mode) window like you expect with a true chat. More, we use messaging,
like email messages, but they send/arrive instantly by chat program. For
instance, I may get a message 'please look at Carol's station, we don't
know what that message means'. I don't even respond to the chat, I go right
out and shadow Carol's session and see what's up. I will then send a chat
back telling what I saw, and what they need to know about it, no conversation.
In fact, we rarely use conversation mode, but it works great when we need
it.
We also have message forums, like this website, just not as extravagant.
Users can post messages to others in their practice, or I can post to a
forum that all users on our products can see. So an office manager may
post the practices holiday hours, and I may post a new trick that a user
showed us, or ask about feature requests, or announce new features we are
working on.
The system has another great side - users are in touch with support instantly,
from their desktop via the small client app; or it can be accessed with
a browser. So a doc working on paperwork from home, without the client
software installed (although it is a much better interface and they should
just install it), can chat with their office from afar, anytime.
Regards,
Danny
PS: only mildy confused about the new thread, once my Aricept kicked in
I was fine.
__________________
Daniel M. Frieling, President
e-MedRecords, Inc.
dmf@compukid.com
(973) 726-4444 opt 5
Post #13
02-11-2005, 10:03 AM
dmf
Site Member (inactive)
[Quote] Originally Posted by TomSweeny
... but we have found an increasing number of support organizations
offering it and widespread customer acceptance (a surprise).
Our customers love it, great feedback on it. And yes, it is just another
avenue to support, we find it to be the cheapest and most efficient - and
a great selling tool when doing an online software demo.
[Quote] Originally Posted by TomSweeny
The other interesting observation about chat is that it offers comparable
service levels to the phone (response time, abandon rate, session time,
etc.), where web and e-mail support generally provide terrible response
times and closure rates.
Philosophically speaking... we need to remember that support is about
helping customers get the most from the products they purchase. Support
is (or should be) about creating and sustaining relationships. The
way we deliver support should enhance our ability to accomplish this mission.
My two cents.
Success rate of solving problems is way high!!! Support is my #1 item
when it comes to dealing with my own vendors. I buy lessor products because
of better support, it's worth it.
The customers see the chat as us removing a big barrier between them and
support, click and say 'hello'. Doesn't get much easier. It is a great
tool to show everyone how much support means to you, it does help sustain
the relationship, you speak to them all the time, at least some of them.
As for the ones who don't have a life and just like to chat - I made it
a rule that we never respond with things like 'OK', or 'THANKS'. That is
'chatter', not chat. And we certainly never send 'YOUR WELCOME'. By not
responding like that, we teach people to not do it also. When 'chatter'
comes in, the best thing we do is answer it the next day.
Please be aware that I use the word 'chat' a lot - but think of that as
the 'package', we normally just send messages, 2-way conversational chat
is not used in most situations, only where necessary. The nice thing with
our system is you can instantly switch back/forth between message-mode
and chat-mode.
Regards,
Danny
__________________
Daniel M. Frieling, President
e-MedRecords, Inc.
dmf@compukid.com
(973) 726-4444 opt 5
Post #14
02-15-2005, 11:10 AM
PHanson
Newsletter/Forums Member
Chat for Support
I am curious about this. The original poster mentioned that he was in
the software industry. When a "chat" message comes in from a
user, and an answer is given to the user, how does this information then
become available to other users who may have had the same question? Is
there any documentation that is updated? Is there any "reference" sites
available so that someone asking a question can (hypothetically) check
a reference site, find an answer and be on their way. If you are interested
in making your software product more user-friendly, invest in a way for
the user to find information: online Help, access to FAQs that are organized
in a way that makes sense, manuals, whatever.
The scenario I envision is this:
User is on "Apples Maintenance." Has a question about the "Description" field
- how many characters can I enter?"
Sends a chat message to support. Support "finds out" (documentation,
experimenting, asking programmer) and sends back "The Description
field can have 50 characters."
User goes on their way, enters description. Problem solved.
WRONG!
What you've done is teach the user to not use the resources you already
are paying someone to maintain <documentation> and to ask someone.
What I personally think would be better is this:
Send a chat back to the user - "The Description field can have 50
characters" but add "I found this information in the online Help
by typing "Apples Maintenance" in the Index. All of the fields
are included on that topic."
Then, you've told the user *where* to look (the index) and "how" to
look (type what you want).
Paul Hanson
Technical Writer
Iowa
Post #15
02-15-2005, 01:18 PM
gail
Newsletter/Forums Member
Paul,
Our company is in an early developement cycle and we use chat with our
Alpha and Beta groups. We have considerable documentation and for the most
part its context sensitive in the software. However, there is a touch that
chat adds that goes a long way towards personal satisfaction and customer
loyalty. Sure, the customer can look up the information, but it helps our
development team know what has to be looked up. Many times we find that
we didn't put the GUI together in a fashion that was clear to the end user.
Also, in the time it takes a support person (our developers at this point)
to return the answer, we are encouraging an environment of cooperation
and collaboration. Some of our best new enhancements have come from impromtu
sessions with testers using our products.
This strategy was helpful in a startup that I was involved with a couple
of years ago as CTO. We were building some fairly complex educational software
and with each iteration we were able to add some great enhancements and
even full features based on our chat sessions that seemed to have tremendous
sales impact because it was what our customers really wanted.
In terms of customer relations you can't ignore the aspect of perception
management that you get from direct interaction. If a customer has to read
your doc, a task that most hate to do no matter how good it is, they are
likely to resent having to do so. When they get a chat session, their frustration
can be recognized and dealt with. They can be told its not unusual for
this type of question to come up and can be gently encouraged to check
out the online tutorials or approriate doc. Nobody like to be told to RTFM.
No one!!!
One of the other plusses is that we record the sessions so we can train
support and level 2 and 3 developers how to better deal with the questions
that come through. We used a popular IT help desk product that allows us
to keep statistics and to generate reports. We are able to find some trends
that where our products were going that customers didn't seem to want.
Another point to consider is that we keep our costs very low by using
chat and with this current project our developers work from their homes,
so I get instant feedback on what problems are happening for the nominal
cost of VPN services. I keep office and infrastructure costs down, create
a person to person feedback model that customers seem to like, and I'm
able to preserve the interactions for review later to help us build our
product. All in all a win.
On another note, we have found that serialization of the sessions is not
all that difficult. Depending on what the issue is as long as we give a "sorry
to keep you waiting be with you soon" at regular intervals we have
a very low call abondonment rate. I think that this comes from the fact
that a user who doesn't have a show stopper problem can surf the web, listen
to music, or walk around the house or office without the encumberance of
the phone. If they have a critical problem we route that to the head of
the line. If they can wait, we send links to FAQ's and product pages that
we feel can help. The big plus is that even if we are ready and the customer
is not we can do something else without losing the interaction.
I just ran a report on contact times of our chat sessions and find that
the average is about 15 minutes. I know that there are some that are much
longer due to waits and from experience I know that the customer's question
is generally answered within the first 5. Lots of the time is spent with
the customer giving us "feedback" or just chatting and building
a connection with our company.
Email has NEVER worked for us. Personally I hate email support. In chats
I can cut and paste error messages, or even send a screen shot as a file
to the support person. In some cases we are able to convince the user to
let us install a remote monitor and we can do it via the chat.
One of the nice things about chat is that it scales better than nearly
any other medium. One of the things that falls out of support is that if
you are having to do a lot of it then you are doing something wrong. Either
your product missed the mark for usability, its buggy, or your help and
doc stink. As CTO I worked out a deal with the VP of production where support
was augmented by QA personnel and developers when the volume of messages
reached an agreed upon high water mark. It was simple to do by having the
assigned staff connect to the chat server.
Along these same lines if there were particular modules that were having
problems, the production staff began helping with level 1 support. Developers
and QA will change the way they do things if they have to deal with the
fall out of crummy code or the result of poor testing.
As to the cost, at the edu company we purchased a few fast rack mount
linux boxes to run our chats on. IT used a 3rd party ISP to host our boxes.
They had OC3 lines and provided a great VPN solution for us. That kept
costs down, and all we had to do was assign people to connect to listen.
All in all a good solution.
Post #16
02-15-2005, 01:26 PM
dmf
Site Member (inactive)
Our software is very specific to the industry that we support; answers
are certainly never going to be "searchable" on the web, so for
us, that is a non issue.
As for reading the documentation ... here is our scenario, very different
than others ... mom is in the doctor's exam room with a screaming 6 month
old and the doc needs to figure out where in the system a particular item
should be documented ... they do not have time to leave the room and go
look it up, they don't have time to open documentation and they certainly
cannot call us from the exam room.
Chat for us solves that in a wonderful way, and the customers are amazed
how fast they can get their answer with hardly having to do anything.
For other products, support is a nuisance and telling them "look
in the manual" is a viable option. When you are taking $500/month
for support, you'd better be ready to answer questions, and answer them
quickly.
We know our product inside out and backwards, so it is very rare that
a question cannot be answered on the spot, although as we grow we know
this isn't necessarily the case; but each person can search their own archives
for word phrases and resend previous messages to other users.
The best thing to us with this over a phone call - the end user has the
answer in their own archive as well, so they know they don't need to ask
a 2nd time, they can find it themselves, and even forward the answer to
other users in the same practice.
We have not spent time fully honing this process, all we know is that
we love it and the customers love it.
Your points are well taken, for another industry, not ours
Danny
__________________
Daniel M. Frieling, President
e-MedRecords, Inc.
dmf@compukid.com
(973) 726-4444 opt 5
Post #17
02-15-2005, 03:00 PM
gail
Newsletter/Forums Member
Danny,
Remember my comments are based on your input and not being able to see
your software.
It sounds like there might be some GUI and training issues involved with
your product. If you are having your users (yes , I realize that health
professionals are difficult) are having trouble finding things then either
the GUI doesn't lead them correctly to the appropriate areas or you aren't
using context sensitive help.
Try to see if there is some correlation between help requests and areas
of your product or GUI. Sometimes some simple interface changes go a long
way towards end users getting the most out of a product.
I've found that when you have the type of call that happens in a critical
scenario that its time to look at information flow and have your GUI evaluated
by a user focus group. If you don't have a focus group these are invaluable
from a marketing and production standpoint and easy to create.
As to your situation being different, I'd gently challenge that statement.
Professional level tax software, personal training products (ours), point
of sale terminals all have the live customer factor where the user doesn't
have the luxury of opening doc or making a call. The customer's perception
of the user's competency is at stake. In the case of a professional tax
preparer know knowing his or her product while sitting in front of a client
can have the disasterous There are other examples as well, so I would assert
that your situation is not so unique and some of the solutions aren't as
difficult as you might imagine.
Post #18
02-15-2005, 04:43 PM
Dave45000
Newsletter/Forums Member
Paul,
I've been a TW for fourteen years. Back in the late 80s, I attended a
conference on hypertext, this before Windows 3.1 was released, before help
was anything, but a database application. There was some discussion of
aliteracy. Now, that isn't illiteracy. That's a preference for other forms
of information transmission. This is why manuals should present the information
redundantly as graphics. But, no print manual, or even online document
can provide all the info for ALL users.
In the MS Word for DOS 5.0/5.5 manual, there were references that said,
to learn more call technical support. So I did. They sent me FAX tips.
The underlying techniques turned me into an expert and cemented my loyalty
to MS Word, even when it is not the best TW platform, and yes, I moved
on. But, back then I used that trick to perform miracles. Thanks that we
no longer need that trick.
But, the point here is that information is delivered via an enactment
chain. That content originates all over the enterprise, not just tech docs.
I quickly came to see the entire scope of the content requirements, much
of it beyond the scope of tech docs. There is an absolute need for a single
enterprise-wide content distributional strategy. This keeps training from
consuming the entire budget as they are want to do. It also keeps everyone
in a positive and contributing orientation, rather than a competitive one.
I will tell you that the STC value adds are flat wrong. They are departmental
centric, rather than enterprise centric. There are business models that
would have TWs earning their portion of revenues, but nobody I knows pushes
those models. In fact certain people within STC are stuck on the project
management and doc spec and that is holding back others in STC that want
to see a different world.
When technical support asks me if I read the manual, my answer is "Do
you want me to tell you what is wrong with your manual." This actually
did happen. The manual would say "You can do x." But, it never
presented enough depth in the task content to actually achieve this. So
what do I do with these people? I deinstall their software. It is there
job to help me do what I need to do right now, rather than address any
perceived defects in me the customer.
The cost of such calls does not originate in bad UIs, another industry
myth, but in bad requirements elicitation.
The real problems that TWs face have to do with the perceptions created
by the TCO concept, which was created in '89. As defined, the cost of reading
a manual is a negative use cost. It is invisible to the customer's organization.
So there is no incentive to change the cost basis of application related
content. Even training, which is included is only included in the sense
of the vendor charge for training and not the cost of attendaning that
training. All content must vanish if software is to be straightforward
in terms of the TCO. Training people are taking advantage of the situation
and pushing an agenda that will eliminate TWs. Face it the days of software
TWs is over. Get another career even as TW employment is returning.
I would say that I have met developers with blame the customer attitudes.
My impression is that they need to be kept away from the customer. The
customer is not a cost. The customer is not an idiot. The customer is focused
on getting their work done, and we are getting in their way. The customer
is the source of everything in our industry. Ideas go nowhere without a
customer.
Get a better attitude and thrive. Serve the customer even if that means
training them to call technical support. No, we are not really training
them to do that. They learned that over a lifetime and will not change.
David Locke
Post #19
02-15-2005, 08:36 PM
PHanson
Newsletter/Forums Member
Agree
I agree with a lot of what you say.
My frustration comes when I peruse the call report system and see things
like "I looked in help text and I couldn't find it." The user
has a legit question that is not documented in the help text because the
question had not come up (the customer was trying to use a report to balance
against another report that it was not designed to balance against). Instead
of then routing that call report to me, so I could fix the documentation,
the CSR talked to the programmer, got an answer, and emailed the client
to say, "Take the total of columns X, Y, & Z from report 1 against
the sum of columns A, B, & C, on report 2."
Instead, the CSR told the client to do that and boom, problem solved.
Client goes on their way. That's the type of situation I'm trying to get
at. There are all these nuggets of information around, but how do you best
get those nuggests to the user in the fastest way possible? I don't have
the magic answer.
The other issue that gets brought up is how do TWers get their knowledge?
I've been a TWer for a decade and it's quite amazing. I'll be given a tidbit
of information that with a lot of work and investigation turns into a document
I can only hope our users think is helpful to them.
Case-in-point: the product I am trying to document at work requires our
installer's to use a specific menu to set up records for a process. There
are 10 menu options on this menu. My question was, why are options 5, 6,
and 9 on this menu? The record you create with those options don't interact
anywhere with the specific system configuration that the product requires.
So I ask questions. I've talked to the system designer, the programmer,
the QA tester, the trainer . . . I pepper our discussions with "It's
my understanding that the reason you would set up option 5 is if you're
doing "this process" but for the product we're talking about, "that
process" isn't allowed. So why is it on the menu? What changed?"
To bring this back to the original thread about using chat to provide
Tech Support, I agree that if it fits your users, do it. It may work for
your industry. I commend the idea that a problem was presented and an answer
was found. That's truly seriously awesome. I could use some of that at
my workplace!
Paul
Post #20
02-15-2005, 09:02 PM
dmf
Site Member (inactive)
[Quote] Originally Posted by gail
Danny,
Remember my comments are based on your input and not being able to see
your software.
It sounds like there might be some GUI and training issues involved with
your product. If you are having your users (yes , I realize that health
professionals are difficult) are having trouble finding things then either
the GUI doesn't lead them correctly to the appropriate areas or you aren't
using context sensitive help.
Try to see if there is some correlation between help requests and areas
of your product or GUI. Sometimes some simple interface changes go
a long way towards end users getting the most out of a product.
I appreciate the comment ... but the user interface that we have desigened
is the exact reason our system is usable. The problem is not that easy
to sovle. In primary care medicine there are more variables than I have
ever seen in 26 yrs in this field ... often the question is more of a discussion
point and not questions about where a specific field is. To give you an
idea of the scope ... take a 15 minute well child exam that has 60 questions
of 'history', 60 discussion items called anticipatory-guidance (both of
these change drastically with every age group, ie: you don't ask a 10 yr
old if they are still breast feeding); then we go to what is called Review
Of Systems, another 16 categories with about 120 total possible questions,
and you haven't even done a physical exam as yet nor considered immunizations.
We encounter items every day where there is discussion of the best place
to document some of the real oddities. We hear from docs all the time 'we
never had one of those before' type comments. Very trick to deal with.
I loved some of the other chat comments about time savings; as pointed
out, if I spend 15 minutes on one chat, it is probably 12 minutes of idle
time. I can do exactly what was pointed out, tell a user to try something...
then I can go onto 10 other things, when they finish doing something, they
can chat back the results. No long phone-hold times, no phone calls being
returned. Never really thought about this, but we rely on this all day,
every day.
Regards,
Danny
__________________
Daniel M. Frieling, President
e-MedRecords, Inc.
dmf@compukid.com
(973) 726-4444 opt 5
Post #21
02-15-2005, 09:09 PM
TomSweeny
Moderator
The demise of doc
I ran a support group a while back that consisted of 7 technical editors.
These people were all top notch writers that had come up through the support
ranks. Their goals was to sift through call records, tap the brains of
the most knowledge support analysts and engineers and develop a comprehensive
base of knowledge about each of the products we supported. I tied to get
the “documentation” group to cooperate with our efforts and
roll some of this great content into their efforts, but it didn’t
fit within their processes. The net result was that support went into the
business of publishing a more dynamic set of publications – this
is widespread across our industry.
Support organizations now have teams of editors, writers and knowledge
engineers developing articles, defining taxonomies and producing information
about the products they support. Most companies provide on-line access
to their doc yet it gets a fraction of traffic support KBs get. Doc and
help are going extinct, yet support KBs are not really the right replacement.
The time is right for a new approach.
Someone has already mentioned this in this thread, but the time has come
for companies to get smart and organize the experts that can capture and
present the appropriate information before, during and after product release.
Doc groups, support knowledge groups, curriculum developers, etc. all need
share the mission and burden of publishing the information customers need
to use product productively. There is a huge opportunity that is being
missed by companies that can’t think beyond organizational boundaries.
__________________
Tom Sweeny
ServiceXRG
Helping companies achieve service excellence
tsweeny@servicexrg.com
Post #22
02-15-2005, 09:56 PM
Dave45000
Newsletter/Forums Member
We would never update help between releases. That content would have
been allocated to technical support until the next release. Technical support
has to cover 100% of task performance regardless of it being covered elsewhere.
The typical support rep can only help the first 80%. The last 20% are going
to be over the reps head. And, those don't typically get escalated.
Chats can be logged and reused later.
David Locke
|
| 
RSS
