Training involves preparing training materials for new courses as well as teaching. Right now we are working on training materials for LISTSERV Maestro Version 6 for users and administrators. We probably do six trainings per year, mostly on LISTSERV. Remote training is done by phone and web (using GoToMeeting), and consulting involves a lot of conference calls with many people coming together for scheduled meetings.

Consulting is working closely with certain customers on major projects. At the moment I'm working with a university on a major DR (Disaster Recovery) project. They have ten LISTSERV instances and one Maestro instance, and it needs to fail-over to the backup instances in under one hour. Consulting is also responsible for remote installation of our products as well as remote migrations and upgrades. With the end-of-life of Windows 2003 later this year, we are getting a lot of requests for migrations and upgrades. Another customer, a government agency, wants me to travel to do a migration and upgrade on-site. Mostly we do everything by remote access these days, but sometimes on-site work is necessary for security or other reasons.

Consulting also functions as escalated or third-tier support to our regular product support staff. Particularly vexing or time-sensitive problems come to us. Sometimes this is informal behind-the-scenes questions, but other times we work directly with the customer on whatever their issues may be. We also do testing to verify if a bug exists and escalate that to development. And then we test again after development offers a fix to verify that the matter has been corrected. Further, we are involved in testing new features or builds even before they are made available publicly.

Pre-sales involves working directly with our sales staff and prospective customers in the process of a purchasing decision. This involves answering technical questions of many kinds. It can also mean setting up test LISTSERV lists and demo Maestro accounts on our hosting servers for prospects. For those prospects who prefer to install and test our products on their own, we answer a lot of "how do I make LISTSERV or Maestro do this or not do that" questions.

We do a lot of work with customers and prospects via GoToMeeting, where I make them the presenter so I can see what they are doing on their machine and guide them to the right configuration settings, or instruct them on how to accomplish certain tasks. It's a great time-saver and I think customers feel they are getting more personal attention.

In terms of access to support, a lot of people like to pick up the phone and call us. But we ask that you write in by email, ask your question or explain your situation. This allows us to prioritize our time better. We can ask a question back, or ask you to send us a log file or a configuration file. From that we can usually provide an explanation or tell how to correct the situation.

Although people are more used to telephoning for support, our system of doing it (mostly) by email is actually very fast and efficient, whether it's for support, training or consulting.

It's not that we don't want to use the phone, but we prefer email so the phone call doesn't come in when we are in the middle of something else, usually time-consuming. If we get an email and schedule the call, then both we and the customer or prospect will be devoting full attention to the matters at hand.

In pre-sales, we get a lot of self-installation questions. People don't understand that LISTSERV is a network application. It needs to exist in a network, have a presence in DNS, and their mail system needs to know where LISTSERV is to send mail to it. We also get a lot of security-related questions, mainly about access and hacking possibilities. We also get LAK questions. For example, if an existing LISTSERV customer wants to try out Maestro, that is a pre-sales prospect. They need to learn how to apply their Maestro test LAK without accidentally stopping LISTSERV.

Support gets a lot of LAK questions as well. The 2014b version of LISTSERV actually requires two LAKs. A product LAK and a current (unexpired) maintenance LAK or it won't run. A lot of customers forget or never knew this.

One question that comes up frequently in pre-sales, support and training is how to control recipients' use of "reply-all" to an email that comes from a LISTSERV list. They ask, "How can I prevent recipients from using reply-all?" The answer of course is that you can't. You can't reach out to someone through their computer or other device and control what keys they press or objects they click or tap on. Instead, we can reframe the question as, "What can you do when that reply-all email comes back to LISTSERV?" Then you can go into the various control options at that point. This comes up probably twice a week.

Another frequent (almost daily) question is, "A message was sent out from a list, but some subscribers didn't get it. How can I tell why not?"

This comes back to explaining that LISTSERV is a network application. It processes mail but then sends it on to another outgoing mail server. That mail server in turn sends onward to another mail server, and another. Something could happen at any one of those transfer points that stops the mail, quarantines it as suspicious, or simply drops it in the waste basket. Usually, the person asking the question has access only to the first mail hop from LISTSERV to the outbound mailer.

Yet another one is "How can I tell which lists have been inactive for a long time?" or a variation of "How can I get a report on how much traffic is going to my lists on a daily/weekly/monthly basis?"

The answer involves turning on various changelog files that may be turned off by default. I think changelogs should be on by default because many of our users never know about these features to turn them on.

For LISTSERV, robustness – it never breaks and is always reliable. I've used LISTSERV since 1992, before the web interface was even added. In all that time it has always worked. You can make human mistakes like sending a corrupt email, but LISTSERV just handles it and sends you back a polite and understandable error message. I noted earlier that some customers and prospects have security concerns like how easy or hard is LISTSERV to crack. I have been trying for a long time, and I still haven't seen a successful hack except when someone chooses a weak or obvious personal password. And that's a human fault. Other times people will say that an inappropriate message was accidentally sent to a moderated list. They claim that the message somehow bypassed the usual confirmation process. Investigation has shown that this is always traced back to a human error, that is, the message was "approved" by a human, even if they didn't understand what they were doing.

For LISTSERV Maestro, I would say click-and-fill HTML message templates. I use LISTSERV Maestro for mailings for a local choir. It is very easy to drop in message content and make very attractive monthly emails. I have another venture where I'm doing two emails a week to promote online webinars. The content keeps changing but with a template it is so easy to drop in and send out. I started with one of our stock templates and added a few things like a logo at the top and the address at the bottom. When using a hosted recipient list for the addresses, the unsubscribe is handled automatically.

We have several large universities that were formerly licensing customers that have migrated to our ListPlex hosting service. Whenever there is a big move like this, there are always concerns about downtime, data and mail getting lost, and so on. So a lot of pre-planning goes on. I can say we have always managed to make the downtime significantly less than expected and largely trouble-free. In most cases, users were informed of the move but never noticed any "bumps" in their service.

Part of that is our combined experience at doing this. To migrate once is trepidatious. When you've done it 15 times, it becomes old-hat. Not that we are sloppy or careless, we just have it down to a long checklist, similar to what pilots do before flying.

I guess the first big move was when St. Johns University closed down its LISTSERV server. There were many public-service lists there including about 350 lists for ICORS. L-Soft decided to move them to our hosting as a donation. This is now the ICORS ListPlex node. We moved all the lists, archives and so on in two stages but in a total downtime of about 2.5 hours. And that was a cross-platform move, from OpenVMS to Windows.

There's also our long relationship with City University of New York (CUNY). They were one of the very first LISTSERV sites in the United States back in 1986. I have assisted them throughout, with two upgrades and migrations, and am now working on another big project for them.

Thanks for asking these questions. It allowed me to take a step back from the daily grind and to see the broad variety of work we do here and the contribution we make to help people use our products to communicate better.