Hooks for sending emails to users and partners

[willrlin]

Discussion to talk about sending emails to users and partners on a more regular basis from the Detroit site.

Our requirements from our PRD are:

• Automated reminders on some interval to property managers to update stale listings. I'd imagine that this may include a setting for the property manager to login and change the frequency.
• [Lower priority, maybe part of the Q4 fellowship]: email or text notifications to users when:
  • new listings are available
  • when new listings match a saved search
  • when favorited listings are updated

@kar-r-green if I've missed anything product-wise.

[seanmalbert]

Automated time based notifications

Would a listing be stale if the last updated date is older than the last time the job ran or should there be other factors involved?

It sounds like we'd want a cron scheduler like node-cron with the frequency stored in the database. To update the frequency it seems like we have two main options:

1. to trigger stopping the current job and starting a new one with the updated frequency
2. as part of the code that runs during the scheduler, check if the frequency has changed

Event based notifications (and possibly time based with queue)

• new listings are available
• as I think I mentioned to you in a call, we're in talks now with Alameda to use Granicus for notifying users who have signed up for email notifications. Given that it is purpose built specifically for government entities, it's possible Detroit may be interested. For at least our first iteration, we're going to have a sign up form for Granicus, and the jurisdiction will use that list to notify the users when a new listing has posted. While I'm sure this approach may not work for Detroit, they do have an API to send things like bulletins when a new listing is added

I understand that this is just a service implementation, but it highlights the need to manage user subscriptions and it's possibly easier to rely on an existing service rather than build our own. So I would say the scope of this relies on two related services.

subscription service

• allows a user to sign up and configure their notifications (new listings, matched listings, favorited updates, etc)
• allows a user to unsubscribe

notification service

• based off of the the user's subscriptions, this service sends emails when a listing is created/updated
• depending on the volume and frequency of triggering events, it's possible we may want a queueing system which sends out emails at certain, potentially configurable, intervals