Hello Jade,

Unfortunately we are in the same situation. Our customers waiting for bugs to be fixed and keep on asking when they'll be fixed.

We always take the time to send detailed bug reports, but these past month, the answer to our bug reports is that we have to wait that MAPI version is out because it has a lot of changes.

95% of our customers doesn't care about MAPI and just want the current bugs to be adressed. We already lost some of them because they were tired of waiting and went to another service provider.

I would understand if we were requesting new features, but we're talking about bugs that prevent our users to use the service correctly.

For a period it was really pleasant to work with support (thank you Kyle, Tony) to quickly resolve bugs we submitted tickets for, but support quality really degraded recently.

I really hope this situation will be back to normal soon...

Kind regards.

Hi Sebastien

Glad to hear that we are not alone, although its not good to hear of the same being experienced by other customers.

Kyle in support has always been super friendly and super helpful and its not his nor any of the other engineers at fault - they arent the ones making the decision to let clients wait whilst smartermail as a product tries to catch up with competitors.

TBH Kyle is probably been the saving grace in this instance as I was have seriously contemplating not renewing support and spending that money on developing integration into a SolidCP / Linux alternative - hopefully management sees the recognition that have been given here and the value that one individual can add to a companies reputation.

We've also been told to wait until MAPI support has been released before some of the bugs we've reported will be fixed.

This is the same for minor bugs (i.e. multiple emails being forwarded in webmail are not being flagged as forwarded) and major ones (i.e. emails uploaded to the server via IMAP have the incorrect date/time displayed within the web interface and these messages are stored within the wrong GRP files!).

The latter bug is causing us massive issues at the moment. It's stopping us from on-boarding new clients and frustrated existing customers. I just hope ST can provide us with a way to fix or repair all these messed up GRP files.

I also want to add my thanks to Kyle, Tony and Rod - cheers guys! Their support is always great, but I feel it would be even better if more resources were put behind fixing existing bugs than focusing solely on MAPI (which we can wait for).

Hi Alex,

Thank you for talking about the IMAP "upload" issue you've raised here. I think we recently had to the deal with the same issue with some customers recently, and haven't found the cause yet.

Kind regards 

No problem Sébastien.

I've been told that the Mailbox Migration feature doesn't suffer from this bug, but that doesn't help us when a client wants to migrate several thousand emails from their local machine. This used to work in the past, but broke sometime.

I've also been told that the MAPI changes will see the introduction of a PST import feature and the code used for this *may* also be used to fix this bug.

Alex, I don't want to hijack the post topic but were the mails imported with a date in the future, or in the past ?

Thanks :)

The future. I would upload lots of emails at once and they would have the current date/time as their date (when displayed within the webmail).

The headers would contain the real date/time.

In addition, all the emails would sit in the GRP file for that day. So, the GRP files quickly hit the ~2GB limit and email clients would freak out. I saw, on several occasions, the email clients try to upload the data again (maybe a continuation of the previous upload) and would then have subsequent ~2GB GRP files for a few days. 

We all work hard, and Im sure that the majority of clients here are business owners.

My point is that we rely on a vendor to resolve issues in a timely fashion and that is not happening, and as pointed out by others, the lack of ownership and responsibility by the vendor has cost these owners customers and income.

I too have had some issues with support. I am very new to SM. I haven't even gone live with my hosted SmaterMail deployment and I'm frankly hesitant to, because of some issues I have had and how much of a "back seat" approach support takes. I put 20+ hours into this project and I would like to not have it go to waste.

I shot off an email to Emily saying how disappointing my support experiences were and I wanted those issues resolved that business day. That was the 15th, it is now the 25th and not all of the issues are resolved. Granted the new tech has done a good job, but two main issues get glossed over and I keep bringing them back up and they want another ticket. Just fix the bloody issue. It also just seems inefficient and slow to resolve tickets. A simple phone-call and 30 minutes would have probably fixed the issues.

Honestly, two things really need to happen for me to stay.

1.) The documentation needs a MASSIVE overhaul, a lot of it is out of date and most of it isn't intuitive.

2.) support needs to be significantly more hands-on and more involved.

The bugs and the unfinished parts are purely just annoyances. I understand the MAPI project was a massive undertaking which probably sucked up a lot of resources, but as a business person when my human resources are stretched thin I hire contractors. Their D&B listing looks a bit off but so does mine, but the ballpark-revenue/workforce ratio is a bit awkward. Unless D&B is way off (it can be). But lets for sake of argument assume revenue is light compared to the human capital liabilities. 

SM is very inexpensive and I mean that is a great thing. But, aside from the $300/incident emergency response, I have budget for a "Premium Support" package. Lets say telephone call back with an SLA. So low priority would be 24 business hours, medium priority would be 8 business hours, High would be 4 and critical would be 2. After hours and emergency within an hour can stay the $300. Probably some "Professional Services" would work also, at $150/hr. I can say "Hey, I authorize 4 hours, make x work." That would generate revenue to hire resources for the programming side. Could that be something that could be done for up to $0.50/user/month? I would also charge $5 per critical ticket. I do, it's a GREAT motivator that stops those customers that make EVERY ticket critical. Now only truly critical tickets get marked as such and all for just $5.

The other thing would also be have a single dedicated RSAA. I set you guys up with a Connectwise Control account (with 2fa) with access to my two mail servers and usernames/passwords for both. I do it once, and don't have to redo it every single time. Even if it is once a year, that is better than every ticket. If you want to charge for that, I'd pay $5/month for that. Technically, even at $120/year or a $250/lifetime I would grudgingly pay that. (hint: I like the $5 one better).

I understand some people might not have my budget. That's why you can keep your current pricing and add-on features. The only thing would be, where a lot of companies make mistakes, over-pricing the addons. Making premium support $1+/user/month would kill it. Let's put it this way, any chump with 500 users can get Office 365 with hands on support through a vendor for $3.28/user/month for Exchange online plan 1. If you take into account that you are not O365 and the need to host said mail server and it doesn't have active/active load balancing and failover over WAN without the need for shared storage. You want to stay at the very most $2/user/month. Put those costs into a calculation. Let's say $150/month for the hosting costs and SPLA Windows License. At 250 users that would be $0.60/user/month, plus $0.70/user/month for SM. That's $1.30/user/month. So you have $0.70/user/month for up-sells and addons. I would say $0.30 - $0.40/user/month is more than reasonable. Just resist the urge to go, "Oh, thats $6,489.99/year" like most do. At that point, I'd eat the profit reduction and move them all to O365 and call it day and go get a margarita.