Optimum Support,
Channels and Modes
As Rossware grows and grows, we find it’s necessary to make
occasional adjustments in how we dispense support.
This document is provided to help assure you are acquainted with what are
our present support dynamics. It
makes for a somewhat long description, but if you are willing to invest in a
single read-through, the resulting knowledge will enable us to better support
you.
At this point we have three full-time persons (Aaron,
Kenton and Brent) whose primary role is the direct provision of support.
We have two more (Karie and Josh) who secondarily fill-in for support (Karie’s
other tasks include building packages and development of training videos; Josh’s
main focus is IT and systems development).
I also pinch-hit on direct support, sometimes surprising a caller when
it’s me that directly answers an incoming phone call.
There are three primary modes by which you may seek support
from us:
1.
Call us on the phone.
Our office hours are M-F, 6:00 am to 5:00 pm Pacific.
Though we might occasionally fail, we make it a priority, within these
hours, to direct-answer every incoming call within two rings (this commitment is
why callers are sometimes surprised to hear me answer).
Please bear in mind the ring count may be different on your side than it
is on ours.
Our standard telephone number is 360-427-6000.
Based on the fact most folks are now using calling setups that do not
involve paying tolls for long-distance regardless, we are endeavoring to phase
out our toll-free numbers.
2.
Email
your inquiry. Here our goal
is to consistently answer within four business hours of receiving your email.
Thus, if it comes in at, say, 11 am on a business day, we should have an
answer back to you no later than 3 pm on the same day.
If, on the other hand, it’s 4 pm our time, it’s our goal to have the
answer back to you no later than 9 am of the next business day.
As a rule (more on this later) we ask that you please send your email queries to
our general support box:
support@rossware.net. Please,
in particular, do not send general support queries directly to me (i.e., yours
truly, Glade Ross).
3.
Initiate a support
connection. A support
connection can be initiated from the Support page on our website, but more
typically is done from within ServiceDesk itself (click on
FileFunctions in the top-left corner,
then pick the second option down).
If ServiceDesk is in a mode that prevents you from doing this, you can open a
second instance to do so. The
SD-Mobile application also has its own button for initiating a support
connection, and your technicians are welcome to use it, when needed.
Once a support connection is made, assistance can be as follows:
a.
Via direct chat.
This is something of a cross between a telephone conversation and email.
Using the chat box, you can direct type a question, and receive a
near immediate textual answer.
For some kinds of questions, you may find this is more convenient than either
emailing or calling on the phone.
The speed of answer, too, is likely to be somewhat intermediate, between email
and telephone call. So that you
know, we try to be quick and dedicated in these chats, but if the person that’s
taken your connection simultaneously has a telephone call, it’s possible he will
be juggling matters, resulting in delays between responses in your chat.
We try to do as well as we can on this, but it’s the nature of the beast
that sometimes turnarounds in chat are a few minutes delayed.
Please simply bear this in mind if you choose this instrument.
b.
Via direct work on your
screen. You can show us, on
your screen, the matter that concerns you.
We can work directly in your system, remote-puppeteering as it
were, to obtain the needed solution.
One note on this: if you need help with an issue at a particular station, please
assure it’s that station you connect.
You might be surprised, but we occasionally feel frustrated when someone
is having a problem at one station, yet connects another.
In addition to the above-described modes of standard
support (all of which are included as part of your standard support
package), we also offer:
4.
Incidental emergency
support. This is for the
situation where you’ve encountered a serious problem on which you desperately
need our assistance, yet it’s outside our standard business hours.
The support page on our website has a link on which you can click,
fill-in a form, pay a fee ($150) and thereby initiate a process to pull one or
more of us away from whatever we may doing during our otherwise off-duty hours
(i.e., sleeping, fishing, etc.), so as to immediately assist you.
5.
Ancillary For-Fee
Services. These are Á
la carte items, and vary by context.
Examples include: (a) if you want us to setup your techs’ mobile platforms with
SD-Mobile for you, we’ll happily do so at $35 a pop; (b) if you want us to
troubleshoot a fault that’s clearly in your system (as opposed to within our
software), we may offer to do so at the rate of $150/hour (minimum one-hour fee,
charged in half-hour increments thereafter).
In the realm of standard support (i.e., items 1 through 3
as listed above), we’d like you to understand some limitations:
i.
In regard to learning Rossware systems, our
support is intended to be available as a robust supplement for your own
self-training (where you are expected to use the self-training materials we
provide), and not as a direct substitute for self-study.
ii.
In general, it should not be expected that it’s
our role to do operational and setup tasks for you.
Examples: mapping network drives, setting up new stations, etc.
We have very purposely designed our systems to make them user
serviceable, and it’s our general expectation this is how such tasks should be
handled – subject to the caveat, if you are struggling on anything, then, please
indeed use us for assistance. We
need to help you get past any struggling matter, as smoothly and easily as
possible.
In regard to this, I must explain a dynamic that has sometimes produced
misunderstanding, occasionally even contrary feelings.
Though in each instance it’s our objective to help a user understand an issue
and know how to surmount it (so you can easily handle it yourself the next
time), occasionally our assistance technicians are so pressed for time they
decide, for the circumstance, it makes better sense to simply do a task quickly,
for you. It gets you past the
immediate need, but there’s a downside.
You’ve not learned how to deal with it yourself, so the next time the
same need arises, you seek our assistance again.
More than that, it may be, since we simply did it for you the last time,
you find yourself expecting the same “do-it-for-you” response this time.
Yet, this time the assistance technician may have time to explain and
show you how it’s done, and it might be a different technician as compared to
the last time. You might object,
even become steamed, insisting the other tech just did it for you, and that’s
how you want it managed this time.
Please understand: I work hard to persuade our guys to avoid taking the easy path
– of simply doing for you tasks you should instead do for yourself (though with
help from us, if need be). I often
invoke this nice little saying:
”Give
a man a fish and you’ve fed him for a day.
Teach him to fish, and you’ve fed him for a lifetime.”
Thus, when you find one of our techs wants to help you understand how to do an
action for yourself, please understand he is very much following my
prescription.
I heartily recognize most of you are not computer wizards, and do not wish to
be. Please be assured, the scope of
things we expect you to manage are very well within your abilities.
They are very simple, and are of a nature that
should be user managed.
If you’ve not otherwise picked up on the needed contextual concepts for
any such matter, it involves but a small amount of work to help you understand,
and thereby place you in a position where, going forward, you can very happily
fish on your own.
iii.
We hope you will not demand we fix (or otherwise
assume responsibility for) faults that exist in your own system (i.e., the
environment you provide for our systems to run within).
I think, as mere principle, this matter is clear and easily accepted.
However, application is sometimes murky, and for a few reasons.
For one, it’s not always obvious on which side a fault lies (i.e., within
your system or within our software).
Where there is uncertainty, I think the burden is on us to hunt,
troubleshoot, and hunt more if needed, until ambiguity is resolved.
For another, even where it's been found that fault definitely resides
within your system, it is sometimes more practical to us to make the software
better adapt to the fault, than it is for you to directly solve the fault.
This is not a frequent situation, but, where it occurs, I feel some duty
to make the adaptation.
Aside from such exceptions, we hope you will respect the general principle that
is summed in a metaphor I’ve sometimes used.
We provide an excellent boat.
If you decide to place our boat in a lake that does not have good water
on which it can float and run about, please don’t blame the boat.
Like any boat, ours too needs appropriate water (sufficient depth without
obstacles, not in
frozen state, other boats not blocking the way, etc.) in which to operate.
iv.
We hope you will please make your own “in house”
knowledge the first resource for users to call upon, and ours but secondary.
An extreme example otherwise has arisen where, on rare occasion, there is a
long-established user, and we’ve already prior expended scores of hours working
to help its personnel come fully up-to-speed in understanding how to harness our
systems. This company hires a new
person. Instead of inside training
that new person (i.e., via knowledge we have already invested to help existing
in-house personnel acquire), the new person is instructed to contact us,
expecting us to provide direct, one-on-one training for that new person.
We feel this is very wrong -- indeed, that it's a rather wanton abuse
of our support.
In a nutshell, we do not believe it should be our burden to repeatedly train
multiple personnel, within the same company, the same thing, over and over
again. On the contrary, our burden
should generally be limited to helping one person within the operation (at least
one on a given matter). That person
should be able to share understanding with others, as opposed to making us go
through the same thing over and over.
v.
We hope (and at least absent very minor exception) you will limit your
support inquiries to matters that genuinely concern either our systems or at
least use of them. Yes, we get quite a few requests for general computer
support, or for matters
that are clearly within the ambit of other entities, such as online interaction
with ServiceBench.
I think sometimes folks just don't know who else to call.
vi.
Please use our
general support staff, in preference to me (i.e., yours truly, Glade Ross) --
outside of circumstances where it's truly me you need. For more specific
guidance on this, I have prepared a separate
document (click here).
If you wish to call on me directly, this document provides guidance.
In summary, we know your time is very valuable, and we respect that. We hope you'll remember ours is valuable too, and will similarly respect ours.
All in all, we hope you will invoke our support in a manner that optimizes the value and resource expenditures on both sides. We want to be here for you, and we hope you will use us, anywhere and everywhere such usage is optimal overall.
Here is a little vignette for summary guidance.
Occasionally we receive a call from someone who has just spent a frustrating hour, seeking to self-answer a question, regarding use of our software -- a question we could have answered inside of 30 seconds. We feel bad, and wish the person would have called much sooner. The bottom-line is, if it's more efficient to use us (considering total resource expenditure all-around), and of course on matters that are properly within support, please use us. We very much want you to.