Our pre-sales support tends to focus on integrating LISTSERV and LISTSERV Maestro with a prospective customer's existing infrastructure. For example, they may have an existing subscriber database and content management system and engage us to help them plan the email piece of things. A lot of our pre-sales support time is spent working to understand the client's existing messaging system and figuring out what we can add to that.

Our consulting time is divided between two main types of projects: new installations and migrations. New installations are usually pretty straightforward. We help the customer figure out where LISTSERV or LISTSERV Maestro fits in their network, and we install it and advise the customer as to any necessary changes in their existing messaging environment. Migrations are more varied and may range from something as simple as moving an existing LISTSERV installation to a new server, to something as complex as exporting list data from a legacy application and converting it to LISTSERV or LISTSERV Maestro. We've done things as large as taking a university Mailman site with thousands of lists and automatically converting them to LISTSERV lists that pull list memberships from a DBMS with course registration information.

Training classes are fairly evenly split between teaching new customers how to use LISTSERV or LISTSERV Maestro and training new staff on existing systems when there has been staff turnover at an organization. Often it's the case that there's been one LISTSERV administrator at an organization for many years, and when they retire, nobody else knows how to run the system. We'll come in and do training for the staff to help them figure out what they've got and how to work it.

I came to L-Soft in 1998 with only a dim idea of what LISTSERV was. Prior to that, I had been doing phone support for an Internet service provider, troubleshooting problems with dial-up modems and the like. Supporting LISTSERV was my first time doing any sort of enterprise-level tech support.

During the last 17 years, it's amazing what has changed and what hasn't. The basics of how email moves around the Internet haven't changed much at all – name servers, mail servers and the protocols that make them work are pretty much the same as they were 20 years ago, and I think that's testament to the robustness of those protocols and the foresight of the people who designed them.

That said, the dot-com boom and bust taught us a lot about what was and wasn't sustainable as a business built on those protocols. There were lots of "huge" companies with millions of dollars in investment capital that just didn't have an actual product that filled a niche. Those companies don't exist anymore. L-Soft does because the product came first.

For our pre-sales clients, the fastest way to get a response is via email to presales@lsoft.com. Phone calls or emails to personal addresses don't work well because those of us who do pre-sales support also teach training classes and commit to on-site consulting engagements, so we may be unavailable for days at a time. The pre-sales address will reach whoever is in the office and handling support tickets that day. The technician can then respond with a phone call or email depending on what's most expedient for the particular question.

These days, "Disaster Recovery" (or "Business Continuity", or whatever the marketing folks are calling it this week) is a hot topic in the computing press, so it's pretty common for us to help enterprise-level customers with disaster recovery scenarios for LISTSERV and LISTSERV Maestro. It's an apt example of how everything old becomes new again. Back in the 1990s, we were doing disaster recovery on VMS clusters, only we called it something different.

Now, 20 years later, disaster recovery has become the hot new thing that everybody has to have. And while the technology we use to accomplish that has changed, the basic principles haven't. You still have to replicate the data; you still have to determine when a failure has occurred; you still have to transition to the failover state; and, you still have to have a plan to transition back. Once you understand that process, the particular technological method that you use to implement it is just details.

I think some of the most powerful and interesting features of LISTSERV and LISTSERV Maestro are also some of the least used. Specifically, I'm talking about those features that connect and integrate email messaging with other systems. I think people tend to think of LISTSERV and LISTSERV Maestro as stand-alone applications when they're really best used in a heavily integrated environment.

For example, I wrote a Tech Tip last month about how to query a web services API to populate LISTSERV list memberships. The idea is that you can have a member database that sits anywhere on the Internet, and as long as you can send a web query to fetch the membership from that database, you can use the results of that query as a LISTSERV list membership by way of a bit of fairly trivial back-end scripting.

Likewise, while you can use LISTSERV Maestro as a system to upload an address list, compose a message and send that message out, you can do so much more when you integrate things. You can set up an auto-repeat job that runs every night and queries a database for current subscriber data, queries another database for current message content, sends out a mailing to your subscribers containing their personalized local news headlines and weather report, tracks their responses (including social media shares and website follow-up), and exports the results via XML into a third-party analytics program to be sitting on your desk by the time you log in to your computer Monday morning. Setting up those sorts of things take some planning and an understanding of the systems that you're working with, but the end result is better quality with less effort.

I'm a system administrator (and UNIX guy) at heart, so I try never to do something manually twice if I can script it once. The most satisfying parts of my job are also the most complicated, and if I can wrap a complicated operation into an error-free script that can be executed simply, I've done my job well.

A few years ago, I worked on a migration project for a large state university. They were new LISTSERV customers and had thousands of university Mailman lists that needed to be brought into LISTSERV. I spent days developing and testing the conversion scripts for that one. I wrote a bunch of Perl that parsed the configurations of all of the existing Mailman lists, then created corresponding LISTSERV lists, then loaded the LISTSERV lists with the subscribers, then located the list archives of the Mailman lists and converted them to LISTSERV format. It was about a week's worth of coding and testing, but the end result was that we were able to run the script at 6 p.m. on a Friday, and by 8 p.m. everything was up and running on the new LISTSERV platform – no typos and no manual copying of files. It was satisfying to have that go according to plan and schedule and to know that outside of L-Soft's consulting staff, there was literally only a handful of people in the world who knew both Mailman and LISTSERV well enough to pull it off.

It's similarly satisfying to go into training with a room full of people who know nothing about LISTSERV Maestro and to leave the room four hours later with them chatting about different ways they might use it than they had initially thought possible. As with consulting, I like for my training classes to focus on labor-saving. I want to teach people to do more with our products while expending less effort. That thing that you spend 10 minutes doing manually every morning? Spend two hours and learn how to automate it once. That's the investment in training and consulting services as I see it – you spend the time and the money up front to figure out the best way to do a thing, and you recoup that investment down the road by getting more done with less work later.

© L-Soft 2015. All Rights Reserved.