BACKGROUND
We are a small department of Texas Tech University that repairs and upgrades
computers, printers, and terminals. Under our charter, we can only repair or
upgrade computer and electronic equipment. Therefore, we are not a help desk,
a computer store, a network shop, or computer store. Here are some other
factors affecting our decisions:
1) CUSTOMER BASE: We are restricted to servicing ONLY university owned or
funded equipment. Unfortunately, the departments are not required to use our
services. Therefore, our jobs depend upon pleasing a very small (and often
VERY DEMANDING) community. We must continually fight off competition from
local computer shops and the big national service companies.
2) FINANCIAL CONSIDERATIONS: Unlike many internal computer support offices,
we are a revenue-based department, which means that we must create profit from
the sales of parts and services to pay for equipment, salaries, and operating
expenses. This factor definitely affects everything we do.
3) MARKET TRENDS: When I took over the shop two years ago, we were THE
experts on campus and many people gladly paid very high fees to retain us on
contract for computer maintenance. In two years, the cost of computer parts
has dropped dramatically and more people are capable of diagnosing first and
second level computer problems. Many departments have dropped expensive
contracts in favor of hiring a knowledgeable student to maintain computers.
In response to this change, we have dramatically reduced the contract costs
(to match local market trends), but we have not been able to reduce our fixed
overhead costs (salaries, benefits, etc.).
4) MANNING: We have a four person work center that has a Manager/technician,
two techs, and a receptionist/secretary. We occasionally hire up to six
students to augment our efforts. The secretary/receptionist is our customer's
first contact point. She usually passes technical questions to one of the
techs. In between phone calls, she tracks purchase orders, billing, and does
the book keeping. We have three techs, including the manager, who do all the
repairs, including site visits, repairs, upgrades, creating purchase orders,
answering technical questions, and even doing sales calls. As manager, I also
handle the various and sundry administrative duties associated with running a
work center, which can take up between 30% to 75% of my time. The other two
techs often spend 50% to 75% of their day on site visits. This alone makes it
imperative that we have a tracking system -- the secretary had no method of
quickly updating the customers, who would have to wait for the specific
technician to come back from calls. Of course, this creates customer anxiety
and frustration.
5) WORKLOAD: Because we are a small repair center, not a help desk, our
numbers will seem very low when compared to many shops that use this class
software. On average, we log approximately 100 repairs per month. We get
from five to twenty calls per day, but many calls are quick fixes that are not
billed or logged. When we get a call, we go on a site visit to see if we can
fix the problem there. If we cannot repair it on site, we take the equipment
to the shop for bench work. We have a four hour response time for contract
customers and do not have a stated response time for others. The ratio of on-
site fixes versus bench repairs varies wildly from day to day. We get calls
for both hardware and software problems, especially Windows and Win95. We
never know for sure what the problem is going to require.
6) TRACKING: When I arrived at my new job two years ago, there was no
tracking system, except written records of purchase orders and shipping
documents. There was no system to track the status of individual work orders,
link work orders and purchase orders, or to ensure the work orders were
completed. The only tracking system in place was placing simple status cards
with the equipment to denote parts on order.. This system required regular
reviews of each sheet and did not lend itself to catching overdue shipments.
In reality, the tracking system was left up to each technician remembering to
return the customer's equipment.
7) CONCLUSION: When I took over the shop, we were purely reactionary. The
loudest and most persistent customer got service first. The customers that
did not yell were put to the back of the queue. As I tightened controls, I
found a number of items that had been ignored for months. In fact, one item
had been shoved into a corner more than 18 months before! Coming from the
structured environment of the military, I found this intolerable! It was
obvious that we needed something to organize our efforts! Therefore, we have
been taking many measures to increase efficiency, quality, and controls. This
is the driving reason for obtaining a work order and call tracking system.
RESEARCHING REQUIREMENTS
Now that I recognized the need for a system, I had to define what the system
should do for us. While our needs may be far different from yours, the
methods will work, even for large shops. Prior to this job, I had 16 years of
experience as a US Air Force electronics technician. During my 16 years, I
worked up the ranks from technician to team leader to foreman to shop manager.
The Air Force uses a completely manual system to track work orders and parts
requisitions that requires up to 25% of the manning to run. This was not
acceptable for my small shop, but it did give me enough experience in tracking
systems to know how these systems work. The trick was to make a concise list
of requirements for this shop. Using past experience as a guide, I set out on
a few experiments to determine the requirements.
1: TECHNICIAN WORKLOAD:
At the beginning of this saga, I had no measurements of shop conditions.
Before I could possibly start the defining the tracking system, I had to study
the shop’s internal conditions. Because we had no tracking system, we could
only guess the number of jobs we handled and did not even know how many jobs
we had in-house each day! The technician’s individual work flow can greatly
affect the type and style of tracking system, so I had to document these
factors first. I could not follow each technician around to determine their
personal work load or know each and every task they accomplished each day. So
I implemented one of the most common management tools -- a personal time log.
In simplest form, each employee records his/her actions throughout the day.
To make your job easier, develop a form with codes for various actions,
equipment, and customers. To make data retrieval easier, you should
standardize how and when they record actions in these logs. I am familiar
with two methods, either at a set time interval, usually at 15 minute
intervals, or at specific events, such as recording each call or major repair
actions. We used a 15 minute model and recorded the top two or three actions
in the last 15 minutes. No matter the method, continue recording activities
for at least two weeks, but no more than a month.
The test showed one problem area for our shop that was a great time-waster.
We found that we almost always had two technicians responding to all calls,
primarily for safety. (We use a gurney to transport equipment to and from our
customer’s office and this can require two people to move it.) The second
technician would often stand around waiting for the other tech to finish the
task. The solution was to drop one tech at one building while the other tech
went to a second building. This resulted in a much more efficient work
process, even if one tech finished first. We found many other small time
wasters that were just as easily solved. You must correct these areas before
you automate the help desk. Otherwise, you WILL end up with an automated
mess.
Be prepared for incredible amounts of grief over this procedure! Many
managers have used this procedure to justify pay reductions or personnel cuts.
Your personnel may see this procedure as an invasion of privacy, as a threat
to their jobs, or as an incredible and useless burden. If you present this as
a positive & TEMPORARY measure and approach it with a positive attitude, you
can be successful.
2) EXPERIMENT 1: WHO, WHAT, WHERE:
This experiment answered these questions:
WHAT DO WE NEED TO TRACK? (What fields do we need to record?)
WHO ARE OUR CUSTOMERS? (And what info do we need to record?)
WHERE ARE OUR JOBS? (Where are the computers & customers?)
While this information seems very obvious, you still need to verify what data
you need to record. For this experiment, I decided to use a paper tracking
system to help me decide which data and fields are required. We filled out a
work sheet for each job and found that the information & form layout changed
daily for the first week. As the job progressed, we updated the sheet and
kept it with the equipment. We stopped the test run at only two weeks, mainly
because this was not a true tracking system. There was no benefit beyond
establishing minimum requirements. While most help desk or work order
tracking software will have fields for this information, you need to know
exactly what you track within your business. In addition to the standard
entries of address, phone number, and location, we found we needed a few extra
entries like TTU Account number, account type (grant, academic, or other), and
network type. As long as the tracking system had extra fields available for
these entries, we could use the system.
3) EXPERIMENT 2 HOW:
This experiment answered only one question:
HOW DO WE TRACK JOBS?
To measure this question, I created a paper tag system that included the
information from the first experiment and expanded it to include various job
statuses. To facilitate easy tracking, I created a pin-up board divided into
sections denoting the status of each job. To get a full sample, we searched
the shop for all old jobs and included all of the new jobs. This move really
helped us organize the work load. Each tag was assigned a one of five
statuses:
1) AWM; AWaiting Maintenance (initial call or on the shelf waiting for
a tech)
2) MIP; Maintenance In Progress (actual bench or site work)
3) AWP; AWaiting Parts (parts on order or exchange in progress)
4) AWA; AWaiting Approval (customer must approve the repair)
5) AWD; AWaiting Delivery (repair is finished, waiting for delivery)
As we worked on the equipment, we moved the tags from one status zone to
another as needed. Once we returned the equipment to the customer, we placed
the tag into a binder, to store for reference. Each tech should update the
appropriate tag for his/her job, but one person must be in charge of verifying
the tags and status board once per day. Keep a log to record closed jobs and
whatever vital historical data you need. We shortened this experiment to only
two weeks -- once we defined the statuses, we needed to continue with the next
step.
4) EXPERIMENT 3 WHEN:
This experiment was the core question to workload scheduling:
WHEN DO WE WORK ON EACH JOB? (What priorities do we assign to jobs?)
This was a continuation of Experiment 2 and ran immediately after that test.
For this experiment, I added colored dots to each job tag to denote the
priority of each job. After assigning a priority, I then grouped similar
priority tags within each status zone. (All Priority 1 tags to the top of
each zone, all Priority 2 tags just below, etc.)
It was interesting to attempt to set a priority schedule. Our biggest concern
was to respond within our contractual bonds -- four hour response time.
Therefore, our original top priority was for contract customers. However, we
found we needed to respond to some jobs immediately. Therefore we made a
special category for true emergency jobs. At first, we had no standard for
emergency jobs. Server failures were automatically added. For other jobs, we
had to rely on user input. Of course, most users always felt that their job
should be placed above all others. I quickly realized that we had to
establish parameters for this category. After several failed experiments, we
decided to add an extra 25% per hour fee for immediate (1 hour) response.
This caused our customers to consider carefully and prevented abuse. We found
that customers readily paid the extra fee for true departmental emergencies.
Our second concern was our walk-in or call-in customers. I knew that we would
regularly delay regular priority repairs for higher priority work. Therefore,
I created two categories for normal jobs, one for new jobs and one for
escalated or old jobs.
After we started using the software, we discovered that we needed a category
for high visibility jobs. We cannot afford to delay repairs for the
Chancellor, Reagents, Vice Presidents, or other college officers. This
category is below our contract customers, but above all other normal
customers.
Here is our “final” priority structure:
1 - Emergency (they pay a higher rate for one hour response)
2 - contract customers (they pay for contract coverage 2 hour response)
2a - Special & VIP Jobs
3 - Normal - Old (normal repairs that have been escalated)
4 - Normal (initial priority for most calls)
5 - Low (shop spares, loaner equipment, etc.)
With the tags arranged in logical sequence, I could finally manage the work
load! Under this test, we could finally ensure that we were abiding our
contractual limits (four hour response and overnight parts, etc.). We could
also see at a glance which item was next in the priority scale. The techs
also had a much easier time scheduling their own work as parts or new calls
came into the shop.
In theory, we will never delay a job in Priority 1 or 2. In reality, we have
had a few occasions where we have delayed some Priority 2 jobs during
unusually heavy work load. Priority 2a jobs may have a delay of a day or
two, but usually they get same day response. Priority 3 is the location for
the oldest normal jobs and allows me some flexibility in assigning priorities.
Priority 4 is our heaviest category and the normal location for new calls.
Priority 5 is almost never used or worked.
5) CONCLUSION:
These experiments supplied me with raw data on call frequency, contract
demands, and work load. The next step was to apply the data and define our
requirements in a software solution to automatically track our tickets.
RESEARCHING HD SOFTWARE
I had started the research on hard numbers a few months after taking this job.
My research took almost six months, including the initial software search. I
discovered that we could not afford the time and effort to develop a system on
our own. My boss and I were not comfortable hiring a programmer to create a
system for us. This situation lead to the third phase of my research --
matching existing software with our needs and budget level. I split this task
into several parts:
1) LOCATING VENDORS: When I started my search in early 1995, `I had no clear
path to search for products and vendors. At this point, I did not even know
what to call this class of software! At first, I looked in software catalogs,
such as the NEBS Software Catalog. It listed some products that might have
helped. I was initially interested in several products for call or work order
tracking. There were various products for auto, home, and, electronics repair
shops. These products looked promising, but did not offer demos. Because I
would not buy a product without trying it, I had to find another source.
At this point, I started searching the Web. I came across the Help Desk List
and visited the resources and vendors listed there. It was soon apparent that
there were few products available for under $10,000. After talking with my
boss, She limited me to $5,000 or less and required more justification. This
meant that I had lots of time to accomplish further research. During this
time, I obtained demos for Top Of Mind, Help Star, Clientele and others. In
each case, I simply called the telephone number listed in the Help Desk List
FAQ. After a few months, it was clear that I could not meet all of the
requirements, so I put the project on a back burner.
Then, in October of 1996, we had to adjust our operating procedures to match
the major market, customer, and structure changes I mentioned in the first
section. Knowing that I had some extensive research, my boss made the
decision that I would purchase help desk software within a day or two. This
started my flurry of postings on the help desk list and long hours of
research. Of course, I found that all of my software research was out of
date. Prices had dropped dramatically and many new packages were available.
I did manage to delay the purchase decision by a week, but that is still far
too short a time to attempt this type of research.
2) CONTACT METHODS: With my time constraints in mind, I decided to
eliminate any and all software that did not have a demo available on the
web. With only a week to decide, I could not wait on snail-mail to deliver.
I did have two companies overnight their demos, but neither made the deadline.
Attachment 1 is the e-mail form letter I used to contact the various vendors.
All vendors replied and were very nice, even if they did not fit my
requirements. A few of the product vendors out of our price range were very
helpful and pointed me to several new vendors that were in my price range.
3) EVALUATION METHODS: Once I had a demo of a software package, I had to
find a method to fairly evaluate each one in less than a week. This was
harder than it first seemed -- any of the packages that made it to the finals
could have worked for us. The evaluation process had to find a product that
would not only work, but fit the shop.
Since time was of the essence, I was swift and cruel in eliminating software.
I had six to eight demos the first day and eventually had twenty different
products. Fortunately, five products clearly would not work for us from the
start. However, that left me fifteen products to evaluate in under a week!!
I decided to split the evaluation into several phases:
A) FIRST IMPRESSIONS: To reduce training time and increase employee
satisfaction, I wanted a system that would be immediately intuitive. Because
I had considered allowing students to enter data, I had to have a system that
had clear procedures. I could not afford to retrain students every semester
or year! Some software simply did not have the right feel. Most of these
packages had strange layouts, or the procedures were unnecessarily complicated
or used unusual terms that clouded procedures. Other software was designed
for other types of operations, like hardware or software vendors. These
products had help desk modules, but also had modules specifically written for
tracking warranties or other modules that would not assist us. Other products
simply did not fit our needs and would have required too many work arounds to
meet our needs. Once I had weeded the field down to a handful of products, I
moved to the next phase.
2) DEEPER EVALUATION: Once I had products that met our minimum
requirements, I had to decide which product fit our work methods. After
reading posts on the help desk list, I avoided several products that might
have had hidden problems. Because I only had a week to evaluate the products,
I had only a few hours to install and try each product. This evaluation
process looked at the assumptions programmed into the software.
Because each package makes a few assumptions about the way we work, I used
this test to check those assumptions. If your work methods do not match the
software's assumptions, you will never be happy with it! Another
consideration is your employees. If the package does not match your shop,
your employees will always have troubles inputting data. This means that you
will always have trouble getting good data back out of it. Because you want
to get reliable data back out of the system, this was a major factor. Part of
this evaluation was testing the flexibility of data fields, reports, screens,
and lists. Again, this is an important ergonomic factor.
To be fair to all products, I took a set of closed calls and input them into
the system. Then I used the report module to retrieve sample reports. This
showed me the quality of data retrieved, the stability of the product, and the
ease of data entry. Of course, part of this was entering some customer,
status, priority, and other shop information. Because I had only a few hours
to spend on each product, ergonomics and intuitiveness played a big part in my
evaluation. Again, I weeded out a few products.
3) EMPLOYEE EVALUATION: This is a step that is absolutely critical to
success in your project. Your employees are the ones who will be entering a
majority of the data. If they are not happy with the product, you will find
many errors. After I had weeded the field to three candidates, I allowed my
employees to evaluate the finalists. I did not attempt to influence their
decisions -- I wanted them to tell me which software they liked and why. My
only influence was in providing the finalists. They found several problems
and bonus points that I had missed. Fortunately, they found all of the
software usable, so my evaluation up to this point was valid.
They approached the research in various ways, depending upon their jobs. My
techs were primarily interested in the help desk module ergonomics. My
secretary was more interested in customer information and job entry. To
perform their evaluations, I asked each employee to use the system in their
normal capacity. They entered new jobs, changed the status of existing jobs,
and updated jobs through our statuses. We also retrieved data from the system
and entered customer data, as appropriate. After each employee tested a
system, they wrote down their impressions of each product. I used this
information in our final evaluation.
4) FINAL EVALUATION: I took several hours to do one final evaluation of each
product. By this time, I had already found the product I wanted to purchase.
However, my employees had found some points that I had missed. I took one
last look at each product with their input in mind. This gave me one last
chance to change my mind. I did not change my mind in this case, but it was a
close decision.
5) CONVINCING THE BOSS: In my case, I no longer had to convince the boss
that we needed the software. However, you will have to broach the subject
eventually. In my case, I discussed this matter with my boss occasionally
over the months. I used my monthly report to keep it fresh in her mind. I
had gently prodded her with justification papers, reminders, and updates.
Eventually, this persistent, but gentle badgering produced the results I
desired. Because my boss demands facts and cost / benefit ratios for all
business purchases, I had spent much time creating justification. My best
advice is to start your research (quietly, if the boss is not thrilled with
spending the money), get all the facts you can find, and keep gentle pressure
on the boss.
ALWAYS REMEMBER TO USE FACTS DURING YOUR ARGUMENTS: Even hard headed bosses
can be swayed by hard facts. Some software companies offer "White Papers" on
implementing help desks. These papers list the benefits, cost savings, and
suggestions for getting it approved. Use these papers to the fullest. Data
Watch provides a particularly good white paper with their QueWatch demo
package. That paper was the one argument that convinced my boss that we
needed a help desk product. Above all, stick to your guns and be persistent!
FINAL DECISION:
Now we get to the conclusion of all my work. I will list the runners-up
first, with a quick synopsis of the good & bad points. Then, I will take the
time to list the good and bad points of my final decision and the rationale
for the changed requirements.
1) AND THE WINNER IS... Track-It from Blue Ocean Software. Their web page
is WWW.BLUEOCEAN.COM. This product just made our price limit of $1,000
(exactly). This software had the most features for our money, including
modules for Purchase Order, help desk, customer, configuration, library, and
training tracking. It also has an excellent Auditing function to import data
back into the system. The extra modules will be an excellent help and will
reduce the work load on everyone. While the software is really aimed at an
internal help desk, the modules will work nicely for us.
overall (9.0); price (9), usability(9), features (10), applicability(9.5).
2) RUNNERS-UP: There are many fantastic products under $15,000. There are
many great products under $10,000. There are a few really good products under
$5,000. There are the two products that made it to my finals:
a) Persist from Core Technology (www.ctc-core.com): This software is a
good, solid help desk with a convenient and simple knowledge base. It was
very intuitive to use and was easy to configure for our shop. I looked at this
product during the “back-burner phase. I had originally picked this product
as my solution to our problems. It's not fancy, but it is very functional and
easy to use. I rated this a close second (If it had the extra modules, it
would be first).
overall (8.75), price (9.5), usability (9.75), features (8), applicability (8)
b) Fault from Cybersource. (www.cyber.com.au) Again, this looks to be a
simple, solid help desk (problem resolution) solution. It's not quite as
intuitive as Persist. This software is an almost product: almost finished,
almost intuitive, almost great. It is just a bit rough around the edges.
overall (7.5), price (8), usability (8), features (7), and applicability (7)
3) HONORABLE MENTION: I had the opportunity to look at many products. While
I did eliminate a few products at first look, I came up with a list of
products worth serious consideration. You have already seen the software that
fit best with my shop. Here is my list of software that did not quite make
the list:
a) Call Tracker 2020 Solutions www.com.au/neiss/2020 $$$$
b) Heat Bendata www.bendata.com $$$$
c) Clientele Clientele clientele.com
licensing
d) Top Of Mind Malloy Group www.malloy.com $$$$$
e)
f)
3) AFTER IMPLEMENTATION: After purchasing the product, you must start the
installation project. In our case, we were running a small Windows 95 network
attached to the Campus Backbone. We had a W95 print and CD server already on
the network. It was a simple matter to install the software on this server
and share the directory. The only step that was not clearly explained in the
Track-It manuals was that each client had to map the drive, otherwise, the
installation was simple and fast. Track-It does not install anything on the
client machines -- all software and data reside on the server. This can lead
to very slow response on busy network segments.
After installing the software, I spent a few days inputting base data,
including customer information, priorities, product categories, statuses, and
shop information. After I had the basic information in the system, I started
adding existing old jobs. At the same time, I gave a few short training
sessions to my employees and started them working on new jobs.
Thanks to the intuitive layout, the training took only about fifteen minutes,
including questions. They had no confusion on how to access the modules or
which module does what. Buttons, fields, and modules are cleanly laid out.
During the first week, we did make many adjustments, based on the experience
gained and the quality of the reports. Our growing pains lasted about a
month, but after that things have gone very smoothly.
4) TRACK-IT MOUDLES: While Track It! actually targets internal help desks/
MIS departments, we will eventually use all of the modules for similar
purposes:
a) HELP DESK: We will use the help desk module without much
modification. We have had to work around a few problems. We changed “TYPE”
field to a “STATUS” field. We record the equipment’s model and ID numbers in
the short description. We add the serial number, warranty info, and purchase
order number in the long description field. A very good point is the filter:
With it, you can select open jobs, closed jobs, or both very quickly. You can
also filter the list for specific customers, priorities, status, department
number (not name), staff member, or date range.
B) PURCHASE ORDERS: Again, this required no modification, except for
one work around: We record the Work Order number in the comments field. This
module provides an ideal method to track open purchase orders, product
returns, and out-sourced repairs.
C) INVENTORY MODULE: For a traditional MIS department, this module
links customer, department, and work station information into one grand
database. We use this for our customer database. Because this uses an MIS
model, Track-It does not allow adding customers on the fly. Therefore, we add
regular customers to this database, without the workstation information. We
have our work stations added to the list with the Auditing function. Next
year, we will add all of our contract customers to this database, to better
follow our contracts. The auditing function will assist us in filling out the
contracts and documenting the equipment.
D) TRAINING MODULE: This module was intended to track user training.
We will use this module to track internal training of our technicians.
E) TRAINING LIBRARY: This module was intended to track training
equipment and materials. We are using this module to track our loaner
equipment. We have a limited number of loaner items that we issue to our
contract customers to replace monitors, printers, terminals, and computers
with parts on order. In the past, we had a sign out sheet to track these
items. This library makes an ideal location to track our equipment.
F) REPORTS: While the default reports are very informative, I have
used them to create my own reports. This change allows us to tailor the
reports to meet our reporting requirements.
G) KNOWLEDGE BASE: The knowledge base is very weak. It is a problem-
resolution database that does not lend itself well to use. It simply lists
the titles in alphabetical order. You click on a title and it displays the
text. There is no way to automatically add entries. Because we are not a
help desk, we use this area to list our standard entries for each status.
5) SHORTFALLS: While we selected Track-It primarily for the multiple
modules, we knew that we were selecting a product that was not as polished as
the runners-up. It has some irritating flaws in design. Here are the prime
problems:
A) NONSTANDARD CONTROLS: The list views do not use the standard
windows scroll bars. There are simply two arrows for up and down. You have
no access to page up/down function. If you get to the bottom of the list, it
automatically selects the last item (the arrow disappears and you are now
clicking on the last item).
B) WINDOWS 95: Track-It does not recognize or use some of the new
features found in Win95. For example, Win95 offers a small menu with Copy,
CUT, Paste, options. This is not available in Track-It. The ^X, ^C, ^V keys
do work in most windows.
C) SEARCHES: There are few searches available. In the Work Order
Module and Purchase order modules, you can search for a specific work order or
purchase order number. You can filter the Help Desk list for customer name,
Staff member, priority, status (type), department number (not name), a date
range, or status (open, closed, or both). You can filter the Purchase order
list for vendor name, staff member, amount (exact or range), date range, and
status (open, closed, or both). Without using the reports module, there is no
way to search for work orders on a specific equipment ID. You can call a
repair history for an item in the database. Unfortunately, this does not help
us – Most of our customer’s machines will never be entered into the database.
Other modules have similar limitations.
D) LIST VIEWS: The list views can be a source of frustration. You are
stuck with the fields and sort order programmed into the sheet. For the help
desk module, you can only see the Work order number, date, time, short
description, customer name, and staff member. (Priority, status, hours
worked, and other fields are all missing!) To make matters worse, you can
only view this list in date (Work order number) sort. If you use the reports
module, you can easily sort the work order list by priority and status. For
our own purposes, we run a morning report that sorts the jobs by priority,
status, and date. We use that report to schedule the work.
E) LINKS & ON-THE-FLY ADDTIONS: Because Track-It was designed for an
Internal MIS department with a fairly static customer base, you cannot add
customers to the permanent rolls while taking a call. The same is true for
adding parts to the purchase order list. This does cause some work slowdowns,
but it is not an insurmountable problem.
F) CRASHES: Track-It has a tendency to crash the client computer after
a long period of inactivity. Of course, users can prevent these crashes by
always logging out when not active on Track-It.
G) ESCALLATIONS: Track-It is modeled for manual escalation only.
Because we have a low work order, this is not a problem for us. However,
other shops will find manual escalation too taxing.
H) ALARMS: Track-It has no alarms, timers, or other automated
controls. The software does offer a due date on the help desk and purchase
order modules, but you must spot the date to use it. We are looking into
other products to assist us, including MS Schedule +.
6) RETURN ON INVESTMENT: This is very hard to gauge, because the help desk
software deals with organizing your work. Because we have no productivity
numbers from before implementing the software, it's very hard to gauge exactly
how much better we are doing now. I can state that we have dramatically
reduce average backlog. The system seems to give us an extra 20-40 manhours
per week because we are now wasting less time reacting to emergencies.
Important jobs get done on time, so we are not “putting out fires”.
Customer satisfaction and confidence has soared. We finish jobs faster and
have reduced our back log by 75% already. When a customer calls, we can now
answer questions about work order status swiftly. Prior to implementing the
software, we were loosing customers because we had very slow turn around (even
with quality repairs). Now, people are now content to wait (sometimes days)
until we can show up to fix their problem -- simply because we are far more
organized.
These are hard things to put into firm numbers, but I believe that we have
already got the $1,000 back in less than three months
7) CONCLUSION: While Track It is not as polished or "slick" as other
programs, it did present the best solution for our problems at our price. If
I had had more time to search, I might have found a product similar to Track-
It that was meant for a repair shop like ours. However, even with Track-It’s
limitations, we are happy with our purchase.
It has organized our workload, reduced our back log by 75% (or more), and has
paid off dramatically in customer satisfaction. It has improved our bottom
line and given us control of the situation, and those were my objectives.
ATTACHMENT 1:
This is the e-mail Inquiry I sent to the various vendors.
*****************************************************************************
Hello,
I am the manager of CompuTech, computer repair center for Texas Tech
University. We are a repair center for PCs, Macs, terminals, and printers.
We have no sales floor and most often conduct business on site. We are a
department of Texas Tech and can only service university computers. My boss
has decided that we need work order tracking or help desk software NOW. This
means that she wishes me to order software either Thursday or Friday at the
latest. Since it is now Wednesday evening, I need a very swift reply.
I would like to know if your company offers:
1) A demo or slide show of your product, so I can get a feel of the
software.
2) Educational pricing (we are a department of the university)
3) 30 day trial period for your software, to determine if your
software fits our needs.
4) Do you accept university purchase orders?
5) Do you offer smaller products at a smaller price?
This is what we have determined that we need from the software:
1) Cost must be under $1,000 ($500 preferred)
2) Run on Win95, Microsoft Network (Win95) and/or Novell 3.11
3) Supports 4 users and up to 25 calls per day (small shop)
4) Track work orders through these statuses or holds:
a) open call (user calls)
b) pickup equipment/on site service
c) awaiting maintenance in shop
d) on bench
e) awaiting parts/approval
f) awaiting delivery
g) closed
* we may add others as needed
5) Manager's reports on time in various statuses, individual
equipment statistics, technicians work load, etc.
6) Allow us to modify various equipment and status codes
7) Here is a wish list of other items wanted, but not needed:
a) Technician time sheets/time tracking
b) knowledge base (even rudimentary & unpopulated)
c) purchase order tracking
d) invoice tracking
I found information about your product in the Help Desk Listserv FAQ and/or
your web page and I would appreciate more information on your product. As I
stated above, time is of the essence, and a slow reply may mean that you are
out of the running. I'm sorry for the rush, but I hope to hear from you soon.
Thank You,
Tom Heisey
Manager, CompuTech
Texas Tech University
Tom Heisey
Manager, CompuTech Texas Tech Univeristy
(806)742-1662 FAX (806)742-3498
*****************************************
* theisey@mail.ctec.ttu.edu *
*****************************************