Ask HN: SaaS Customer Notification best practices? | Hacker News Reader

Ask HN: SaaS Customer Notification best practices?

7 pointsTTMotion8 comments

I've been scouring the internet for information on SaaS deployments & customer notification. There is no single source of info, the only stuff I was able to find was by searching a company website, like Salesforce for example, and trying to see what info I can dig out.

Don't suppose anyone here would have an idea what to do next beyond Googling? I could post a LinkedIn topic perhaps, but I work for a SaaS company so it may look a bit stupid :lol:

Info required: When to take downtime (evenings or weekends or combo) , how far in advance to notify end users, when not to notify (e.g. Patch with no downtime). Bonus would be some info on deployment processes to roll out a product to different geos.

I have all this documented and defined for ourselves, but now there is pressure from above to see can we cut corners or deploy faster so I am trying to gather information on this topic. Thanks

View on HN

I do not think there is a golden standard to follow, however I can share with you my experiences from the past.

I have analyzed traffic patterns from web logs and google analytics to determine the best time of day to schedule maintenance. Problem there is no one likes deploying at 3am!

I have added a feature to allow showing a notification banner on websites and mobile apps (typically via a new database entry) and used that to show the scheduled maintenance notice 1 to 2 weeks in advance.

In the past on more legacy b2b systems (several hours of downtime) I would even send out email notifications. This is really important if you are going to make an IP address change as customers will likely have to update firewall rules.

We would store the notification email list in an external resource / system in case of system outages.

Update your SLA to include these policies, add a section that states emergency maintenance may be performed without notice.

This is really about implementing SOP / policies and following them.

Your long term goal should be to achieve continuous deployment after achieving continuous delivery. This will likely mean removing that 'back office architecture requires downtime' hurdle. On a modern PaaS service you typically deploy to a staging environment, validate, then swap ips (production goes to staging, staging goes to production). And if everything goes to hell swap ips again to essentially roll back. This has become much easier with newer platforms and databases.

Thanks for the feedback. I have the SOP and policies defined, but product team are questioning why we need to take so long to notify customers (i.e. the product is ready, why can't we deploy to production yet). So I was hoping to find some ammo to say "Hey, Salesforce and Workday are doing xyz, this is industry standard". But it seems like I will need to make my SOPs more robust and add justification at each level. Perhaps over time I can gain some reference info. Agreed about the system architecture, but this is SaaS not PaaS

For me it would depend on how long the downtime would be. When I deploy new code and change the database structure it usually takes only a couple of minutes. That's not something I announce days in advance if at all. Most of the time I simply deactivate the system, show a maintenance message, update code and database, and three minutes later activate the system again. Since I don't do it during usual working hours (9-5), nobody has noticed anything yet.

Unfortunately the software downtime is longer and there are hundreds of customers using it. The risk of something happening is something I need to consider too

What exactly do you need to take downtime for? With careful planning this should rarely be necessary unless you're doing something like upgrading the database version.

Yes, it would be for software upgrades, db, hardware maintenance etc. The product is built in this way, I agree life would be simpler if it was more robust

Use a PaaS for your SaaS. Near-to-zero downtime on deployments.

Back office architecture requires downtime. There may also be security announcements, IP changes etc

Reply on news.ycombinator.com