I think it is a result of the impersonal "contact us" intake forms companies have all moved to. You have no indication that you aren't just screaming into the wind. There is no personal touch. So you take to social media where your are sure at least someone hears you. It also scratches the justice itch: if the company doesn't pay attention it looks bad in public and you get some vindication for being ignored.
I'm not saying it's a good or bad thing to do, but I understand it.
> It also scratches the justice itch: it the company doesn't pay attention or looks bad in public and you get some vindication for being ignored.
This is an interesting point. There is some satisfaction from the likes, the comments, and the assurance that _someone_ is seeing your frustration even if the company does nothing.
I admit my second message was terse, but the correct social media response for a critical outage is "we're looking into it". Not "if you want support, go here".
Like I said, I do not have time to hunt for whatever support channels exist and file a ticket. I pay $50 a year so they can deliver a working product, including triaging their own issues.
> the correct social media response for a critical outage is "we're looking into it". Not "if you want support, go here".
I strongly disagree.
For those reading who may not be on X, here's Fastmail's response:
> Hello Andrew! Can you please contact our support team so we can look into this for you? http://fastmail.com/support
That seems entirely appropriate to me, for several reasons:
- it's extremely unlikely that the person managing their social media profiles is a technical expert
- their contact page likely feeds into a ticketing system, which means they can track the issue and actually make sure to respond to you
- it's entirely possible that response was automated
There are many reasons why reaching out to support will be more effective. Logging may be tied to accounts, support systems may upload client side logs where appropriate, an event may be tracked to determine a point in time when you had the problem so relevant logs can be checked.
Their messaging probably could have been better here to say "we're looking into this. If you have time, please file a support request".
On Fastmail.com, the support request is two clicks away, under the big ? button in the upper right and "Contact Support". I'm not sure how much time you have but it took me less than 1 minute to find this button and submit from my logged in account.
This. I am a paying customer. Fastmail's support is stellar. My first port of call is their official customer support channel. Why should I roll the dice on social media, when I have a direct line of support???
This time, I was on the support ticket window, but the penny dropped and I realised it was a service outage / degradation. So I decided to hold back for a bit before filing a ticket.
Based on experience with their service, I trust that their people know what they are doing, and are already on the job.
They don’t. But as a Fastmail customer, I am _really_ tiring of how much they iterate on their UI/UX without notice and seemingly decreasingly solid testing. They push stuff to prod that doesn’t hit beta (at least the public beta environment) regularly. I just stopped using the beta environment because they only test “big” stuff there, it seems.
But for the past year they’ve been nitpicking their GUIs and UX and it’s maddening. They take away or move intuitive and accessible features with no replacement, or end up making you do more clicking/tapping to get there.
I have sent feedback to support many times. Sometimes they revert changes within a week, and sometimes it’s just the canned “we strive to always enhance our customer experience” copy.
Either way, it’s disruptive and unwelcome. Their 2021 era UI was perfect. When they started announcing partnerships with other companies I think they also ended up with more users that are consumers and that creates tension with prosumers and professionals.
Fastmail used to be a haven for people who cared about email and privacy, and many of us chose them based on our own professional experiences running email infrastructure. But now it’s quickly “consumerizing” and their designers clearly have the “to enhance is to remove” mentality.
And as a reseller — don’t get me started on their new billing system and model, which is less reliable than what came before, less flexible, and was launched with no real supporting documentation.
/rant.
The service is still fantastic though in terms of speed, infrastructure, etc. I trust their technology a lot. Their UX/UI people need a time out. Whoever replaced their “Moonpig” billing system with Paddle did the users a disservice.
I’ve been a Fastmail user for years, but I don’t know that I’ve had the same experience. I think I’ve noticed a few UI polishes, but nothing that broke my workflow. What sorts of things have you ran into specifically?
They don't deserve punishment. But they should understand that this is not just "their product" but it is also my tool. Tools like this do not need to change and absolutely should not change without there being prior notification. Yes, in many ways the UI changes are trivial. They don't fundamentally change what's possible. But my keyboard never changes on me without input. My workbench doesn't rearrange itself without my input. If they want this to continue to be my tool (I've been happy to pay them for it) it needs to respect my time and attention.
I'm not a Fastmail user, but... if I were paying a company to read my emails and they shipped a new build that broke that feature due to a lack of basic testing, I'd be publicly "shaming" them.
I don't know. I'm always confused when social media accounts ask to report issues over different channels when it's so much easier to just reply to customer and ask for additional (non PII) information there. In this case it's unlikely that this was the only or even first report about this issue. So why place the initial burden on a paying customer? If your social media is just a marketing channel, at least make that clear so i don't even bother reporting issues that route.
Companies make it clear how to report issues by having a separate support system. If you clicked a "Support" link and it took you to Twitter, I could better understand your confusion.
As for using social media to take issue reports: What will you do when you need PII or have to reassign the issue or reassign part of the issue and those people need to be able to contact the user?
"Why place the initial burden on a paying customer?" Because it creates a better service for everyone to have a known way of doing things.
"Things Happen", in production, to the best of us (and FM's pretty damned good at their job). Pretty sure someone's pager duty has been going off like mad.
A little over half an hour ago, the mail UI broke for me on Android, and then I panicked and went to desktop web and it broke there too. Also on different networks.
As far as I can tell, stuff from their CDN is 404-ing, and a JSON api POST request appears to be going in infinite loop with 200 OKs.
The webmail piece seems to be borked... Calendar, Files, Notes etc. are at least rendering.
The design refresh is actually one of the few I don't hate, I got it yesterday and it is decent. But the blank emails thing started today and this... is a problem.
I disgree. Other people were saying it's broken too. Reasonable company behavior here would be 1 tweet "we'll look into it", and then either "we reproduced and are working on a fix" or "looks good to us please contact support so we can investigate your particular issue". But there's no reason to initially make users jump through hoops.
That response is probably standard support procedure. I think it’s pretty reasonable behavior. Could it be better? Sure. Is the person handling Twitter interactions doing their job? Also sure.
This comment section's been illuminating to see who has probably never worked public-facing support or service industry.
There's no amount of money you can pay to make this behavior not shitty. Shitty behavior is never a good look, but sometimes it's understandable. If you refrain from being shitty, you won't have to worry about whether or not it's understandable.
Also, the only reason that someone can be shitty and get results is because other people aren't. (In this case, "submitting" a bug report via Twitter and still getting a resolution is possible because other people reported it through the proper channels.)
It didn't break anything for me. However, I am failing to understand the point of this design "refreshment". There is nothing new out there, just minor UI changes with no purpose?
It makes access to the calendar, contacts, etc., one less click, which I think is nice. Would have preferred all that was set to buttons at the top instead of a thin side bar though.
Maybe they don’t realize how important you are. This is a failure in their VIP program, imo they should expedite that over a bug that effects all users.
Ha, cool. I imagine an an age of AI and LLMs, a lot of people are going to feel special at different points despite the cost of that going to nearly zero.
It started out as not being able to search, but the situation is quickly deteriorating and now I'm unable to open pretty much any email message.
Some content seems to briefly show up and then it quickly disappears and after that, it's as if cache has been invalidated and you can't get back into it.
Luckily for me the Drafts folder's showing, so I was able to send (well, I assume it's sent) the Single Most Important Email I need to send today, which I'd spent about half an hour getting right just as the interface imploded...
Edit: apparently "hybrid apps" using webviews are allowed as long as they're not "thin wrappers" for websites and provide meaningful functionality. See also: the capacitor framework.
There are a few different threads on this and now that things are in a stable place I'm going to cross post this to all of them!
The larger context is that we're making a major change to how we create IDs for email and mailboxes over the JMAP protocol. The old IDs are a UUID for mailboxId and the first 25 chars of the sha1 of the message for the emailId, prefixed by an 'M'. The new IDs are the createdmodseq for the mailbox prefixed by a 'P' (these are pretty short for most users) and a reverse counter of nanoseconds of the message internaldate (delivery time) for the emailId. This gives good storage density for offline and good data locality in databases for the email listings.
This morning we rolled out a build which we'd tested extensively on our staging and staff servers, but missed that for older v19 mailboxes which hadn't been upgraded to v20, the code to check if messages belonged in a thread incorrectly marked them all as missing.
This made MOST emails appear missing for most customers, clearly a very bad situation.
We immediately rolled back, but in the hurry missed that an unrelated change to correct subject matching for some languages (Japanese users had reported the issue, but possibly others as well) had changed the thread version, so new threads then had failed reads (making some, though many fewer, messages appear blank in the UI). There were about 50 million attempts to read those values over 15,000 users, because our UI was keeping on retrying thinking it was just a temporary synchronisation issue because the previous request told it there was a Thread to fetch data for. Ouch. https://github.com/cyrusimap/cyrus-imapd/pull/5527 contains those changes.
Anyway, since the only difference between the old and new records was normalisation of subjects, I wrote a tiny patch to let the old code read the newer records and just deployed that, which made all the emails re-appear for everyone again. This is the one bit of code from all this which isn't in a public repo, but it's two lines of: if (version == 2) version = 1;
But we'll wait until Monday to upgrade again, when we have fresh eyes available to watch that it's OK.
...
P.S. this is almost entirely unrelated to the UI changes. The underlying reason we're doing these changes IS related to UI changes, it's there to make offline mode use storage more efficiently on your device because the IDs are smaller and provide better data locality, but the timing is purely coincidental. The Cyrus changes have been done almost exclusively by the team in the USA and the UI changes by the team in Australia, and our deploy timelines were not synchronised.
I've been a happy Fastmail customer for 11+ years and will continue to be so. Everyone wrote that their experience with FM support has been good, but I've been even luckier: until today I never needed support. One bug per decade is a great record.