October 29, 2009
Release notes (RN) and known issues:
Enhancements which come from forum suggestions should be marked consistently—could improve accountability and customer faith in process
Update: we have updated our development process to capture “customer enhancement” items as requirements are entered. We’ve used fields in our development logging tool, Jira, to do this.
“ Release Notes in Progress”: should also include forum enhancement suggestions
Update: Based on the updates we’ve noted above, you will start seeing the forum symbols prior to the final release.
Flag the metagroups that produced the enhancement suggestion, e.g., consortia, sysadmin, international, etc. This will More overlap among the groups, easier to interpret the results of the enhancement forum if the reference is there.
Apply more granularity to explanation of enhancement: where does this apply—single libraries, groups, gateway-specific?
Update: we are reviewing various methods of handling this; we agree that the larger release notes do not make this clear.
Integrated Apply indexing to RN documentation. We need to know where to look for what—sys admin notes, release notes, versions of RNs for same build?
Master index across client care info. What about tagging??? Depends on granularity…also think about formats other than pdf that are more web driven, dynamically updated. Any formats must support printing cut and paste etc.
Avoid pdf format and use document mgmt system for sake of currency
Known issues—list actual known issues—clarify what is fixed and what is not fixed.
Interest in group—report known issues that have not been corrected—ideally in a resolution process. Very frustrating to not hear about known issue until days after problem logged. Also more version specific information, release version of problem, projected fix dates, etc. Also provide for client care (and ? whether client care should maintain this list)
Consider whether more items escalated to development should just be collected into a known issue document.
Also sense of how many sites reported the issue.
Paul – search for the issue—how can we put these into a searchable knowledge base. (both)
Sites noted that customer wiki not that well indexed; note customer knowledge base provides some inconsistent results. Too many places for information. Known issues—ideally searched from x date.
Push definitely of interest.
Guy notes that he distributes problem info. to his members along with corrections.
Update: we are making further changes to the corporate and client care portal in 2010 and will definitely be exploring expanding indexing and search capabilities.
Keep known issues list current.
Other issues (Client Care):
Server configs as set up by SD—inconsistencies—example SendMail
. SAILS notes that even with multiple servers on same os we have set up their servers very differently. Our staff should review other servers’ setups prior to setting up new ones. Also try to have similar settings among customers. Also upgrading versions…not a whole lot of faith in configuration support, etc. Also explain to site why new server might be set up differently than existing servers.
Send mail: problem for almost a year—send mail for user announcements –e.g., didn’t set up to use send mail but mail instead. [automation task force]
CCS: felt that they had to fight to get it staged it the way they wanted it to be set up. Linda drove the check old machine, make sure new machine is set up properly. So we need to be more proactive in reviewing other machines and explaining why sometimes we would recommend something different.
Also what does their maint. include—e.g., are we supporting their OS—e.g., who does the OS upgrade.
Example Test server better configured than production server; production server not even configured properly. Client care staff told Gair that backup we’d set up after golive was no longer supported—so how are we maintaining these backups.
What is our policy about no longer selling EOL products—e.g., from manufacturer.
Eileen has received quotes for Sun products that have been marked EOL on the Sun page—what’s the deal with that.
Support for OS updates, patches…policy for OS support. DuPage: production server for e-Library—now the security patches are really important because e-library is inside the firewall. Need a better flow on security patches vs. regular patches for the OS. And how will we communicate?
Expertise is expected in setting up servers—hardware support weak
Update: We are making several changes related to this:
- We are automating our installation process and further automating our upgrade process so that config mistakes or oversights related to the installation of Symphony itself will be much more difficult to make
- We have staff members expanding certification on our supported hardware platforms
- In cases in which we may not be able to guarantee consistent expertise (e.g.., configuration of non-ILS products such as mail servers, we are reducing services intentionally in order to focus on the main ILS.
- Additional review is underway.
Why does Salesforce.com drive intelligibility of quotes?
Units do not equate to final price—e.g., 3 units @ $10 may not = $30. Also note that the hardware quotes are particularly problematic since each configuration is unique. Also the accounting stuff that can influence. Kate notes that we now have public view vs. internal view.
Update: we have made and continue to make changes in the quote process to simplify quotes from the customer perspective and believe all customers will note significant improvements in quote legibility. Also note that we have modified our Accounting structure to be regional—similar to Sales—so that Accounting staff will become more familiar with customers and can work more closely with both our customers and Sales teams to improve service.
Client care: “Who knows EDI?”
Atlantic County: first how Client Care discussed—I don’t know edi, don’t want to, all edi staff are gone. B&T ended up organizing the calls for the correction. Also: how we discuss “need to find expert help” with customers. Also logs falling between the cracks and apparently no internal escalation on our end. See a difference in sides of house. When work with someone who used to work for Dynix—get more info on solution. If speak to “sirsi” the problem may be corrected but no education takes place. Also need to look at how we provide initial training. Gair did note that EDI is working well now.
Update: We have focused on EDI training for client care to improve expertise in this area. We also made many updates to EDI itself in Symphony 3.3 which we believe will make it much easier to use and to support.
Let us know details of how an issue was fixed. How can we prevent a recurrence? Updates needed as work progresses. Summary of fix would give us a better understanding.
Treat client care interactions as a training opportunity which may prevent a call in the future. What really caused the problem and how did the fix occur? And get those items into knowledge base. Training of client care staff—basic understanding of language that we use—e.g. basic MARC, consortial concepts, common words (charge, hold, request, etc in their different contexts). Richard concerned about metrics under which they are being evaluated—e.g., timeframes for close—can we be sure that client care doesn’t get penalized for providing a little more info. [what about movement into knowledge base]. As Paul notes—what information did we provide out of development or Systems?—make sure that we are providing internal staff with the info. they need.
RESOLUTION passed by group unanimously on October 29, 2009:
Bring back a consortia client care team.
Color not important, and not to be confused with GREEN although sustainability would be good.
Or consortia certified staff on the various teams. But this group notes that we may wish to think of consortia as a “module” in the same way circ, etc. as a module. Also with the one team there is an understanding of the idiosyncrasies of given customers. Also the communication between individuals.
Update: Client Care is reviewing support structures for improvements and understands the strong preference for a consortia focused team and knowledge base.
MONEY: lengthy discussion regarding pricing elasticity
We need consistency and reasonable pricing
Having to bargain to get good pricing is not the ideal way to interact with customers. Also note that economic reality doesn’t seem to have been considered. Eileen/Cory noted 7.5 and 8 % increases. ? regarding economic indicator we use to make these decisions. Dickering is not desirable. Eileen can’t plan from year to year in terms—various group attendees indicate that they haven’t been approached yet. The concern that the pricing is situational.
Unbundle content! We know we’re paying more going through SD for content and other 3rd party products.
Cost to add library or branch keeps ratcheting up. What are the criteria? This gives the impression that you don’t want the consortia to grow and thrive, devaluing us as customers. If SD pricing to add library is an obstacle to our growth, it forces us to consider other options.
Cost projections must be predictable. TCO quotes can be helpful but we need consistency and reasonable pricing
Update: we are making numerous updates in pricing and cost effective maintenance plans and do expect further beneficial updates to how we approach new member fees.
Toggle between owning and charging is too broad
Text messaging?
Update: Text messaging is on the 2010-11 roadmap for Symphony.
Mobile apps?
Update: Bookmyne 1.x is now available and additional versions and functions will be released in 2010.