FY24.1.x: Requirements / Design (Slate+Alumni)

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

• Security and Access Management
  • Import users for launch
    • Alumni Relations - Admin and Staff
    • Program Admins
  • Define role-based security model and assign users to appropriate groups based on role
    • Roles needs to clearly separate the communications-centric needs of the Alumni and Programs from the Advising functionality
      • 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) 
    • Include program-level grouping to further segment access to program-specific student populations

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

Technical Design

• Database Ops / Feeds
  • Automate incoming data feed per technical specifications
    • From Athena (in development)
      • Requires opt-out data fields for all Athena categories
      • New field for Athena UID
  • Automate outgoing data feed per technical specifications
    • To Athena
      • SPS opt-out values
      • Universal identifier (TBD)
• Security and Access Management

• • Create a security model that supports four unique realms to serve the three utility functions
    • Advising
    • Alumni
    • Programs
    • Communications (for Slate+SPS initiative)
  • Create roles to control access to functionality based on business function
  • Update permissions on all existing objects to ensure proper access based on role and need
  • Create security documentation to define what permissions to apply to future objects based on the defined roles and realms
  • Add populations to users based on security requirements
  • Restrictions Management (Opt-outs)
    • 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
        • Categories provided in Athena integration docs
      • Ensure that all restrictions are honored across all communications
• Populations
  • Create the populations for each of the defined population groups
  • Create population rules to assign records to the appropriate population(s) based on defined criteria
  • Create queries based on populations and ensure permissions adhere to security model

• Landing Page
  • Create separate homepage widgets for the Alumni realm highlighting relevant information
    • Actual widgets TBD
• Communications / Deliver
  • Use the Designer functionality for all standard communications
    • Create components for all of the potential elements that are included in a standard mailing
    • Create templates for each type of message that requires a specific layout
    • Create a simple template that can flex its layout depending on the components in use
  • Create template(s) in simple HTML to accommodate truly unique designs that fall outside of the designer components
    • May require content blocks for shared/reused messages