Page PageSusan M. Johns
7th Annual CODI Conference
Minneapolis, MN
April 10-12, 1996
The purpose of this presentation is two-fold: 1) how do we as systems administrators, directors, persons responsible for our automated systems -- how do we deliver customer support to our fellow library staff and patrons, and 2) how do we deliver and/or receive customer support from our favorite vendor(s)? This two way street is defined as the "external" and the "internal" customer by Leland and Bailey in their book Customer Service for Dummies.
That said, how many people here are from ALS/Dynix Customer Support? How many of you are system administrators? And how many of you have brought tomatoes, tennis balls, or other things to throw? Oh, you were going to juggle them? That's okay then.
One of Karl Albrecht's many nuggets of insight in his book, The Only Thing That Matters: Bringing the Power of the Customer Into the Center of Your Business, is the definition of "Customer Perception--Hierarchy of Customer Value". Not unlike Maslow's hierarchy of needs, the Customer Perception Hierarchy divides the delivery of customer support into four categories:
Basic customer value is defined as dialing a toll-free number to contact a vendor for customer support and actually getting someone to answer the phone.
Expected customer value is defined as the support person on the end of the phone solving the problem you've phoned about.
Desired customer value is defined as feeling a higher level of satisfaction or quality of resolution from a completed problem. This might include more long term satisfaction, as in solving a bug problem for other sites as well as your own.
Unanticipated customer value is defined as receiving a service or answer to a problem which might cause the customer to put down the phone, clap his hands in glee, and walk off in some temporary state of unanticipated ecstasy or joy. Anyone remember the last time they felt this? The example that Albrecht uses is that of a chef in a large hotel chain bringing trays of cookies for people to sample while they stand in line waiting to check in to their hotel rooms.
We look at the customer support role, and our role as librarians in this light.
We would like to be correctly identified by name, site, institution code, platform, release level, and institutional profile without having to continually re-iterate this information each time we place a phone call. We want someone to know what our specials and customs are. We want to know with confidence that the person working on our system knows our system better than we do.
Response to customer problems can be very simple in nature: keeping use of telephone tag to a minimum; using reliably all forms of e-mail and message delivery; keeping communication accurate and timely; and not closing logs without some notification. We expect the customer support person can capably take the log down and understand the module well enough to offer a quick solution or suggestion, or perhaps even give an accurate estimate of response time, ascertain urgency, etc.
Time is money. Needs met in a timely and professional manner can include being given a correct reference to log numbers, follow-through on older logs, the ability to use LogX or Vantive to allow both customer support and the customer to track problems and solutions. This also includes receiving correct billing for invoices in timely fiscal year fashion, and having the invoices arrive at the correct addresses with the correct amounts and services itemized on them. We would be delighted if this also meant keeping track of customer specials and unique programs in a systematic manner, and annotating when changes or patches are applied to given code.
How much money does our vendor spend on sending tapes out over and over again before they read correctly? Happy to report with R.152, I think we're making progress in this area! How many reloads of data or reloads of software and exaggerated downtime occurs at our sites? How many times are simple steps left out which require a 2nd or 3rd touchback phone call with the message, "nope, still doesn't work"; or "well, I got a different message this time but it still doesn't work."
Some good questions were raised yesterday in the security issues session concerning proactive management. These included assistance with security audits, making patches available more quickly, even a simple checklist for new systems administrators to get beyond the initial install guidelines to the "what next" phase of proactive management of our systems.
Dynix/ALS is here to provide the vision of design, to see for us a vision based on market trends and customer needs analysis. Vision includes, but surely is not limited to such things as proactive operating system fixes/patches/upgrades; switching platforms; graphical GUI products; graphical links within MARC records; the great leap to a client/server environment; security issues and support. These are all examples of the proactive leadership we expect and have grown to depend on from Dynix/ALS.
*The message sent is not necessarily the message received.
You cannot NOT communicate. (Albrecht)
*The Quality Axiom: Doing things well usually costs less
than doing them poorly (Albrecht)
*The machine itself makes no demands and holds out no promises;
it is the human spirit that makes demands and keeps promises (Lewis Mumford)
*Quality: a measure of the extent to which a thing or experience
meets a need, solves a problem, or adds value for someone (Albrecht)
*Customer Feedback: on the whole, knowing is
better than not knowing. (Albrecht)
Continuing with another of Albrecht's examples, we now use his Customer Value Model as an evaluative tool for the performance of our customer support teams.
Price confidence is defined as the value of the service to the customer. Are we getting our money's worth? Was Dynix purchased because it was low bid or low quality? Chances are, for the majority of customers, the Dynix product was the best possible match for our local institutional needs. It is a product that in fact did enter our lives with a great deal of Price Confidence.
Michael Schuyler indicated yesterday in the security session about the dark side of "social engineering": for instance, revealing your passwords based on trust of the person who's asking you for it. I'dd like to think about "social engineering" in a more positive light, the "what can I do for you" attitude.
As we negotiate contracts and survive initial site installations, does the Dynix product gives flexibility to the average site or institution? How about choices in customization options, options for continued growth in size and/or added features, added modules? Does the product lend itself toward changing from single-site to multi-site consortia-based needs? How easy is it for us to change platforms without interface disruption for our patrons?
Does the Dynix product allow us as users to tailor the software and even the automation process to local variations in cataloging practices, circulation procedures, screen displays, notices, reports? etc.
Whether this "can do attitude" is still there, and how it is priced out after we become "customers of duration" I suspect is worthy of continued discussion, even as Dynix/ALS works towards making their product not only one of Price Confidence but one that is cost productive for them as well.
Leland and Bailey indicate "when we receive good service, we tell 9-12 people on average. When we receive poor service, we tell up to 20 people. An 82% chance exits that customers will repurchase from a company if their complaint is handled quickly and pleasantly. If the service is really poor, 91% of retail customers won't go back to a store". How does a retail customer differ from a reader or a librarian?
If there is a site present that does not have any specials or custom programming, please see me after this session. :-)
By far, the Dynix software product is one of the most flexible systems with good hooks and good track record for customization, ability to locally tailor custom reports, modify screen and data display to our local needs, and build a myriad of indexes.
While we often grouse about "x not working", or "y isn't quite right", we must remember and keep in perspective the flexibility and power that we do have with system parameters and recall reports that is unparalleled compared to other library automation systems. The power of individualizing our systems is both a blessing and curse depending on how the customer exercises his or her control of knowledge and responsibility.
Albrecht defines error-free mechanics as "doing all the basic things properly".
In the context here today, this would involve getting our names spelled correctly on contracts and on screens; getting screens set up properly in all accounts; receiving faxes sent with correct price quotes, getting invoices mailed to the correct mailing address in a timely fashion; and receiving documentation mailed out in advance of a release.
These are basic things: logging the logs without having to suggest a log number; answering the phone politely, not leaving customers on indefinite hold unless a snooze is mutually agreed to; taking appropriate messages with information given and notated; and providing enough callback information.
By that I mean identifying yourself by something other than "this is Brian from ALS". In the UK, where I was recently privileged to spend a portion of my sabbatical, I asked the Dynix customers if they had this problem, and they laughed and said, "yes, but we'd be happy to have some Brians. All of ours are Peters!"
Albrecht defines agency continuity as "being able to deal with one particular agent on a long-term basis, so that he or she understands the customer's needs and problems in depth."
It is a problem that plagues many vendors around the world and is not exclusively limited to Dynix. If we can't get the agency record correct with basic information, how can we begin to get our customer support representatives to understand the idiosyncrasies of the complex specials or custom programming at our sites, or even more amusing sometimes, the individual idiosyncrasies of our system administrators?
"Knowing the customer" must be the number one priority for the newest and the oldest customer support person, particularly if continuity cannot be assumed or assured.
As we regularly upgrade, all of us realize that we need as much information as possible about the upgrade process and new release features. As we upgrade and find bugs and problems, many of us continue to realize we need even more timely information than what monthly mailings provide. We are finding features which are not adequately covered in documentation, no matter how thoroughly we read the instructions.
This is information support. Albrecht defines information support as "taking the initiative to advise the customer of important matters he or she might not know about, voluntarily suggesting options or approaches that add value for the customer". This goes beyond basic documentation. This is talking about discussing the implications of x well in advance of doing a tape load; or the implications of having telnet access to your local site operations; or the implications of not archiving your serials, or the impact of format integration, etc. It may be appropriate for a workshop forum, or it may not.
Do customer support people always have the time to discuss these problems in advance of the customer implementing them? Often not. Do many CS people have the information we need? Absolutely.
If information support does not or cannot come from the vendor, we turn to each other. If we were to measure or quantify our information sources here today, I would suspect a very high percentage of the information support you and I engage in is coming from other customers. Dynix_L is also alive and well in phone calls and conferences such as this all over the world. Dynix_L has radically changed how we receive and give information support to one another.
Proactive Safeguarding of the Customer's Interests:
Changes in upcoming releases, new equipment needs, changing conditions in the marketplace all demand that the vendor pay attention to the long term interests of the customer. This, in some respects, is something that Dynix/ALS has scored fairly high on in the past. As mentioned previously, having at our disposal prompt patch availability, security audits, and even simple task checklists are signs that our vendor is looking out for our best interests.
Other safeguarding of our interests can include long-term equipment investments, security issues, market trends in many areas, making the move to Unix platforms; changing to GUI; format integration; even serials/acquisitions online interfaces
"Taking action quickly and skillfully to help the customer deal with problems that arise or to correct mistakes made by the agency, making amends for inconvenience imposed on the customer through the agency's malfunctions" is how Albrecht defines recovery.
This is another area where Dynix/ALS does come through successfully. Beta test sites often have programmers available on the spot when major corruptions or downtime occurred due to a bad piece of code. Dynix/ALS has made good efforts to rank log items in strict priority to determine data corruption and/or downed system crises, even in the cases of hackers as we learn new security issues on our systems.
Patron and circulation problems must have a high priority as well; after all, we are mucking with people's lives when fines disappear or calculate incorrectly.
In my experience Dynix/ALS excels at this aspect of the customer value model, and in cases where there may be some question of the quality of this service, we should all have significant contractual recourse to support us.
*It's supposed to do that!
-- anonymous helpline response (Lubar)
Similarly, it is fair to assume that customer support agents have expectations and assumptions about us as systems administrators and librarians.
What is the support person's job today? How often do we call individuals that are no longer on our team or officially assigned to a given module? How often do we call for ski or weather forecasts? Or to hear great Utah Public Radio features? Or, my favorite, how often do we call people in development or former trainers for "just another piece of insight, please"?
Customers need to provide correct information to customer support, which allows THEM to concentrate on the fix. Get to the point. Ever have someone call the library and say, "Hi, I need some help... I'm working on a project, but I don't know what I need. I mean, what I think I need is--well, my instructor said we should look for some sources... on, well, I haven't chosen a topic yet.."
A second way of providing accurate information in our logs is by looking up the problem in the manuals first. Consider it a wasted log if you call up to report "x doesn't do y"; and lo and behold the answer is, "on page 22 of the manual it says..."; How much better to approach the log with, "I've read on page 22 of the manual and it says x, except that x doesn't do what it says on page 22...".
This gives us the edge on the information and research, the control, if you will, of what shape the answer will now take--is it a problem with the documentation, or is it a problem not covered by the documentation?
Also, test. Test again. Test again based on what your staff have reported. Often many problems are internal misunderstandings. We do ourselves a favor when we clear these up before passing them on to customer support.
OR, if you are like me, and you occasionally resort to "NEVER MIND"; a la Gilda Radner, do your support person the courtesy of saying "forget it, but thank you very much" so they can get the log out of their queue. Tell them THANK YOU FOR LISTENING when the mere verbalization of the request on the phone to them makes you realize "oye, here's the answer!
Finally, explore and suggest options of possible problem origin. This comes quite naturally if you are a beta test site and are accustomed to analyzing problems while laying awake at night. Often we feel like we are losing our minds, and instead, we find historically in our error logs that something that needed patching a while back has lost its patch. Having the capability to search our log inquiries as well as old answers given to us in the past, does help us maintain our sanity, not to mention the sanity-span of the customer support person who has us on the phone yet again!
Test within a reasonable amount of time, and confirm or deny that the problem has in fact been resolved. This does not mean waiting until the book has been successfully checked in or reindexing the record and destroying the evidence. This does not mean crying "wolf!" every time we have a log and panicking if it is not fixed in 48 hours.
This DOES means conveying to our directors or other supervisors that we need a safe, nurturing, and quiet area for system administrators, free from fire alarms, book alarms, angry patrons, etc. where we can sit in peace and quiet and think through the problems at hand before placing a log that doesn't quite make sense.
Don't let things fester. Be proactive with conflict and/or contract resolution. The benefits of saying thank you are innumerable.
Distributing M&Ms is also apparently a cultural difference that does separate the UK from the US customers. I've tried to do my part in exporting that concept overseas. However, all of us in the US can "export" good cheer and gratitude, even in times of stress.
In some cases, what we automate, or what we ask to be automated, is something that long ago should have been abandoned. If you can't explain the process in 100 words or less on a typed sheet of paper, how can we ask someone else to "program this"? Just because we've done it this way for years doesn't mean Dynix/ALS has to drop everything and write a special for it.
Careful evaluation of our local site personnel forces library administrators and directors to continually seek out qualified individuals for the positions of information officer/system administrator. Are we giving to Dynix/ALS the best possible information and the best possible people to convey the challenge of information exchange/liaison activities?
On the other hand, we often must reach outside ourselves and understand conceptual design beyond our local worlds: this is true in print options, statistics, and cross-module capabilities, to name a few examples.
*Not everything that counts can be counted; and
not everything that can be counted counts -- Albert Einstein (Albrecht)
Lest customer support feel that applying management guidelines as an evaluative tool is not very original, let me now invoke a very unique communicative concept for librarians and system administrators. Ben Shneiderman, world-renowned systems design expert, uses in his book Designing the User Interface (1986, 1992) many rules of succinct communication. It is an excellent book for screen design and cognitive process analysis, but doggone it, it works for simple communication over the breakfast table as well. I've chosen several guidelines given for conveying error messages as an outline for how we as librarians can facilitate our communication of problems and solutions.
Know what module, what mnemonic, what Bib number, what patron number, what file, what field, what barcode number, what index. Know the steps. All of them. Saying "it doesn't work" is not a helpful response. Make up your mind about the desired result or option specified before you log it. If it really needs to be a "what I was wondering" log, or a "what if" scenario, think about what we said previously about Information Support.
TROUBLESHOOT. Try things before you call them in. Have screen prints and other evidence ready for faxing. Thoroughly research the problem. If you don't like it when they say, "nah, I think it's "x", learn to anticipate that. Test for x before you call them and log the problem.
Tape record your phone conversations sometime for your own benefit. Try calling your support team with your boss present at your desk and see if your tone of voice changes while you're on the phone to Customer Support. Ask the support person, "what information can I get for you, what else can I do to help pin this down?" Ask if you need to call later if they're working on a different site or in the middle of a nightmare with a system that is down.
Remember that we learn from other people by the following statistics: body language, 55%; tone of voice, 38%, words, 7%. When you take away the body language, tone of voice is 86%; words, 14% (Leland and Bailey).
Shneiderman defines this as terminology (or an interface) in "which the user controls the system by initiating more than responding". However, do let them get in a word edge-wise! Come up for air!
True confessions time. Here's something I'm very terrible about. I like to watch the minds of new customer support people who haven't any idea who you are or what your site is like. I like talking to them and watching them twist on a spittle and hang themselves occasionally.
Don't play 20 questions with these people! Give them a clue. Even my favorite "old guys" on customer support who have put up with me for years, they have bad days and no-brainers occasionally.
We must help our customer support representatives choose the best path of options available to customer and support person alike. Much as I would like to see every Dynix/ALS programmer with at least 10 years of library experience, I know that certain words like "hold" or "issue" or "copy" can mean a thousand different things and processes depending on what module you're in and where you're at in your understanding of how libraries function.
Try phone first, verbal. Try phone again. Try a fax. Try a fax with lots of arrows and circles and diagrams on an example. Find a team leader. Call another customer. One of the reasons Marge Freeman was honored as Mentor of the Year at the banquet last night is because she listens; she offers answers, she has workarounds, she thinks about problems from different angles than the rest of us often do. Listen to how other customers try to describe the problem (or rephrase it) back to you.
Find your boss. Do you ever play good cop/bad cop with your boss? I recommend this for new installation sites. It is a strategy that occasionally works with customer support if it is not over-used. Remember how many ways we try to train student workers in the library? Visual, verbal, hands-on? Sometimes we encounter customer support people with different learning styles than our own. Think in terms of those various learning styles, even listening styles.
Deal with the complexity of the problem with appropriate means of communication conveyance. Get out crayons if necessary and draw colored boxes and doodles if that is what it takes. Withhold invoices as a very last resort. P.S. Find your bad cop to do that!
Listen to how you phrase the questions you ask. Remember how much most of us hated essay questions in school? Or true/false questions? How are we asking the question to customer support representatives?
This goes a bit back to user-centered phrasing, but is also in how we annotate our multiple levels of messages. Put the bib number on the example. Sign the fax. Make sure the fax is readable. Change the ribbon in your printers occasionally, preferably before you fax 24 pages of unreadable error messages.
Use a como file for "evidence" or create a procomm log that is indisputable if you have message that whizzes past too fast. If support has to call you back because you've sent them gibberish, you've achieved nothing, no matter how long the "agent" has been at the desk.
Think also in terms of consistency, such as who is discussing what with whom. Don't count on team leaders to convey nuances to the programmers (like release levels, actual screens or mnemonics used). If you've had to route complaints or assistance requests up a level, think bigger picture. Save time. Make people happy.
Conversely, think how we waste time when we re-explain things to different customer support people who are not familiar with our problems--we end up explaining things twice. This is also true in libraries. Unless it's a show stopper, customer support needs to get back to the system administrator, not the backup SA, not the circ person that answers the phone and doesn't have a clue what the log was about.
Use all tools and know when which ones work better (email, voice mail, fax) for what situations, and make certain they get to the correct people.
A phone message from customer support of "it's fixed" doesn't often cut it when you have about 40 logs outstanding, nor does it work when the person who took the message has left for the day or isn't familiar with the log to begin with
We must at some point ask our customer support people, what CAN we do to make your jobs easier? I would like to see the customer support people surveyed by Ameritech, just as Ameritech surveys us, and really learn and study the top 10 things that librarians do that annoys the socks off of customer support people.... or the top 20.... or 30....
*My software doesn't have bugs, it has random features (Lubar),
or as Randy
Boeker would say at Dynix/ALS, it is "functionally challenged".
*Even error has its uses. (Alvin Toffler)
*Cherish your bugs. Study them. (Lubar)
*Definition of an upgrade: Take old bugs out,
put new ones in. (Lubar)
*An omlette, promised in two minutes, may appear to be progressing nicely.
But when it has not set in two minutes, the customer has
two choices -- wait or eat it raw. Software customers have had the same choice
(Frederick Brooks, Jr.)
The human has not caused the error message, neither the programmer nor the librarian. I am here to tell you that Randy Boeker did NOT stay up all night programming bugs IN the software just to see if Susan Johns could find them. Although on some days after talking with me endlessly on the phone, I'm sure he wished he had!
Understand when Why is best asked; it is often not the best question unless you're actively beta testing, especially if you want it fixed quickly. Can you? or Could you please? is often a better way to address the strengths and values of a person entrusted with troubleshooting and supporting your system.
Many Dynix customers who have been customers for more than a year (this makes us "seasoned" customers) lament the fact that we often feel like we are the trainers of our customer support teams, particularly the newer team members.
Many find this to be burdensome, but so long as my customer support teams are willing to train and advise me, this is a suitable arrangement. I would hate to have a customer support person tell me, I've fixed it but you don't need to know what I did.
Conversely, we as librarians should never say "nyahh, nyahh I found a bug and you don't know where it is". It achieves nothing :-
Remember also that we want our staff that come after us to be trained by customer support just as we were initially. I had a scary thought yesterday during the security session. If the roof caved in on all the system administrators here today, can you imagine what all the customer support reps would have to do? Train another 600 new system administrators back home! Imagine what the stock of Tylenol, M&M Mars, and AT&T would do if that happened! This goes back to that good reputation of Dynix/ALS of "recovery when things go wrong"!
This is a strength that many sites in the US can offer and provide in either a formal or in an ad hoc manner. We, in fact, put the system to the test each time we do a transaction on the system. Testing occurs each and every time we press the <RETURN> or <ENTER> key and get a desired result.
Or, with whining comes responsibility. If I complain, even if I'm not formally in "test" mode, I have a responsibility to be creative, suggest, and provide alternatives rather than just raw criticism.
The bottom line is the patron. Accurate and timely information. Competency leads to knowledge; wisdom leads to responsibility. If the bottom line is the patron, we must take the responsibility of hiring and nurturing top-of-the-line system administrators AND customer support representatives.
*Three helping one another will do as much
as six working singly -- Spanish Proverb
*What is really important in education is ...
that the mind is matured, that energy is aroused. -- Kierkegaard (Shneiderman)
*An individual without information cannot take responsibility;
an individual who is given information cannot help but take responsibility
-- Jan Carlzon (Albrecht)
Tom Quarton, CEO of Ameritech Library Services, has often talked about having the best possible job in the Dynix/ALS organization: having great support and resources available from the parent organization, Ameritech, and having within his charge superior staff and customer support individuals capable of solving the toughest problems.
I feel as customers of Dynix/ALS we, too, have the best possible jobs in the world: having an automation system that provides the best possible electronic resources and management of our library automation systems, and having around us patrons with an unquenchable thirst for information, access, and knowledge.
Tom often talks about the "competency" that we seek as individuals, this within the structure of providing an organization that can bring out the strengths of its individual employees. I would offer to you that competency does, in fact, lead to knowledge; and with knowledge, wisdom, and with wisdom, the responsibility to share that competency and knowledge and wisdom with our patrons, our peers, and our sister institutions. This is where we as librarians fit into the picture as a whole.
As libraries join together to share bibliographic and other resources in regional and consortia-based environments, we also have a great deal of technological resource sharing.
Standards are just one facet of resource sharing. We now have a product that supports Z39.50 and continues to offer us exciting implications and products based on the Z39.50 standard. SISAC/BISAC standards for our serials are another example of sharing resources, particularly among consortia and in a way that brings our resources down to the issue level. Other standards through BSI in the UK continue to provide commonality in data and resource exchange. And of course, may favorites, Z39.69 and Z39.70 for patron and fines standards, will help facilitate even further development of common bases of information, particularly with emphasis on future ILL and consortia cooperation.
CODI-ED, Vantive, and efforts of global committees, planning, and discussions in electronic formats allow shared databases of stored knowledge and expertise to be available around the world.
The Custom Programming/Specials Task Force, the Security Task Force, and many other such efforts in the future will benefit all sites, and, in turn, benefit the global product as a whole.
These, coupled with WWW and Internet resources, among them e-mail and listserv capabilities, enhance our understanding, power, and control over our local technological and bibliographic resource decisions.
User group meetings such as this, both on a regional and a global basis, provide myriad of solutions and problem solving techniques from a wide variety of creative and resourceful individuals and groups. Regional and global contact in our context as users of Dynix includes exciting liaisons with people far, far, away from our local sites.
Dynix_L, where so many of us have met from the various sides of the "pond", allows us to cut across paper obstacles and time zones, phone tag and general frustration. Dynix_L is an excellent community which makes use of the strength of its users' knowledge and information to reach across the globe, often providing answers, camaraderie, and even wisdom within minutes.
Karl Albrecht. The Only Thing That Matters : Bringing the Power of the Customer into the Center of Your Business. HarperBusiness, 1992. ISBN 088730639.
Randy Boeker. Personal correspondence. 1995.
Brian R. Gaines and Mildred L. G. Shaw. The Art of Computer Conversation. Prentice Hall International, 1984. ISBN 0130473324.
John Gall. Systemantics : The Underground Text of Systems Lore; How Systems Really Work and Especially How They Fail. General Systemantics Press, 1986.
Karen Leland and Keith Bailey, Customer Service for Dummies, IDG Books Worldwide, 1995 ISBN 1568843917
David Lubar. It's Not a Bug, It's a Feature! : Computer Wit and Wisdom, Addison-Wesley Publishing Company, Inc, 1995. ISBN 0201483041.
Ben Shneiderman. Designing the User Interface : Strategies for Effective Human-Computer Interaction, 2nd Edition, 1992. Addison-Wesley Publishing Company, Inc. ISBN 0201572869
My thanks to the staff of Liverpool John Moores University (UK) and to the International Dynix Users Group (DUG) for their support during my recent sabbatical. Thanks also to the many staff of Ameritech, particularly the development programmers, who also provided a home away from home in Continuing Engineering during the second half of my sabbatical.
Send comments to: suzyq@pittstate.edu
Susan M. Johns-Smith
Axe Library
Pittsburg State University
1605 South Joplin Street
Pittsburg, KS 66762
Phone: 620-235-4115
This page last updated 28 October 2002 03:58:27 PM