Content Comparison

Special Considerations

Current State

• Programs are sending communications to alumni themselves. Therefore, SPS alumni receive emails from three different sources: Columbia's central alumni department, the SPS alumni team, and the program itself. This creates several problems:
  • There is no control about how often emails go out.
  • There is no consistent look to emails across programs.
  • Programs use their own alumni lists, which may not be consistent with other teams' lists.
  • If an alum opts-out of emails from one source, it may not be shared with the others.

Desired State

• Alumni team will make final decision on send dates in order to control frequency of emails.
• Slate will become the default platform for all alumni communications in order to create consistency of appearance. (Collaborate with the communications team to come up with email templates. Have some default starting language.)
  • Main templates: 
    • All school
    • Program templates
    • Events (invitations)
    • Announcements
  • Design Goals:
    • Ability to insert photo between text
    • Looks different on mobile vs. pc
    • Break communications down into different sections
    • Visually appealing with lots of links to connect people to the alumni webpage
• Records will sync slate with alumni database to become more data compliant
• Logic in communications such as newsletters based on the population receiving it to determine what content they are seeing

Additional Considerations

• Alumni newsletter will be designed first. Will feature alumni spotlight, faculty spotlight, campus news, etc. A separate version of the newsletter is generated for faculty. There is some information that is faculty only. Some content that is not pertinent is removed.
• Templates might need to skew a bit based on programs.
• Create a shared folder with templates so we can see the emails they’ve sent in the past.
• Email Send Cadence:
  • 9/1 - 6/30. Every two weeks, student and faculty newsletter
  • 7/1 - 8/31 Once a month
• Suggest using wealth management as testing team
• Common comms currently being sent:
  • 3 annual alumni networking events
  • New graduate campaign
  • Welcome message to each degree conferral group
  • Run emails for giving day (typically by program). Send out 40 emails in 2 week period
  • Additional campaigns (e.g. push to update emails and addresses)
• Slate allows drip campaigns. Good for controlling traffic.

Functional Requirements

• Populations
  
  • All alumni - The alumni team sends a school-wide newsletter every two weeks.
    • Use the OAD definition of alumni; only matched records that have opted-in from Athena will be included
      • E.g., People are considered alumni if they have 24 credits and have attended Columbia for at least 1 year
    • Allow for filtering on various data points 
      • Graduation year/range
      • Program
      • Geography, etc.
  • Faculty - All full-time and active part-time faculty receive a modified newsletter.
  • Select staff teams (teams that have overlap with alumni in the course of their work - e.g. admissions)
  • Donor population - Donors who want to be included (separate from parents and alumni). This data can be pulled from university database. Mostly listed as prospects or previous donors. The Alumni team wants to be able to send thank you letters to these donors.
  • Precollege program alumni/parents - for both fundraising and financial aid. This list doesn’t exist in any database. The alumni team should obtain a list within a month or so of program completion. They would send their first message in October. They would like to be able to filter the list by last year the student attended. They are mostly only interested in parents for the last few years.
  • Students who are scheduled to graduate  - The alumni team wants to email soon-to-be alumni.
  • Guests - Non-Columbia people or people from another branch at the school who are interested in activities at SPS. Prospective students as well. Manual upload.
• Security and Access Management
  • Programs should be able to send emails to alums of their program ONLY; a mechanism for uploading contact lists of non-alums should be provided
  • Restrictions Management
    • Need a form to capture granular opt-in and opt-out for SPS communications
      • Align communication categories with Athena, and require designation in all communications sent through Slate
      • Ensure that all restrictions are honored across all communications
    • All restrictions must be shared with Athena through the two-way integration
• Communications
  • Create templates for the most common regularly sent emails in coordination with Comms & Creative Services team
    • Alumni Newsletter (also sent to faculty in modified form)
  • Templates should allow for some flexibility, but retain a consistent look and feel for all users

Technical Requirements

...

• Alumni Relations - Admin and Staff
• Program Admins

...

• No student information beyond the contact details and population queries should be available to Slate+Alumni user group (unless there is administrative overlap in roles that should allow access) 

...

Functional Requirements

• Athena to Slate Feed
  • Create a source format to import Athena data.
  • Set the feed to check for a new file nightly.
  • The feed will update alumni's Athena fields in Slate.
• Slate to Athena Feed
  • Create a Slate query that exports any new additions to message groups (opt-out groups) each night.
  • Create a Slate query that exports all alumni message groups (opt-out groups) each week.
• Slate Athena Sync Portal
  
  • The Athena to Slate feed can only update alumni's Athena fields, not their message groups. Therefore, the portal  will compare alumni's Athena opt-out fields to their Slate message groups and provide a mechanism to change them either on an individual or group basis.

Technical Requirements

• Athena to Slate Feed
  
  • Create a source format with Athena data with the following fields

• Athena to Slate Opt-Out Sync Portal
  
  • Methods: 
    • Main screen: Provides a landing page for users. Uses a query and liquid template to make sure the user has permission to edit Athena data.
    • Process list: Provides a list of alumni whose records need to be updated. Uses the "Alumni with Opt-Outs" query to get the list of alumni with opt-out records.
  • Views:
    
    • Home Screen: Welcomes the user. Contains a button that directs the user to the Process List method
    • Process List: Provides a list or alumni whose opt-out records need updating:
      • The query gets the records of any students who have a "Yes" value for any Athena opt-out field OR a has any opt-outs on his/her record.
      • Liquid Template iterates over the rows checking to see if the record needs updating:
        • If the alum has a "Yes" value for CU Do Not Contact, 

Data Requirements

• Incoming Data
  • Create scheduled exports based on last modification date for the required data points in the following systems
    • SIS
      • This is already covered by the Advising project data feeds
    • Athena
      • Preferred email, address, limited demographics, and flags for communication restrictions captured at OAD
  • Create source formats and scheduled imports for all data noted above
  • Create manual formats and processes for importing any data not managed in source systems
    • None currently identified; though the idea is to support non-alumni imports, such as organization contacts
• Outgoing Data
  • Create scheduled exports for the following systems
    • Athena
      • Granular opt-out values based on the Athena integration project definition
• Managing Data
  • Create forms for adding/editing any manually sourced data points
  • Automatically imported records need to be updated in the system of record (e.g., Athena, SIS)
• Reports and queries
  • Audit queries to validate imported data
  • Determine best reports for leadership and users to validate and monitor performance

...