The Office of Marketing and Communications’ (OMC) Email and Automation Team
We are here to support and understand email use case(s) across the university and guide the onboarding for Salesforce Marketing Cloud (SFMC). Our role includes governing email best practices, consulting on strategy and template alignment, troubleshooting issues, and introducing new tools and capabilities to the marketing community at Ohio State. Our team will onboard and provide training via BuckeyeLearn to all users of SFMC under the university instance. The training for the Salesforce Customer Relationship Manager (CRM) partners with Strategic Enrollment Marketing (SEM) for recruiting and admission support. There are other instances of Salesforce within Ohio State — it is important to understand if your college/unit has its own instance. We do want to clarify that our team does not support Microsoft Outlook or other third-party bulk email platforms. We can support email best practices for these tools. Our team runs the Email Community of Practice meeting, please visit the webpage and request to join the community to stay informed.
Before we talk about access, there should be a discussion with leadership and other areas of the college/unit. We suggest a streamlined approach to email planning and execution. This discussion should cover who currently has access to Salesforce Marketing Cloud (SFMC) and other email tools. It is best practice to have a central email execution SFMC super user for each college or unit. We also advise all SFMC users in the same college or unit to support each other as much as possible. Each area has specific criteria for their use case for sending email with SFMC, it is important to share knowledge within each college or unit.
How many SFMC users does your area need? Not all individuals executing email should have a license for Salesforce. Approved users are based on use case review. SFMC is more complex than Mailchimp or Constant Contact, etc. Users that send emails sporadically (less than once per month) may need to rely on other licensed users for the email-sending action. See below for the reasoning for a central email super user for support of infrequent sends.