To something more like:
We don't deny that LibraryH3lp has lots of features, but it is not as complicated as it may appear at first glance. Yes, we have more buttons, dials, levers, and switches, but they each exist for a very specific purpose, and together they work to provide your patrons with the simplicity of "Push for Cheese". Here is a walkthrough of the core concepts.
Fundamentally, of course, is the widget - that box you stick in a web page that the user can type in to chat with you in real-time. In single-operator systems like Meebo, a widget corresponds exactly to one user: you have one login, and this is used to sign in and answer chats. If you share the login among multiple people, things get a little weird because all of the guest-side messages go out to all of the people using that single account. There's no need to further review the other shortcomings of this setup, as you've experienced them, but it is easy to understand and setup.
Building on that, multi-operator systems like LibraryH3lp break the one-to-one limitation of single-account systems like Meebo. You still have a widget, but you can have multiple user operators, all of whom can answer chats without tripping over each other. This is a popular arrangement because it is a lot more powerful to use and only slightly more challenging to deploy. The weaknesses of this system center primarily on organization. But LibraryH3lp has organizational knobs too.
From the patron's external point-of-view, you're a library, but of course internally you have branches and departments, individuals, and specialties. When the patron contacts the "library" (via chat, phone, or email), job one is to direct him or her the individual or department best suited to provide help.
To facilitate this, LibraryH3lp breaks the concept of a widget into two pieces: a widget and a queue. The widget is still a box on your web page, and the queue specifies the target or destination of the chat. Another way to think of a queue is as a tag or a label. Some librarians are reference librarians, some are science specialists... some are even both. Queues are a way to organize your users. So you can have a widget in your page that targets your circulation or reference queue, but when an ILL question comes in you can transfer that chat to your ILL queue (tag/label) so the patron receives the most appropriate help. Because widgets and queues are separate, this works whether the chat comes in from the web, IM, or SMS.
Of course, once you've organized your users into queues, you shouldn't need to setup a "chat dispatch" operator who answers and routes chats. That's silly... let the computer do it, that's what it's for. And that is what we call a service. It's a way to describe how to route the chat to the most appropriate operator. You can say, in effect, if any of my science librarians are online right now, send the chat to them. Otherwise send the chat to the reference desk so they can help as best they can. If none of my librarians are available for chat, send the patron to my after hours backup service or to my email form.
With all the knobs comes flexibility. Instead of just a user and a widget, we give you any number of users to answer chats, queues to organize your users, widgets to display in your web pages, and services to ensure that your patrons get the best help possible.
Most importantly, you don't need to worry about any of that if you don't want to. When you signup for LibraryH3lp, we set you up with one service, one widget, one queue, and one user, in a way that is functionally nearly identical to a Meebo setup. And we send you a code snippet in your welcome letter to do all of this. Once you've put that code into your web pages, you can learn what the knobs do later and never have to make any code changes. That's as close to "Push for Cheese" as any nuclear power plant can get.
No comments:
Post a Comment