ShareThis
SHAMELESS SERVICE III – MAILFIRE
// January 5th, 2009 // 6 Comments » // geek stuff
This is going to be a full on rant, so if you are allergic to people whining then don’t read it! I am sitting at work with my hands tied by bad support and unreliable infrastructure, in both cases, thanks to Mailfire, a bulk email service provided by Web Africa. Just as it takes me a lot to pimp something on the net, it takes a hell of a lot of frustration, hair pulling and teeth gnashing to actually write an entire blog post complaining about something. In summary, all I can say about Web Africa/Mailfire is that if they wanted to set up a bulk html email* programme, some research on the matter might have saved them (and us) many tears of frustration. Now, I don’t actually know what kind of research they did do when setting up the service and I won’t speculate, but the evidence suggests they missed some fundamentally simple things .
What I do know is that after approaching them several times about specific coding issues, I can still not send out emails set up in basic html and get them to render as they should when ground through the mailfire system, but which render perfectly when sent through another system**. In addition, their user interface is not simple, or rather, it is not intuitive.
Being an organisation that sends out a lot (and I mean a LOT) of html/electronic mail, some of which (for example weekly newsletters) HAVE to go out at at specified time on a specified day, we need a reliable service, and if something does go wrong, quick and dependable support (even over the “holiday season” peeps – not everyone stops working). The call I had to make today is typical – their server was offline / paralysed-tortoise-with-broken-leg slow, meaning that:
1. I couldn’t open my html docs in Dreamweaver to edit them (partly DW’s fault, as it gets a nappy-rash when it can’t find image locations / download images), leaving me the option of editing in Notepad or the like (no, I’m not whining because I’m lazy, I’m whining cos I’m busy).
2. In order to send out the letter on time, I would have to relocate all 25 or 30 images to another online location and redo the entire newsletter (an exercise so time consuming that it would still go out late).
When I called “support” to complain I first got “but it works on our side..”
DOH! “That’s not the issue.. I am the customer and it DOESN’T work on my side, and NO it’s not our connectivity – the rest of the internet LOVES me and wants to show me all sorts of things”
“Please send us an email”
“Why? I’ve told you what the problem is “
“It will have to go to a higher level”
“So take it to a higher level”
“Send us an email”
“fine”
I send them the following email (not the politest ever, seeing as I have had issues of various kinds with them from DAY 1 and by now I’m well fed-up):
“I cannot access your mailfire server to send out a message (YET again). Images in our documents (hosted on your server) are thus unavailable to us. We will thus (ONCE again) not be able to send out a message on time. “
Four hours later, I receive an email back from them:
“Hi Niki. Would you mind providing me with the client code for this account.”
NO: “we’ve fixed the problem”, “we give a shit” “we understand your frustration”
MORE: “we have not made the sodding effort to find out your client code and get started on the issue.”
AAAAARRRGGHHHH!
Now perhaps it was that we simply got exceptional service from our previous provider, Striata – a no nonsense CMS/backend mail setup, and ONE liaison who KNEW the system, was friendly, efficient and if developer’s/system advice was required, would get back to me by telephone in under 20 minutes. ALWAYS. In addition at holiday times like this, there were also ALWAYS standby staff – one person handling our account with some technical knowledge.
When I requested a meeting with the Mailfire developer to sort out coding, rendering issues, I was told that the end of January was the earliest meeting I could get (he’s apparently on extended leave) …with additional time for development, etc, a working system by mid to end Feb? For a political party with an election coming up in March/April? I think NOT. I explained this and could still only get mid January as an option, rather than in December as I had requested.
But for today (and coincidentally it happens to be my first day back after a short “holiday”), Mailfire scores an EPIC FAIL from me (perhaps I should send them t-shirts?)
I have resorted to sending out our most popular newsletter using the old (less) hassle-free system, as we still have credit there (thank GOD!). I am now seriously casting around in desperation -we have limited time and need reliable service…where do we get it without riding this off-road learning curve again?
To be fair, I should add that by all accounts, Web Africa provides excellent support in the other services they offer, such as web hosting.
* Anyone who works with html email will tell you that it is an irksome beast. Each email client (and there are MANY) selectively supports html and css, in other words, what works with one won’t work with another, and one has to be very careful (and bloody patient) when designing html email to ensure standard rendering across the board. Essentially, you use very, very old-school html and keep css inline and to a minimum.
**The mailfire system seems geared towards novices, who can pick from templates and compose their emails in the WYSIWYG editor (which seems based on WordPress), which is great for them. But many/most well established companies will have their own designers/e-communications department who will want to send out the emails they compose as they have designed them to render. Mailfire does not support this approach unlike our older system, which allows us to simply paste the code into its interface, choose a list and send AS IS, meaning if we have done our own checking, testing, etc, there are no hassles (not friendly for the novice, I’ll grant). Mailfire simply does not allow a code-list-send scenario – the only option is working through the WYSIWYG editor, which adds in much unwanted code (as they do) – I’ve even seen code added in there that I know is not compatible with certain email clients (hence my query into the research these guys have done).
