For those who haven’t used the admin tools for SQLSaturday when an event is created there are a set of messages loaded automatically. It’s up the event admin if they want to approve them, edit them, or delete them (one at a time). It’s one of the parts I wrote a long time ago and I like the concept, but the messages themselves have not been updated much and the styling is bland.
Here’s an example:
And one more example:
My mantra for events is to do work in big chunks – get in the groove and make progress. Messaging is a good place for that. If you try to write/approve them as you go, well, you end up getting behind because life or work got in the way. Depending on how much you want them customized there may be some that you will need to write later (say you haven’t nailed down the speaker party location or maybe you haven’t decided on precon locations), but you can get most of them ready to go.
I went through the messages and consider these all “good enough” to just approve as is:
These fall into the “not good enough” category and so I just delete them (so they don’t get accidentally sent or cause us to keep asking if they need to approved):
I have to now write the replacement messages (plus a few), and I’ll use my announcement list (see my previous post) as a starting point:
I haven’t written them yet, so that is work to do!
Trying to think about how we’ve used it in the past and this year leads to a few comments/suggestions:
- I wish the subject line had the option to use the city name instead of the event number (I think this is helpful especially for speakers that submit to multiple events)
- The token list shown on the editor page is incomplete (it is at least missing LOCATION) and really needs more options
- There is no styling applied beyond the header/footer you see above and no option to just point to an external CSS
- There is no option to use the previous year messages instead of the auto messages. You can copy them over one by one using the template functionality, but it’s tedious and you have all the auto messages cluttering things up.
- More than anything, I feel like the messages need a review by a few different events.
To expand on the tokens, things I wish for:
- Call for speaker end date
- Speaker party date & time range (Sep 27, 2019 7-9 pm for example)
- Speaker party
- Hotel Name
- Hotel URL
- Hotel group code
- Hotel notes (for example, do they have a shuttle to airport, or shuttle to the event)
- City Name
- Summit URL
- Summit Discount Code
- Summit Location
- Android & Apple Guidebook App URL
- Lunch fee amount
- Lunch fee cutoff date (we don’t have this as a data point in the event settings)
- Lunch description (type of food or vendor, if we have vegan/other options)
- Lunch fee URL
There are probably more. Any or all of those allow us to write richer messages and have them be much more reusable year over year. The code to replace tokens is already there, so it’s just a matter of getting the new values (at least for the ones we have vs the ones I wish for).
Thinking about all of this for a bit, I’m slightly astounded that this wasn’t tackled long ago. For example, there is no automatic Summit message? There is no message that includes previous year attendees by default?
Wrapping up, the ideal for me is that I can set up an event, glance at the messages, and then click approve, knowing that perhaps the messaging piece is done and I can always add a special one in later if needed. Ideal <> mandatory, now or in the future. If you have have someone with the time and skill to craft a set of messages from scratch, that’s great!
One thought on “SQLSaturday Automatic Messages”
Even as an attendee (and rare speaker), the city name is a lot more useful than the number. It’s great that there’s a short/unique way to get to the SQL Saturday events by number, but I’m really more likely to look at the location/date to remember the event than think “Oh yeah – #777 is in Vegas”.
Good ideas for those who run the events, though. I know the discussion came up in the community about the tools provided for SQL Saturdays and how it wasn’t something the organizers could really do anything about.
Comments are closed.