Archive for the ‘System Administration’ Category

Managing Customer Communications

October 22, 2008

We sell our products over the Internet and our customer service is likewise managed predominantly via email. When I started at the company we had a several support addresses which were sent directly to a staff member’s Inbox. These were then forwarded on to individuals within the team to answer. Obviously this was an appalling state of affairs as there was no real way to track workload, whether the customers were happy with the responses and generally no management oversight as to what was happening. It also meant that there was very little consistency in responses as everyone basically re-wrote their responses every time. Not very efficient.

As a result we had a look around at ticketing systems that we could use to manage the customer correspondance. Because we were dealing with end customers, a traditional CRM system didn’t really meet our needs. We do not have a long history with most of our customers – instead dealing with product questions, returns etc. We wanted something more lightweight, but still capable of being able to track customer history if necessary and provide management reporting etc. Any solution we look for now also has to integrate with LDAP. Zimbra uses LDAP internally and provides extensions to allow for single sign on. This will allow us to manage user accounts centrally.

Having used Zimbra, we now had some Linux expertise in house (more on this later) and decided to trial Request Tracker. This is a Web based tool that receives emails sent to specific addresses and delivers them to Queues set up within the system. It also has an FAQ Management system (RTFM) which integrates with Request Tracker allowing our staff to formulate standard responses to common questions. This saves time and effort. You can define arbitrary queues, and groups of users, permissions assigned to a user/group/queue combination. It is an incredibly powerful tool and because it is written in perl easily extensible (if you know perl). It supports a multitude of databases ensuring that it is likely to support a database  you are already using.

Of course, as with a lot of Open Source systems, this is also the major problem as well. Because *everything* is configurable, it means you have to configure everything. They options are mind numbing. Once it is set up, you should not have to play with the permissions too much more, but if you do, be ready to start scratching your head for a while. In addition to this, because the system is so easily extensible, some functionality is not easily available unless you write some perl code. For instance, it makes sense to define a single automated response, rather than trying to create 20-30 of them for each queue, but if you do that, there is no obvious way of stopping a particular queue from using the global one. Unless you write some perl code. There are also some extremely odd artifacts in the user interface – for instance, when replying to a ticket, rather than having the recipients checked and allowing you to uncheck people who shouldn’t receive the reply, instead everyone is unchecked and you have to explicitly click on the ones who should not receive the replies. A usability expert would have a field day with that one.

While RT integrates partially with LDAP, it will not take the group membership from LDAP, so you still have to manage every user in two places. This is painful. The other integration issue we have yet to address is to tie in customer tickets with our internally developed system to manage customer profiles etc. Ideally these would be linked. We plan on revisiting this when we look at ERP implementation.

So is RT a good solution? Well it is certainly very powerful and if you can live with the geekyness (and have perl expertise in house), I would recommend it. For us, I would drop it in a minute if there was a more user friendly solution out there. Any suggestions?

Cheers,

David

Advertisements

Email strategy

October 15, 2008

Having decided to migrate to Open Office, we then needed to decide what we were going to do with regards our Email. Everyone had been using Outlook, connected to the Small Business edition of Exchange. This worked reasonably well except for the fact that Exchange didn’t have a built in Spam filter which resulted in hundreds of Spam emails being delivered per day to various people within the organisation. There were also Desktop support issues with Outlook; when the pst files get larger than 2 Gig corruption is likely to occur which did factor into our thinking. The Small Business edition of Exchange had several key limitations for us including a limit on accounts and also total file storage. This meant that we could not keep our email centrally (and hence backed up) and were about to run out of users. We needed to find a replacement.

Our basic strategy is to migrate as much as possible into Web based applications. This reduces desktop support costs as well as hardware costs (eventually – when we have no desktop applications required any more). As such we went looking for a Web based email solution. We had a look at a variety of solutions and eventually settled on Zimbra. This looked to be extremely full featured with a Web interface that was exceedingly close to that of Outlook (2003) which the users were already used to.

Running through our due diligence on the software we even discovered that Microsoft themselves could find little to criticise (see: Microsoft’s curious infatuation with Zimbra). With Zimbra being Open Source, we downloaded it and trialled it with some of our users to find it worked, very very well. It has built in anti-spam which immediately cut down on a huge percentage of the Spam received, while providing a usable interface for most of the users.

One user didn’t like the fact that messages were marked as read in the preview pane (this was subsequently fixed by Zimbra in their v5 release) and for users that had to download attachments regularly, it was slightly less well integrated with the Desktop than Outlook was. However, the increase in efficiency as a result of the Spam solution more than made up for that. With the v5 release, the cross mailbox conversation view is astonishingly good and everyone who has used it has commented on this. It is far better functionality than we have see in any Desktop app. An additional benefit is that the same interface is available when travelling as within the Office (without requiring a VPN to be set up).

While we started off with the Open Source version, we migrated over to the Network Edition after 6 months – mainly because we had migrated critical emails from the Desktop PST files that Outlook had used to ensure that we had backed up email on the server. This resulted in a much larger Email store than anticipated and with the Open Source edition, we only had offline backups which started taking in excess of an hour to run. Migration to the Network edition allows us to have online backups which makes life much easier. It also cost far less than upgrading to the full version of Exchange.

The upgrades for Zimbra are excellent – it is being actively worked upon and each new release brings us functionality that we find useful. The latest version (as of October 2008), v5.10 apparently provides automatic translations courtesy of Yahoo – which for our Customer Service team is of major interest. We shall be testing this shortly.

I would like to find a downside to our transition to Zimbra, but the experience has been great. We can highly recommend it. While there was some initial resistance to migrating away from a desktop email client, a year later everyone is using the Web interface smoothly.

Cheers,

David

Desktop Strategy, part 2

October 10, 2008

Now we had made a decision on the hardware, we then needed to look at the software. One of the banes of any Administrator’s life is licence management. It is always painful and not a lot of fun. We had to audit the software in use and look at whether we could identify valid licences for it.

The primary software used in many businesses is of course, Microsoft Office. On the original machines we were mostly licenced for MS Office, but different versions with different subsets of software available. Everyone used Word and Excel, some used Powerpoint and everyone used Outlook for email. Unfortunately, whoever had purchased the licences for Office had only purchased OEM licences which meant that as we replaced hardware we would have to re-purchase software we had already bought. Ouch. In addition to this, we were on Office 2003 and would have needed to buy Office 2007.

As a result, we reviewed our options and decided to look into Open Office. I had only previously used Microsoft Office and entered into the review with a degree of skepticism. My preconception was that it would be pretty good, but not quite as good as MS Office. I assumed we would be sticking with MS Office as a result. However, the review was most interesting; it turns out that Open Office has a different approach to document management than Word – it really pushes you into using a style based solution. Having used Framemaker back in the early 90’s this was a blast from the past.

The advantage of a style based solution when you are in a company with more than a roomful of people is that it makes it very easy to create document templates which enforce a specific style and merging of multiple documents (for things like a weekly report) becomes very easy to create a consistent look and feel between multiple authors. Word obviously supports styles, but I have always found with Word that it tends to splinter unless everyone is incredibly disciplined about keeping the same style. In a small company that tends not to be the case.

In addition to this, the look and feel for Open Office was much closer to Office 2003 than Office 2007 was. Reading reports on the Internet there was a degree of consensus that the effort involved in training would be smaller for Open Office than the new Microsoft suite.

So, having trialed the software with the more technically savvy of the company, we made the plunge and migrated to Open Office, saving us the cost of 50 or so licences of Microsoft Office. A saving in the thousands of dollars.

One month after the migration, I had a total of 12 support requests from the users asking how features worked. Most of these were already covered in our migration documentation, so we pointed them to that in the first instance. As part of the migration we didn’t mass convert any documents, but left it to the users to save in the new file format as they opened them (to minimise costs). This saved huge amounts of disk space as the ODF file format appears to be far more space efficient than the MS format.

We have now been excusively using Open Office for 18 months and generally we are very happy with it. It does however come with some issues that were unexpected and have required some effort:

  1. If someone else is editing a document, it does not tell you who it is. Instead it comes up read only. When you have people in multiple offices, this becomes an issue.
  2. We have two sites with a wireless link between them. Every so often Open Office will lose the connection for some reason and be unable to save the document. Mostly this is worked around by saving to a local disk and copying back to the network. However, sometimes the Open Office format seems to get very broken and the only option is to save as an MS format and then re-open it and re-save the file again. Nasty.
  3. There are some areas of incompatibility which don’t appear to be high on the radar to be fixed. One example: Calc does not understand the Excel A:A syntax for referring to an entire column. While these are not the biggest of issues, it is disappointing to see that the only competitor to MS Office which proclaims its compatibility is unable or unwilling to fix these problems. Luckily using Google to find solutions is pretty easy.

Other than that it has been smooth sailing. We plan on fixing the first two issues by moving off file servers and migrating to a document management system, then editing will all be local and we should not see those issues again. If you are just using file servers however I would strongly recommend you test large documents on the network before jumping into Open Office. If you can live with that however it is really very good, and you can’t beat the cost.

The last aspect of MS Office we needed to look at then was Email. More on this later.

Cheers,

David