BUILDING A MEANINGFUL RELATIONSHIP WITH YOUR VENDOR
by Stephanie Taylor
Do you speak techie? For non-technical people, liaising with a technical company can feel like working in a foreign land without a phrase book. It's not just struggling to understand the buzz words and the jargon, though. The real trick is to understand what your role is in the relationship. Armed with this knowledge, you can help them to give you a good customer experience.
There are three main areas of interaction between software companies and customers- buying a new system, installing a new system, and ongoing system maintenance. Learning the key points in each area will help you to build a good relationship. No technical knowledge is required - the most important thing to realise is that your job is all about being clear about what you want to do and within what timescale. How the system will work is the concern of your technical partner - the vendor.
To start, if you're buying a new system you need to focus on what you want that system to do. Do your homework well and find out how the system will be used, who will be using it, what functionality you need, what you'd like and what you can live without.
Have a standard checklist of your requirements and take this along to demos to make sure you ask the right questions. Focus on what the system does, not how it is doing it. Is it covering your checklist?
Ask the vendors about support and training options. Check if they have a user group for the products. And ask to see the system working in a live environment, where you can meet their existing customers. Most companies will have customers who will act as demo sites for them and should be happy to arrange a visit. Never make your choice based on a demo from the sales person alone. Remember in this phase that you are looking for an ongoing relationship with a company, not a one-off purchase. Further down the line you'll want upgrades and new versions of the system. You'll need support from them and training. Make sure you are happy with the whole package before you make your final decision. And make sure again that the system does what you need it to do!
Now you're moving on to see your requirements translated into your system. Stick to your original requirements and highlight with the vendor what needs to be done to create the system you ordered. Have you ordered any additional features that will be bespoke to you? Does your system need branding, configuring, linking into existing systems? Plot out everything that needs to be done by both you and the vendor to get the system up and running. At this stage, obsess on detail. The vendor will be only too happy to be certain of what you want. Most bad experiences are due to a lack of understanding on both sides about what is needed. Better to check now than regret something later, when it will be costly and time-consuming to fix.
Identify the key points in the plan for installation. These are the things that would be real show-stoppers for you so clearly identify these with the vendor. Tie these key points into your payment plan so that you only pay after you have received, fully tested, and approved the system. This can be broken down into several stages over time if that works better for your implementation. Make sure that you have a well-planned testing and approval phase before you go live with anything new. Build time into your implementation schedule to allow the vendor to fix any problems. If you're not happy with the way something is working, being specific about the problem helps your vendor to help you.
Once your system is up and running, you still have an ongoing relationship with your vendor. Initially, they may undertake training for you, and you will probably have a support service with them. Make sure you are clear about the terms and conditions of your ongoing relationship with them, what is included in the original package and what kind of support or training would incur additional charges. Most problems in this area are down to the two parties not clarifying the situation so that the customer finds they are facing un-planned charges.
If you're not sure, ask until you understand. That way you can budget correctly and take decisions calmly ahead of needing the services.
Updates and new releases can be tricky if you're not clear about the difference. Updates are usually installed to fix problems or bugs and will be free. They are small improvements, not major changes. A new release is a much bigger undertaking and will include new functionality.
You would expect to be charged for a new release as the vendor has spent significant time and resources on developing the enhancements. You are usually not obliged to take the new version, so if the new functionality is not of interest you can decline. However, you do need to be clear about the ongoing support for your current version as eventually this will cease. This time is usually generous (years rather than months or weeks), but if you clarify this, you won't have any surprises further down the line.
Above all, don't be afraid to ask questions. Clarify anything you are not sure of, and really hammer out what you want. Vendors are not always great at communication, but a good vendor will appreciate this attitude. The more they know about your needs, the better chance you have of getting what you want.
Stephanie Taylor has extensive experience in the United Kingdom's higher education library and information sector, developing global document delivery and information management solutions. As founder of Critical Eye Communications Stephanie is now a consultant and trainer, offering courses in the effective use of communication technologies in the project environment, and preparing Library and Information workers for the changing nature of their roles. Her previous article, on writing a functional specification, is available at <http://marylaine.com/exlibris/xlib293.html>. Stephanie can be contacted at: [email protected]
* * * * *
COOL QUOTE:
Libraries struggle because they manage a resource which is fragmented and 'off-web'. It is fragmented by user interface, by title, by subject division, by vocabulary. It is a resource very much organised by publisher interest, rather than by user need, and the user may struggle to know which databases are of potential value. By off-web, I mean that a resource hides its content behind its user interface and is not available to open web approaches. Increasingly, to be on-web is to be available in Google or other open web approaches.
These factors mean that library resources exercise a weak gravitational pull. They impose high transaction costs on a potential user. They also make it difficult to build services out on top of an integrated resource, to make it more interesting to users than a collection of databases.
"Metasearch, Google and the Rest." Lorcan Dempsey's weblog, March 20, 2005, http://orweblog.oclc.org/archives/000615.html
* * *
You are welcome to copy and forward any of my own articles (but not those by my guest writers) for noncommercial purposes as long as you credit ExLibris and cite the permanent URL for the article. Please do NOT copy and post my articles to your own web sites, however. Instead, please copy a brief excerpt and link to the URL for the remainder of the article.
Ex Libris: an E-Zine for Librarians and Other Information Junkies.
http://marylaine.com/exlibris/
Copyright, Marylaine Block, 1999-2006.
[Publishers may license the content for a reasonable fee.]
