
Ask HN: SaaS Customer Notification best practices? - TTMotion
I&#x27;ve been scouring the internet for information on SaaS deployments &amp; 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.<p>Don&#x27;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:<p>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.<p>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
======
c_sleight
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.

~~~
TTMotion
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

------
NameNickHN
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.

~~~
TTMotion
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

------
semiquaver
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.

~~~
TTMotion
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

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

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

