4 ms·

Ask HN: SaaS Customer Notification best practices?

• jehna1 11y ago
  Use a PaaS for your SaaS. Near-to-zero downtime on deployments.
  • TTMotion 11y ago
    Back office architecture requires downtime. There may also be security announcements, IP changes etc
• c_sleight 11y ago
  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 11y ago
    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
• semiquaver 11y ago
  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 11y ago
    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
• NameNickHN 11y ago
  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 11y ago
    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