Staff Portal
ACE
CONTACT
1525 University Avenue
Knoxville, TN 37921
Main Telephone Line
(865) 974-2115
[email protected]
ACE HELP
(865) 974-4153
[email protected]
ACE
Process Planning
The conversion from ANDI to Salesforce/Ascend will be a two-fold project: As we work to implement an entirely new suite of technologies, we will also be managing significant changes in our everyday operations, changes that will affect every person in the UT Foundation. Nearly every job we do — prospect development, stewardship, gift processing, email marketing, reporting, online giving, web content management, and on and on — will look significantly different by the end of 2023.
As an important first step in our organizational change management, we contracted with Huron Consulting for an eight-week engagement to identify, map (current state), and plan (future state) our key business processes. Huron is an industry leader, with deep experience in higher education and technology transformations, including conversions from Ellucian Advance (ANDI) to Salesforce/Ascend.
Process planning is a three-step exercise: a 90-minute discussion of the current process and pain points, followed by documentation and then a 60-minute discussion of how the process will likely be transformed by our new technologies.
Table of Contents
Athletics
Bio/Demo Updates
Process Overview
Bio/demo data is manually updated on constituent records by constituent management staff, as well through update requests from development officers and administrative staff. It is common practice for departments outside of the constituent management department to designate a team member who is responsible to generate update requests. This practice is in place to limit duplication of effort and control for errors. The process of updating bio/demo information for individual records involves three stakeholder types:
- Central IT Office (Internal)
- UT Campuses (Internal)
- Vendors (External)
The process begins with one of three inputs that are categorized as internal or external. External information comes from constituents via email, voice notes, or documentation related to gifts. Internally, departments can submit updates to a specific set of data directly within ANDI for review and approval by constituent management staff or can send an email directly to the constituent management department. Data updates submitted through ANDI are limited to basic contact information, employment data and spouse details. Sending an email allows the requester to propose an update to any bio demo field.
Once information is received by the constituent management department, requests are collected in a queue. From the queue, records are evaluated individually via a manual review process. The information received is reviewed to determine if duplicate information exists in the system. If duplicate information or errors in the data exist, the requested update is denied and not entered in ANDI as an approved change/update. However, if duplicate information does not exist, the requested updated is entered and approved.
Opportunities
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Duplicate Records/Manual Review
- Currently the matching logic to look for duplicate records and duplicate data is not robust. A manual review process is necessary to ensure accuracy. Manual review is time intensive and possesses a higher risk of inaccuracy.
2. Limitations of System
- Currently users are only able to update select fields directly in ANDI. Ideally, they would have ability to update more than basic contact and biographical data.
- Fields such as prefix and gender are currently required due to system functionality, however this data is often not available. Ideally, fewer fields would be required when creating new records.
3. Joint Salutations
- Currently, the system does not create automatic joint salutations.
- There is currently no policy in place as to who should be listed first in a joint salutation.
4. Notifications
- There is currently no automated notification system for the approval, denial or completion of data update requests.
Final Summary
The analysis shows that the current process possesses inefficiencies that increase the effort and time needed to update records. Currently, this process meets intended objective, goals, and customer requirements but could benefit from the addition of automation and out-of-the box functionality delivered in implementation of the new CRM. UT Foundation can expect to benefit from increased speed of entry, reduced time and effort spent in manual processes, defined business processes for handling different types of constituent data, and transparency surrounding the approval, denial or completion of update requests.
Future State Process Overview
Bio/demo data will be manually updated on constituent records by constituent management staff, as well through updates submitted by development officers and administrative staff. The process of updating bio/demo information for individual records involves three stakeholder types:
- Constituents (External Communication)
- Development Staff (Internal Communication)
- UT Foundation Constituent Management Department (Internal Communication)
The process begins with one of three inputs that are categorized as internal or external. External information comes from constituents. In the future state, this will include information communicated via email, documentation related to gifts, or via updates made in the constituent portal. During implementation, Huron will partner with UT Foundation staff to establish matching logic to govern how the system handles duplicate and erroneous information. This matching logic will act as a point of data validation when staff members submit updates to constituent records so that duplicate data will not be entered into Salesforce.
Certain data will require manual review to maintain the Foundation’s expectation related to data integrity. These items will be reviewed directly in Salesforce and the appropriate action determined by Constituent Management staff.
Key Changes
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced. The points below indicate key future state changes:
1. Automation and Matching Logic
- Currently the matching logic to look for duplicate records and duplicate data is not robust. A manual review process is necessary to ensure accuracy. Manual review is time-intensive and possesses a higher risk of inaccuracy.
- In the future, only a small amount of critical information will be manually reviewed. This review will happen directly in Salesforce eliminating duplicate data entry and opportunities to introduce human error.
2. Constituent Portal
- Currently, constituent can provide updates to their information by emailing Foundation/campus staff or communicating with their relationship manager. This data then must be entered into ANDI and reviewed.
- In the future, constituents will be able to access a constituent portal that allows them to submit changes to their own personal information directly into Salesforce. In addition to traditional Bio updates, constituents will be able to provide more robust information back to the Foundation as well (e.g., Interests, Communication Preferences)
3. Creation of Records
- Currently, ANDI’s minimum requirements to create records are not in alignment with business needs. In the future, UTF will be able to customize the minimum information requirements need to create a record in Salesforce to better reflect their policies.
4. Joint Salutations
- Currently, the system does not create automatic joint salutations.
- In Salesforce, the system will allow automatic joint salutations.
5. Notifications
- Currently, there is no notification system to alert or inform staff or constituents of changes made or fulfilled requests. Notification regarding the fulfillment of a request is a manual process of emailing individual staff members or constituents to inform them of the status of their request. Because this process is not consistently applied, staff may receive duplicate requests to complete an update.
- In the Future, notifications of actions taken can/will be automated to send to internal stakeholders and constituents.
Key Considerations
1. Matching Logic
- Huron will partner with Central IT and Foundation staff to develop matching logic. Staff will want to consider potential criterion this might include. This will impact training opportunities in the future for staff tasked with entering data.
2. Security/Visibility/Edit Rights
- The current system limits the information that can be edited, a determination will need to be made as to which information will continue to be limited.
- UT Foundation will need to determine if there is information that should not be affected by visibility restrictions and to whom visibility restrictions will apply.
- It needs to be determined how to distribute the right to edit information, including what information can be edited/updated and which stakeholders will have the right to make edits/updates.
3. Requirements
- Determine the minimum data points needed to create a record.
4. Joint Salutations
- It will be helpful to establish/revise a policy for the order of joint salutations.
5. Notifications
- ‘It needs to be determined to whom, when, and by what method it is appropriate to send notification of actions taken to update records.
Core Impact
The out-of-the box functionality delivered in implementation of the new CRM will address most of the challenges of updating individual records. UT Foundation will benefit from increased speed of entry, reduced time and effort spent in manual processes, defined business processes for handling different types of constituent data, and automated matching logic to validate data inputs. Robust automation and matching logic will ensure that records will no longer be evaluated individually via a manual review process. The information received is reviewed to determine if duplicate information exists in the system, so that duplicate inputs will not be accepted. One of the new benefits of the CRM will be the creation of a constituent portal that will allow for constituents to directly manage changes to their personal information. Also, a new notification system will be automated to track and communicate changes to constituent data quickly and efficiently.
Process Overview
It is common practice for campus departments and vendors to send CSV files to the Central IT Office for updating bio/demo data in the ANDI system. The process of updating data through batch upload involves three stakeholder types:
- Central IT Office (Internal)
- UT Campuses (Internal)
- Vendors (External)
The process begins with one of two inputs that are categorized as internal or external. External information comes from vendors; internally, departments submit CSV files containing bio/demo information directly to the Central IT Office for review and approval. The Central IT Office runs a script to validate the data. The data is placed into staging tables and goes through a validation process. Data that passes validation is then uploaded into the ANDI system.
Opportunities
During discussion about the batch update process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Duplicate Records/Duplicate Data
- Currently there is not robust matching logic for all fields
- Data such as student activities can be batch loaded on records, but the system does not check to make sure that data is not already on the record.
2. Required Fields
- Currently the system requires that certain fields, such as prefix and gender, be populated in order to create a record; this is a point of frustration, as many external sources often do not provide this information (examples: 4H Alumni, Health Sciences alumni)
- Currently the system requires that all records have a home address; ideally this would not be a requirement, as sometimes the only known address is not a home address.
- The vet hospital receives donations from “grateful clients” (owners of pets); however, due the nature of the data, the minimum data requirements such as gender and prefix aren’t available. As such, a lot of manual manipulation to add the records.
- Parent association data often does not meet minimum requirements for entry, so therefore admissions data is typically used for parents instead. Would be ideal to be able to use the parent association data.
3. External Address Validation
- Every two weeks, information is batch loaded from NCOA; errors in the load require manual review, which is a time-consuming process.
4. Documentation
- The current system does not retain/produce a record of who completed a batched record or when it was completed
5. Notification Systems/Error Reporting
- There is no functionality that reports errors in uploading records
6. Parent Data
- Need to determine a policy for how to handle parent data for students who have not graduated and are no longer attending the university
7. Student Data
- Student data is usually linked to student ID numbers. However, a policy needs to be determined for handling of students who leave the university before graduation.
Athletics would like to contact former athletes, but many of them did not graduate from the university; a system needs to be in place to be able to track these records.
8. VIP Records
- There is no consensus definition for a VIP. Usually, VIPs are considered donors who make very large gifts, or donors who require special handling. There needs to be one common definition for this designation, in order to ensure data integrity. Currently special handling codes are available, but not used. Information regarding special handling is entered as comments on a donor’s record by development officers
- There is no way to protect the VIP data from being overwritten during vendor loads
9. Lost Records
- A record can be saved as an active record, even if it doesn’t have an active phone number, email address or address. This goes against Foundation policy; ideally they would not be able to save a record as active without one of these three fields.
- The ability to have the system prompt a user to change the status to “lost” if the record does not have an active phone number, email address or address.
10. Relationships/Spousal Linking
- There is currently no way to create relationship records, such as spouses and children, during batch loads; users must manually link the records in ANDI.
Final Summary
The analysis shows that the current batch process possesses inefficiencies that increase the effort and time needed to update records. These inefficiencies include the inability to batch load entities, resulting in the need to use staging tables. This process could benefit from the addition of automation and out-of-the box functionality delivered upon implementation of the new CRM. UT Foundation can expect to benefit from reduced errors, fewer required fields, more robust matching logic, CRM-contained address verification, as well as reduced time and effort spent in manual processes.
Future State Process Overview
It will continue to be the practice for campus departments and vendors to send CSV files to the Central IT Office for updating bio/demo data in the Salesforce system. The process of updating data through batch upload involves three stakeholder groups:
- Central IT Office (Internal)
- UT Campuses (Internal)
- Vendors (External)
The process will begin with one of two inputs that are categorized as internal or external. External information comes from vendors; internally, departments will continue to submit CSV files containing bio/demo information directly to the Central IT Office for review and approval and uploading. The Central IT Office will no longer run a script to validate data, but instead will rely on matching rules. During implementation, Huron will partner with the Central IT Office to determine and implement the matching logic that underpins the validation process. The data will enter staging tables, go through a validation process, and be uploaded to Salesforce. Data that does not pass validation will be automatically shared with Central IT, allowing for any necessary manipulations to the CSV, based on the error reasons provided and the ability to reupload manipulated data fields. Salesforce will maintain a record of what data has been uploaded, when it was uploaded, and who completed the upload.
Key Changes
During discussion about the batch update process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Duplicate Records/Duplicate Data
- Currently there is not robust matching logic for all fields
- In the future, Salesforce will allow for robust matching logic for all fields to automatically validate imported data. There will also be flexibility to allow record by record reviews of imported data within Salesforce before updating data where appropriate.
2. Required Fields
- Currently the system requires that certain fields, such as prefix, home address and gender, be populated in order to create a record; parent data also does not usually meet minimum requirements and becomes unusable
- The future state ability to control required fields will allow for importing of data from internal and external sources that have not historically provided this information
- Currently, due to the minimum data requirements such as gender and prefix not being available for grateful patients, uploading this data requires a lot of manual manipulation to add the records.
- The future state ability to limit the required fields only to those defined as necessary, according to the university policy for creating a new constituent in the database, will eliminate the need manual manipulation
3. Salesforce-Native Address Validation
- Currently, every two weeks, information is batch loaded from NCOA; errors in the load require manual review, which is a time-consuming process.
- Leveraging ascend’s Interims object will allow streamlining of the regular load of NOCA data and update of records.
- In the future state, Salesforce will house native address validation tools, lessening the burden of manual reviews.
4. Import Records
- In the current system, documentation is not retained/produced to record who completed a batched record or when it was completed
- In the future, Salesforce will produce a record of who completed an import and when it was completed.
5. Student Data
- In the current system, student data is usually linked to student ID numbers with no policy to determine handling of students who leave the university before graduation; non-graduated athletes are also difficult to track
- The future state will allow an opportunity to realign Constituent Types and other relationships to the university across various objects in ascend’s data model. This will allow for simpler reporting for those current segments that are difficult to track and report on in ANDI.
6. VIP Records
- There is currently no consensus definition for a VIP.
- This implementation will provide opportunity for staff to establish one common definition for this designation, in order to ensure data integrity. This will be easily tracked and managed in Salesforce.
- Currently special handling codes are available, but not used. Information regarding special handling is entered as comments on a donor’s record by development officers
- In the future, special handling code will be applied to donor records and be easily accessible to development officers and other staff reviewing VIP records
- Currently, there is no way to protect the VIP data from being overwritten during vendor loads
- In the future, Salesforce functionality can limit the editability of VIP records.
7. Lost Records
- Presently, a record can be saved as an active record, even if it doesn’t have an active phone number, email address or address. This goes against Foundation policy; ideally, they would not be able to save a record as active without one of these three fields.
- The future state will provide the ability to have the system prompt a user to change the status to “lost.” or automatically update the status, if the record does not have an active phone number, email address or address. These can be presented in a list view or report to be regularly reviewed by staff.
8. Relationships/Spousal Linking
- There is currently no way to create relationship records, such as spouses and children, during batch loads; users must manually link the records.
- The new system will allow for batch loading of relationship records.
- Ascend will allow for the creation of households, account hierarchies, and roll up reporting of giving that will provide Development Officers insight to complex family giving.
9. Notification Systems/ Error Reporting
The current system does not produce an import error record
In the future, Salesforce will produce a record of upload errors, allowing staff to view reasons for errors correct errors, and re-upload data.
Key Considerations
1. Required Fields
- What are the minimum required data points for creating a new constituent in the database?
2. VIP Records & Special Handling
- How do you define VIP records?
- Are their different types of VIPs?
- What actions would you like to limit on VIP records?
3. Parent Data
- What types of parent data would you like to have in the future?
- What are the current and future sources of parent data?
4. Lost Records and Other Workflows
- How and when would you like to be notified of a lost record?
Core Impact Summary
The future batch process will reduce the effort and time needed to update records, with the ability to batch load records. Matching rules will be determined in the upload process, so as to reduce errors in data. The addition of automation and out-of-the box functionality delivered upon implementation of the new CRM will address many of the pain points in the current process. UT Foundation can expect to benefit from reduced errors, the ability to automate lost/inactive status, fewer required fields, the ability to create relationship records, more robust matching logic, CRM- contained address verification, as well as reduced time and effort spent in manual processes. Salesforce will allow for the customization of a record layout so that important information like special handling codes and preferences will be easy to locate. Staff will benefit from a reduction in lost records and the ability the link records/view relationships.
Furthermore, there will be new import reporting functionality for batched records, the ability to receive import error reports and the ability to fix import errors.
Committee and Council Management
Process Overview
Stakeholders
- Development Staff
- Alumni, Donors, & Friends that serve on UT Committees
Committees are formal groups of alumni, donors, and friends that support UT’s academic, social, strategic, or fundraising initiatives. Committee participation is recorded in ANDI to track an individual’s engagement with the university. Campuses and colleges/units are responsible for the creation and management of committees in ANDI.
When a committee is created, the responsible unit must request a committee code be created in ANDI by Central Advancement Services. After the committee code is created, designated staff members can then add and update committee membership. There is special ANDI access required to make these changes, and access is provided based on job responsibilities or upon request.
Committee membership can be added to an entity record from the Committee screen in the Alumni Engagement menu. A committee code, membership status, and a start date are required. Once a membership row with the status of “current” is added, the committee membership will display on the right side of the entity overview and the entity will show up on the member list on the committee overview. When the committee member’s term ends, the responsible staff member must update the committee row with a “former” status and a stop date. There is no automation in committee membership, meaning status and start/stop dates must be updated manually.
ANDI users can pull a list of committee members from the lookup screen. UTFI Business Intelligence has also created a committee dashboard to measure committee membership, member giving participation, and other metrics. Committee membership currently affects alumni engagement scores, as well.
Committee management in ANDI presents several challenges. There is no simple way to see a list of active members. Membership updates must be made record by record. There is no way to attach ownership or responsibility to a committee, making it difficult to determine sometimes what unit or staff member is working with the committee and members. The most holistic view of committees is on the dashboard, but updates cannot be made directly from the dashboard. Additionally, any updates made in ANDI won’t reflect on the dashboard until the next day. There is also very little information about the committee in ANDI. There is no ability to denote the purpose or responsibility of the committee (alumni board, donor board, academic advisory board, special interest board, etc.). There are no details listed about the criteria for the board – who is eligible, how members join, term lengths, etc.
Opportunities
Holistic Management: Create a committee overview that allows Central Services to assign a dedicated staff member to manage a committee. Once assigned, development staff can view active committee members, former committee members, and relevant details for the committee. Allow authorized staff to update active membership from the committee overview, pull a list of information on committee members, and add relevant details about the committee. Allow development staff to be assigned to committees for which they are responsible. Allow the ability to create committee meetings and mark which members attended.
Expand Description and Key Data Fields: Make it easier to include important information about a committee on the committee overview page. This includes the general purpose of the committee, membership conditions, meeting schedules, associated allocations, and other relevant data.
Expand Participation Coding: Add additional coding to denote different types of committee participants. Some members participate as an individual, but membership also includes UT faculty/staff and industry representatives. Clarifying participation types will allow users to track all committee participants. This can also be beneficial when calculating giving participation totals, especially for boards with industry representatives.
Communication Campaign
Process Overview
Communications campaigns involve the use of several processes, depending on which campus submits the request to initiate a campaign. The following stakeholders are involved in executing a communications campaign.
- UT Campus Departments (Internal)
- Central Advancement/Online Engagement Team (Internal)
- Campus Alumni Office (Internal)
Generally, communication requests are sent to the Alumni office by a representative from the individual campus. After receiving the request, the Alumni office submits a JotForm to the online engagement team. The online engagement team hosts several types of forms: email, events, and newsletters. Completion of the JotForm triggers a Trello card via the Zapier connection of the JotForm and Trello apps. (Trello is a project management tool that the Online Engagement team uses to manage projects, such as email campaigns). Upon creation of a Trello card, all four members of the online engagement team are notified.
The project is managed by the engagement team member who has the most experience with the campus initiating the request. Once the project is assigned, a send date is added to a centralized calendar of upcoming events and campaigns as a placeholder. A member of the Online Engagement staff builds the email, and the requested communication is reviewed internally by Online Engagement staff. Once the created email is approved by staff, the list of recipients is uploaded, and the email campaign is scheduled to be sent.
Some campuses do not follow the general process, due to campus administrators having the ability to generate their own emails for email campaigns. These campuses include UT-Knoxville, UT-Chattanooga, and UT Health Science Center.
University of Tennessee-Knoxville administrators build their own emails, which are then reviewed by an internal Digital Communications Team, who completes the JotForm supplied by the Central Advancement Services Online Engagement Team. The Online Engagement Team then adds the campaign to the centralized calendar, reviews the email and sends edits back to UT-Knoxville for approval. Some emails require additional approval, and in those cases, the Assistant Vice Chancellor approves email communications. Once the campus approves the email, the approved communication is sent back to Online Engagement. Once the Online Engagement team receives the approved email, the recipient list is uploaded, and the outbound communication is scheduled.
At the University of Tennessee-Chattanooga, campaigns are scheduled during quarterly and monthly meetings. After these meetings, administrators build emails, which are sent to the Donor Engagement team for approval. Once approved, Donor Engagement sends the emails to the Online Engagement Team of Central Advancement Services. The Online Engagement Team then adds the campaign to the centralized calendar, reviews the email and sends any email edits back to UT-Knoxville for approval. Emails requiring additional approval are sent to the Assistant Vice Chancellor to approve email communications. Once the campus approves the email, the approved communication is sent back to Online Engagement. Once the Online Engagement team receives the approved email, the recipient list is uploaded, and the outbound communication is scheduled.
University of Tennessee Health Science Center follows a different process: an internal intake form is completed by administrators via iModules/Encompass. The form is received by the Alumni Affairs team, who then sends the request to the Assistant Vice Chancellor for approval. Once approved, the email is designed by the Alumni Affairs team, who then submits the JotForm, sending a campaign request to the Online Engagement Team. Once the email is scheduled and reviewed by the Online Engagement Team, the email is sent back to the campus for approval. If changes to the email require additional approval, the Assistant Vice Chancellor will review the email and send the approved version back to the Online Advancement team. Once approval is received, the recipient list is uploaded, and the email is scheduled to be sent.
Opportunities
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Data Centralization
- Not all emails are created by the Online Engagement Team.
- Different campuses follow different processes because administrators can create their own emails.
- Emails requiring additional approvals can prolong the process before email campaigns are sent.
2. Project Assignment
- Currently there is no standardized rule for assigning communications projects.
- Assignment rules can reduce the dependency on multiple apps like JotForm, Zapier and Trello to manage communications and project assignments.
3. Campaign Calendar
- The calendar could be improved by providing information about audiences.
- If audience information were provided, planned send dates for emails could be adjusted to reduce overlapping emails.
4. ‘Subscription Preferences
- If a constituent unsubscribes from one type of communication, he or she is opted out of all communications; subscription preferences would allow for email recipients to choose the types of email communication they would like to receive, without removing them from all communications.
5. Reporting
- Depending on which Central IT staff member generates the recipient list, a different constituency is produced based on their specific process for generating the list or knowledge of the data set.
- There are no standardized segmentation rules
- Currently, event communications are not facilitated by specific campaigns or comprehensive communications strategies.
- Emerging changes in the industry related to privacy (e.g., Apple email privacy capabilities) can impact reporting; this includes functions like masking emails, which obscure information regarding open rates and engagement.
- Non-Alumni donors are not loaded into ANDI.
6. Analytics
- Predictive analytics functionality is lacking.
- Campaigns would benefit from insights to reengage, to create personas or attribute-based journeys/communications, or actions taken in previous emails
7. Multi-Channel Communications
- Currently email is the sole channel for campaign communications.
- Campaigns could benefit from the use of multiple communication channels, i.e., SMS messaging.
Final Summary
The analysis shows that the current process possesses inefficiencies focused on standardization of data retrieval processes, availability of audience information, lack of analytical functionality, individualization of communication preferences, and lack of multi-channel communications. Standardization of data retrieval processes would produce consistency and reliability of data. In addition, non-alumni donor opportunities are lost because ANDI does not house data on non-alumni donors. Furthermore, a time-lag exists concerning the validity of data, due to the updates not being loaded into the recipient list between the time the data is generated and the actual send-date of communications.
Having comprehensive, centralized, real-time data in Salesforce will eliminate the time lag. Reliable data and standardization will also address the problem of reliance on the personal knowledge of the person generating recipient lists. Moreover, staff retirements will no longer be a hindrance, as standardized retrieval practices will reduce reliance on personal knowledge and bring uniformity to the process. More robust analytics and audience insight could improve targeting, timing and personalization of communications. Additionally, not tracking subscription preferences negatively impacts the ability to communicate with constituents. If a donor unsubscribes from one email or newsletter, the result is that they completely opt out of all communication instead of being able to provide information on the ways they would most like to receive advancement communications.
The inability to customize communication preferences is also related to the limited communication channels used by Advancement. Currently, email is the sole communication channel, but Salesforce Marketing Cloud will allow for the ability to build interest profiles, customer journeys and roll out multi-channel communications planning.
Future State Process Overview
Communication requests will be initiated by each campus’s Alumni office, who will determine if communications are intended to satisfy a campus-specific need. If the communication is campus specific, the alumni office will generate recipients from a list of standard segmentation reports. Segmentation parameters can be defined prior to go-live, during the implementation process. Campus personnel will have access to share email templates and have the ability to create communications campaigns in Salesforce. During the communication creation, the recipient list will be indicated, along with the desired send date. Centralized communications calendars will allow for the coordination of communications across campuses, as well as across initiatives/campaigns on a particular campus.
If the communication is not campus-specific, alumni personnel will request that the Online Engagement Team produce the campaign. The Online Engagement Team will create a campaign in Salesforce and generate the appropriate invitee list, based on the request of the originating campus. The OET will create the communication piece, review and attach approved emails to the campaign, and schedule the send date to the appropriate recipient list.
All communications will be tracked in Salesforce and engagement information will be available for view on the constituent’s record. Real-time insights will be available to determine the impact of a particular or group of communication campaigns.
Key Changes
During discussion about the process, several improvements to current inefficiencies were identified:
1. Communications Coordination/Centralization
- Currently, not all emails are created by the Online Engagement Team.
- In the future, approved email templates will be housed in a shared templates folder.
- Presently, campuses follow different campaign planning and execution processes, allowing administrators to create their own emails.
- In the future, administrators will be able to review, update, and attach templates to campaigns for campus specific communication. Wider reaching campaigns will require assistance from the OET.
- Currently, some recipient lists are built with information from outside the ANDI system.
- In the future, Salesforce will house all data and email templates.
- A central communications calendar will allow for increased coordination of communications.
2. Project Assignment
- Currently, there is no standardized rule for assigning communications projects, and multiple external systems are used to execute campaigns and track project management functionality.
- In the future, the creation of assignment rules will reduce the dependency on apps like JotForm, Zapier and Trello, which are currently used to manage communications and project assignments.
3. Subscription Preferences
- Currently, constituent subscription preferences are not comprehensive and result in constituents opting out of more than they had potentially intended.
- In the future state, email recipients will be able to comprehensively communicate their subscription preferences. This will enable communications staff to honor the specific wishes of constituents.
4. Reporting
- Currently, depending on which Central IT staff member generates the recipient list, a different constituency is produced based on their specific process for generating the list or knowledge of the data set.
- In the future, segmentation at least 80% of the audience segmentations will be predefined and housed I shared reports, following standardized segmentation rules.
- Currently, non-alumni donors are not loaded into the system.
- In the future, Salesforce will add the ability to track communications to non-alumni donors via reporting functionalities native to the system.
5. Analytics
- Currently, predictive analytics are not employed in communication campaigns.
- In the future, audience insights will assist in reengagement activity, provide for the creation of personas or attribute-based journeys/communications, experience tracking and robust tagging functionality.
6. Multi-Channel Communications
- Currently, email is the sole channel for campaign communications.
- In the future, campaigns will benefit from the functionality of multi-communication channels, i.e., SMS messaging.
Considerations
- What data would you like to use to drive segmentation in the future?
- Who will be able to create a communication campaign in the future? Who will create communication templates/content?
- What communication engagement information would you like visible directly on the constituent’s record?
- What uses for dynamic content and automated communications journeys would you like to explore first?
Final Summary
The current system possesses inefficiencies surrounding standardization of data retrieval processes, availability of audience information, lack of analytical functionality, individualization of communication preferences, and lack of multi- channel communications. Standardization of data retrieval processes will produce consistency and reliability of data. Non- alumni donor opportunities will no longer be lost because of the new ability to house non-alumni donor data in Salesforce. Real-time data availability will add integrity to the data retrieval process, eliminating the time lag between data retrieval and the send date of communications.
Standardization of the data retrieval process will also address the problem of reliance on personal knowledge to generate recipient lists, bringing uniformity to the process. More robust analytics and audience insights will improve personalization of communications. Additionally, tracking subscription preferences will improve communications, by ensuring communications are targeted to the appropriate constituents. Currently, email is the sole communication channel, but Salesforce Marketing Cloud will provide the ability to build interest profiles, customer journeys and roll out multi-channel communications planning.
Constituent Types
Corporation and Foundation Engagement
Process Overview
Stakeholders
- Central Advancement Services Staff
- Development Staff
- Corporation and Foundation donors
Corporation and Foundation fundraising activities require unique technological support from the CRM. CF fundraising can be more complex because it can incorporate multiple entities that fall under the same organization. There could be several records in the system for the corporation since a unique record has to be created for each relevant entity. There will be one parent record, but corporate foundations, subsidiaries, divisions, branches, plants, and others could fall under the umbrella for the parent organization.
Having multiple entity records under a parent corporation can complicate other aspects of the fundraising process. The first is that it can be difficult to get a holistic view of a corporation’s giving to the university. There is no simple way in ANDI to synthesize the giving data.
A second issue is that alumni employment numbers are spread out over several entity records. If the company is a matching gift company, most employed alumni will be linked to the matching gift entity record (usually the corporate sponsored foundation). However, this is not guaranteed. Employment data might end up tied to any one of the entity records in the system – the local branch the alum works for or the parent record. Clean-up of this data must be done manually, so it is difficult to see an accurate picture of alumni employment by organization.
Note: An issue in ANDI that is not unique to CFE fundraising, but is relevant to this discussion, is that alumni employment is stored in two different places on an entity record. ANDI has an employment table that allows us to store the employer (linked with an ANDI ID if available), job type, job title, and job status. Employment can also be listed in the address table as a business address. Sometimes, especially with automatic batch loads from data submitted externally, employment data will be updated in one section but not the other. It is difficult to tell which section contains the accurate employment data.
Another complicating factor of CF fundraising is the establishment of prospect records. Prospects are connected to entity records. We have not had a consistent policy in the past that stipulates how corporate prospect records should be created when multiple entities are in the corporate hierarchy. Unless there is an established corporate hierarchy, it is not easy to see which entity record is the “correct” record. This can lead to the entry of contact reports on the wrong entity record, making it difficult to know who is visiting a CF prospect. There might be multiple prospect records created for a corporate entity, so it is also difficult to see how many proposals have been submitted to a corporate entity.
Central Advancement Services has worked to manually build corporate hierarchies. The hierarchy establishes a parent record and connects all associated entities (corporate sponsored foundations, divisions, subsidiaries, plants, branches, etc.). These updates are made by Prospect Research and the UTK Corporation and Foundation Engagement team. They are researched and coded manually. However, there is no indication of where the entity falls in the corporate hierarchy from a lookup, so users must go to a record and then view the corporate hierarchy.
Opportunities
Corporate Hierarchy: Allow companies to be connected in a corporate hierarchy that is automatically sorted by different types of entities so that the tree displays the entities in a logical order.
Record Search: When searching for the organization name, include the record type and its position in the hierarchy (parent vs branch). Ideally, we would have a feature that allows a user to display the corporate hierarchy as they search before selecting a record.
Single Prospect Policy: All entities part of a corporate hierarchy should fall under a single prospect record. This will allow all development officers working with the corporation to be aware of what others are doing.
CF Record-Specific Data Categories: Allow for a more extensive “relationship” section for organization records: this should be able to include faculty partners, important alumni employees, and various corporate contacts. It would also be helpful to have a section that can list the various locations of a company (headquarters, branches, etc.). A section where fundraising or research interests could be tracked would be beneficial to fundraisers.
Alert Capabilities: Organizations usually fund awards through multiple payments. It would be ideal for alerts regarding these payments to be pushed from the system (when money is expected, when documentation needs to be sent, etc.).
Improve Employment Data: Allow alumni to be connected to the relevant corporate entity (the specific location they work for) while allowing that data to “roll up” to the relevant corporate foundation and parent record. This will allow employment totals and matching gift potential to be measured more easily.
Data Integration
Deceasing
Events
Process Overview
Planning and execution of alumni events begins with individual campuses. Each campus’s Alumni Office controls planning.
- Campus Alumni Office (Internal)
- Central Advancement/Online Engagement Team (Internal)
- Central IT Office (Internal)
Planning for events begins with the Alumni Office on individual campuses. Events can be planned well in advance of execution, but sometimes alumni chapters decide to hold events ad hoc. Alumni staff usually use Excel spreadsheets to track elements of planning: budget, timeline, action planning, etc. Some campuses use the project management
tool “Monday”. Once plans are set, the Alumni Office submits the ANDI reporting request form to generate an invitee list.
Once the Central IT Office receives this request, they generate a list based on the parameters provided by the Alumni Office and forward the list to the Alumni Office that initiated the request. If the list generated does not meet the requirements for the office, the Alumni Office may adjust the parameters and re-submit the request to the Central IT Office. Other times, the Alumni staff may manually adjust the list in Excel. Additionally, some campuses can generate their own lists if the Central IT Office is overwhelmed with requests.
Once the list is approved, an Alumni Office staff member submits a JotForm to the Online Engagement team. The Online Engagement team hosts several types of forms and is responsible for creating registration forms and email communications for an event. Completion of the JotForm triggers a Trello card via the Zapier connection of the JotForm and Trello apps. (Trello is a project management tool that the Online Engagement team uses to manage projects, such as email campaigns). Upon creation of a Trello card, all four members of the online engagement team are notified. The project is managed by the engagement team member who has the most experience with the campus initiating the request. Once the project is assigned, an event and send date are added to a centralized calendar of upcoming events and campaigns as a placeholder.
A member of the Online Engagement team builds the registration form and email communication, and the requested communication is reviewed internally. Once the registration form and created email are approved by staff, the list of recipients is uploaded, and the email campaign is scheduled to be sent. Some events employ the use of mailed invites; when mailing invites, the list of invitees is sent to a vendor who executes the mailings.
During and after event execution, attendance and fundraising are tracked manually via a spreadsheet. Attendance can be tallied manually or via a QR code (through QFlow). UT Foundation has access to an iModules Check-in App, which is not currently being utilized. Attendance reports are forwarded to the Central IT Office, where they are entered into ANDI to track alumni engagement scores. After events, attendees receive email communications with surveys and event information such as fundraising results, webinar recordings or picture galleries.
Opportunities
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Data Retrieval
- Data retrieval can be labor and time intensive because adjusting parameters to augment event invitee lists can be a complex process. As an example, generating the football tailgate event invitee list can take the entire summer to complete due to the number of changes that may need to be made before the list is finalized.
- The complexity in the data retrieval process can force the Central IT Office to make decisions about parameters that should be made by Alumni Office staff.
- The process of generating lists could be improved with the addition of the ability to see a preview of a list before the list is generated.
- The data retrieval process would benefit from a simpler reporting tool that would allow Alumni Office staff to easily pull and manipulate lists to their needs.
- The accuracy of the list depends on the data in ANDI, which sometimes lags due to when updates to student records are added. One result of the lag is an inability to pull an accurate list of alumni until graduates are loaded in July or August.
- Lists can become outdated by the time event communication is executed because the list information does not represent real-time data
- Not all data is stored in ANDI; invitee lists can be a compilation of ANDI data, as well as data from other sources or systems.
2. Event/Project Management and Tracking
- Currently there is no standardized process for planning events, with some planning being managed via Excel spreadsheets and some offices using software, such as “Monday.”
- Attendance and fundraising are usually tracked manually, via Excel
- Currently ANDI’s Event Module is used for attendance tracking, which then helps generate alumni engagement scores.
- The event planning process budgeting, ROI, and other types of event reporting are generated externally using the data from spreadsheets managed manually.System limitations include minimal functionality surrounding package pricing and the difficulty in distinguishing charitable and non-charitable portions of event registrations.
- The process would benefit from a more robust system for attaching appeal codes and the ability see accounting of all the methods of fundraising (online giving and gifts received in-person) for an event in one place in the system.
- Guests of attendees are not easily tracked.
- Tagging/coding events would help in searching for event data within the CRM and would help in building entity interest profiles and generating lists for future events.
3. Reporting, Analytics and Automation
- Insights might increase alumni engagement if events that might be of interest for an alumni could be suggested to them instead of depending on the scope of list parameters.
- There is limited reporting around event registrants. It would be helpful for development officers who attend events to receive reports with more robust information about donors prior to the event. Generally, establishing and displaying event metrics is an area of opportunity.
- The ability to build robust entity profiles especially for VIPs improving on the Entity Profile Report.
Event planning would be improved with a more robust communication system, including the ability to map communications on a constituent journey and the ability to automate reminder emails and SMS (currently only UT-Knoxville uses text reminders through the Mongoose/Cadence system). - Insights/Automated follow-up is an area of opportunity, especially for prospective registrants that abandon registration forms. Follow up on abandoned registration forms is currently a manual process.
Final Summary
The analysis shows that the current process possesses inefficiencies focused on standardization of data retrieval processes, availability of audience information, lack of analytical/reporting functionality, manual event/project management. Standardization and simplification of the data retrieval processes would produce consistency and reliability of data. Currently, queries must be run to generate lists, and there is no way to preview a list before it is generated. The process of running SQL queries makes the current process of generating a list complicated and time-consuming. The ability to preview a list would help save time during the list generation process. In addition, non-alumni donor opportunities are lost because ANDI does not house data on non-alumni donors, and it is difficult to track attendance for guests of alumni.
Additionally, data retrieved for lists lags behind real-time updates made in the system, so that entity information may become obsolete between the time the data is generated and the actual send-date of communications. Having comprehensive, centralized, real-time data in Salesforce will eliminate the time lag that may impact planning timelines and improve the accuracy of lists used in communications. Centralization could also limit the dependency on other systems to house data needed to generate a list. Lastly, the data retrieval process could benefit from discharging the data retrieval process duties from the Central IT Office and instead allowing campus Alumni Office staff members to retrieve lists.
Allowing alumni staff to generate lists would ensure that lists are generated, and parameters are manipulated to retrieve data in a more intentional way.
It would be more beneficial to centralize the planning steps and management of events in one system instead of using multiple systems and vendors to manage planning and execution. Presently, Excel spreadsheets, external project management software and other vendors (i.e., QFlow and Social Tables) are utilized to manage various elements of the event planning and execution process. Centrally, managing and tracking various elements such as planning timelines, event budgets, event action plans, attendance, fundraising and return on investment will make accounting easier, and create a more seamless and connected event management process. Moreover, the ability to separate gifts from the non- charitable portion of an event is an area of opportunity to be addressed in the future state. Additionally, it can be difficult to establish package pricing for events regarding alumni affiliation or discounts owed to various registrants at the point of registration.
Improved automation, analytics and audience insight would provide more accurate constituent targeting, personalized event suggestions for alumni, and more robust event metrics. Currently, there is limited reporting functionality in ANDI, reducing the amount of information available to development officers attending events with important faculty, staff, and alumni. More robust reporting would not only make it easier to help development officers identify and connect with VIPs and attendees, but analytical insights, engagement and event metrics could help identify the best methods of communication and improve the cadence of communications sent to alumni. Furthermore, the ability to create tags for events could assist in the ability to search for events, build entity interest profiles and improve constituent journeys.
Automation would also reduce the time spent reaching out to registrants that have abandoned registration forms. Automated reminder emails and SMS messaging would improve engagement during the registration process.
Gifts
Process Overview
The lifecycle of a gift includes the following stakeholders:
- Development officers
- Administrative assistants
- Business office
- Advancement Services
- Donors
The lifecycle of a gift begins when a donor decides to make a gift. Gifts can be made through various means, such as checks, online credit card transactions, cash, wires, payroll deduction, ACH, stock, and many others. Outright gifts of $25,000 or more are typically documented in a gift agreement. Stock gifts are routed through a broker. Gifts that are received in locations other than the Central Services office are documented on a gift transmittal form. Online gifts are collected through a payment processor and a batch is generated for processing. Certain gift types such as stock gifts require additional research to determine the donor’s identity, or the desired designation of the funds.
Once the constituent management team receives the gift, the gift is entered into ANDI through a batch. Transactions are often verified by members of the constituent management team to ensure accuracy. As the gift is entered, it is coded in the appropriate manner to indicate tender type, allocation, and other pertinent details. If the gift is split between spouses, made on-behalf/in honor/in memory of others, special steps must be taken as the gift is entered. All documentation, including checks, are manually scanned for our document repository.
Once the batch is closed, an in-house process runs overnight that posts each gift to the appropriate records in ANDI. Currently, gifts physically received at each campus office are processed at that respective campus, and all online and specialized transactions are processed at the Central Services office.
After a gift is posted in ANDI, a receipt is generated. For donors with valid email addresses (and who have not opted out), e-receipts are emailed. For other donors, receipts are printed and physically mailed. A file is generated to the bank once the deposit is completed the following morning to get the funds deposited in IRIS.
Reports are generated on a regular schedule based on college/unit needs for stewardship.
Opportunities
Improvement opportunities to address current inefficiencies:
1. Gifts with no Coupons
- We run into issues when gifts come in with no coupons
- Research as to be done to determine where the gift goes. The DO often has to be called, and sometimes the donor. This takes time and slows other processes.
2. Receipting
- Generating duplicate receipts is a painful process
- DOs often have to call and request receipts for donors who lost theirs or didn’t receive one. Constituent management has to rerun these, slowing other processes.
- Ideally, DOs could run their own, or perhaps have receipting available in the constituent portal
3. Online Giving
- Not all entities are loaded in iModules.
- John Doe transactions – ID is not in iModules and has to be researched
- Company credit cards – not sure who gift is for
- Other funds not listed – has improved but still an occasional pain point
- Donors making an online gift in response to a direct mail appeal – online appeal code gets assigned
4. Anonymous
- Anonymous gifts can be sometimes difficult to track and process. We would like to see a better and more efficient process for true anonymous gifts, anonymous donors, anonymous organization gifts, non-publicized gifts, etc.
5. Miscellaneous Processing
- Splitting credit between spouses is a manual process and can be improved
- Splitting credit between allocations should be less time consuming
- Payroll deduction: open to overhauling completely. Right now, the process to have a reoccurring payroll deduction and a one-time payroll deduction is a very manual, tedious, and time-consuming process.
- Quid pro quo transactions (i.e. event registrations with a gift component) are very difficult to manage. Especially when there are different price tiers for attendees of the same event.
6. Scanning
- Currently, we have to scan each check twice: once for the bank, and once for ANDI. We would like to reduce that to one scan.
- We would love to see less scanning if possible, and perhaps a remote check capture function for DOs.
7. Gifts from Other Departments
- Athletics and WUOT giving information comes over in an Excel file. We need a better process for this
8. Miscellaneous Pain Points (that may not be able to be addressed)
- Stock gift donor identities and other info
- DAFs – everything about recording them, receiving them, tracking them, etc.
- Payroll deduction checks from outside entities, such as UT Medical Center
- Researching whether a check should be a gift or a pledge payment
Final Summary
The lifecycle of a gift is a fluid process with unique situations depending on the type of gift, donor, designation, and time of year. Currently, some units use electronic gift transmittal forms, others use paper, and some gifts come in without any forms. This creates research and manual work for the team. There is also additional research by multiple parties when a coupon is not included, and/or a designation is not specified. Online giving can be hampered when donors choose other funds other than what is listed on the giving form. Also, not all donors are in Encompass, which can cause problems when trying to post online batches.
A smoother process is also needed in regards to anonymous gifts and related transactions, as well as the process of splitting transactions and credit. Currently, the payroll deduction process is limited, and recording a one-time payroll deduction when a reoccurring payroll deduction is already in place is a pain point. Quid pro quo transactions are also difficult to deal with. A nightly process runs to post batches in ANDI and the financial interface. Ideally, gifts would be posted in a more timely manner.
Pulling duplicate receipts can be a headache and cause time delays on other processes. Currently, a member of the constituent management team has to pull these receipts. We would love for a DO to be able to do this accurately, or perhaps even a donor within their donor portal profile. The constituent management team would also benefit from improvements in the scanning and document management process, including a reduction of the number of documents scanned.
The constituent management team faces other pain points with stock gifts, donor advised/directed funds, external payroll deduction (UT Medical Center), reconciling gifts with WUOT and Athletics, and also determining if a gift should be recorded as a gift or pledge payment in certain situations. The new CRM needs to address the aforementioned issues and provide alternative solutions to the current pain points in the lifecycle of a gift, which will also go hand-in-hand with many of the current roadblocks in the lifecycle of a pledge.
Pledges
Process Overview
The lifecycle of a pledge includes the following stakeholders:
- Development Officers
- Constituent Management Department
- Donors
The Constituent Management Department is notified about new pledges through pledge forms or electronic gift agreements. If a pledge amount is below $25,000, a pledge form is completed. If the amount is $25,000 or more, it must be documented in a gift agreement. Once the Constituent Management team receives either a pledge form or gift agreement, the pledge is entered into ANDI through a batch.
A report is run weekly to generate a list of pledge reminders. The report is checked against data in ANDI to determine if a pledge reminder is due to be sent out to the donor. Once this list has been reviewed, pledge reminders are sent to donors who have requested to receive them. Some donors have indicated they do not want to receive reminders. Usually, these preferences require manual management and Constituent Management staff may reach out to the primary Development Officers to determine how reminders/notification should be addressed.
A pledge’s status may change depending on donor activity. If a donor decides to cancel a pledge, he or she may reach out to indicate the cancellation. The pledge must then be manually updated with a status of “Canceled”. The Constituent Management office sends a report of unpaid pledges to be reviewed by the Vice Chancellor to determine if the pledge is to be written off, or if the primary Development Officer should be assigned to complete outreach to the donor. The Vice Chancellor has the final authority to write off a pledge. If a pledge is paid, its status is automatically updated to “Paid”.
Once a pledge payment is made, a gift receipt is produced and sent to the donor. If a donor makes multiple payments at the same time, they will receive multiple receipts. When a donor makes an overpayment or multiple payments, the initial payment schedule is automatically updated to a custom payment schedule.
Opportunities
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Proposal Assignment
- Constituent management staff must assign the proposal number to a pledge. However, this can often times be missing or hard to find.
2. Payment Scheduling
- The system automatically generates a payment schedule based on the amount of the pledge and the life of the pledge. However, occurrences like over-payments can generate a custom schedule that is not easily managed.
- It is difficult to facilitate payments that come in before the pledge is set up in the system
- Ideally, the system would have the ability to apply an overpayment to the overall pledge amount, thus lowering the amount of each installment but not changing the schedule. Another option would be to adjust the total number of payments. In the future, the Foundation would benefit from such flexibility.
- Staff need the ability to designate if a pledge payment is an outright gift, depending on donor intent.
3. Reminders & Receipts
- The process of determining which donors should receive reminders is report-driven and requires manual management; this process would be improved through automation.
- Unable to easily track in a report which donors do not want to receive pledge reminders. Special handling and custom notification processes for donors who do not want reminders is managed with the help of Development Officers and spreadsheets.
- Need the ability to combine receipts for donors who make pledge payments and gifts at the same time.
4. Reporting and Metrics
- There are currently limited dashboards, reports and metrics surrounding pledge fulfillment.
- Email reports are cumbersome; dashboards would help make reporting more readily accessible and easy for staff to utilize.
Final Summary
The process of entering in a pledge is complicated by system limitations surrounding payment scheduling, assigning proposal ID numbers, generating reminders and receipting, and a lack of well-established metrics. Assigning proposal ID numbers can often require research, which can be time-consuming. One major pain point in the pledge process is that the system does not adjust well to donor behavior. If a donor overpays a pledge payment, there needs to be a way to apply the overpayment to the overall pledge, thus reducing the amount due for each installment and keeping the schedule intact.
Currently if a donor over-pays, pays toward future payments, or pays before a pledge is entered, the system defaults to a custom schedule. The custom schedule may impact the ability to remind donors of pledge payments or require manual work to correct the schedule. Constituent management staff would benefit from a system that can accommodate these donor behaviors and provide consistency.
Generating reminders is a manual process. Presently, once the reminder report is received, it must be manually checked against ANDI to ensure its accuracy and avoid sending reminders in the case that a pledge payment was processed as a gift. The process of generating reminders is further complicated by instances of donors who do not want to receive reminders but still would like to be notified of impending payments.
The process will benefit from a CRM that can automate reminders and manage preferences and service indicators to exercise control of automated actions. In this way they will be able to benefit from the ease of automation and reduced manual reviews while still maintaining donor relationships that require special handling. The donor experience is further impacted negatively when they receive multiple receipts when making more than one payment at the same time. Concerning donor preferences, donors will benefit from the ability to receive combined receipts for pledge payments and gifts. Lastly, the current system does not provide robust metrics related to pledge activity. The new CRM will provide the ability to track metrics such as pledge fulfillment, allowing more transparency and the ability to use data to adapt and take actions to meet goals.
Future State Process Overview
The Constituent Management department will be notified when pledges are established; pledges will either be established by the donor while working with a development officer or by making the pledge directly online. For pledges over $25,000 a gift agreement will be completed, and for pledges under $25,000, a pledge form will be completed, all housed in Salesforce. Once the Constituent Management is notified of the pledge information, the data will be entered in a batch to be processed, which will save the pledge information to the constituent’s record.
A report, housed in Salesforce, will run weekly to generate a list of pledge reminders. The report will be updated in real time and segregate out any donors who have requested that no reminders be sent. The reminder report will be available to internal stakeholders wanting to review the information, via shared reports, dashboards, or scheduled to be delivered via email. Pledge reminders will be automated to be sent to donors who have requested to receive them. Development officers will use the report of donors declining reminders to conduct appropriate outreach to drive the payment of pledges.
A pledge’s status may continue to change depending on donor activity; if a donor decides to cancel a pledge, he or she will reach out to indicate the cancellation. The pledge will be manually updated with a status of “Canceled.” Unpaid pledges will be captured on a report available to the Vice Chancellor who will continue to have the final authority to write off a pledge or assign development officers to outreach tasks. If a pledge is paid, its status will be automatically updated to “Paid” and the transaction will be related to the pledge.
Once a pledge payment is made, a gift receipt will be produced and sent to the donor. If a donor makes multiple payments at the same time, a combined receipt will be issued, detailing all the payments. When a donor makes an overpayment or multiple payments, staff will determine whether to apply the overpayment to the overall pledge amount (keeping the payment schedule intact and reducing the amount of each payment) or applying the overpayment to the upcoming payments, thus reducing the number of outstanding installments.
In the future, pledges will be easily adjusted to meet donor needs/changes and the appropriate tracking of those adjustments will be kept in the system.
Key changes
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Proposal Assignment
- In the current state, constituent management staff must assign the proposal number to a pledge.
- In the future state, proposals will be easily associated with pledges.
2. Payment Scheduling
- Currently, the system automatically generates a payment schedule based on the amount of the pledge and the life of the pledge, but over-payments can generate a custom schedule that is not easily managed.
- In the future state, staff will have the ability to apply over payments to the overall pledge amount without changing the schedule
- Presently, staff need the ability to designate if a pledge payment is an outright gift, depending on donor intent.
- In the future, staff will be able to designate if a payment is an outright gift or pledge payment.
3. Reminders & Receipts
- In the current state, the process of determining which donors should receive reminders is report-driven and requires manual management.
- In the future state, reminder preferences will be managed by automation, with Salesforce housing preferences and segregating them into separate reports that inform communication activity.
- In the current state, constituent management staff need the ability to combine receipts for donors who make pledge payments and gifts at the same time.
- Salesforce will offer the ability to combine receipts for payment and gifts.
4. Reporting and Metrics
- There are currently limited dashboards, reports and metrics surrounding pledge fulfillment.
- In the future state, reports and metrics will be housed in Salesforce; dashboards will be readily accessible and easy for staff to utilize.
Considerations
- What pledge information do you want to be visible to donors when they log in to the constituent portal? What actions should donors be able to take related to pledges?
- Who should be able to adjust a pledge amount, payment schedule? Is there a need to a process flow to request an adjustment to a pledge?
- What reporting capabilities would campuses and the foundation like to see related to pledges? Are there certain reports that will allow for driving towards higher pledge fulfillment?
Final Summary
The future process of entering and maintaining pledges will remedy many of the complications in the current system surrounding payment scheduling, assigning proposal ID numbers, generating reminders and receipting, and a lack of well- established metrics. Proposal ID numbers will be attached to pledges automatically. When a donor overpays a pledge payment, staff will have the ability to apply the overpayment to the overall pledge amount, reducing the amount due for each installment and keeping the schedule intact. This will reduce the amount of manual effort expended to manage payment schedules.
Generating reminders will become an automated process. In the future, a reminder report will be maintained in Salesforce and will be available for weekly distribution to internal stakeholders. Another report will also indicate which donors do not want to receive reminders, even though they have payments due. The reminders will be segmented to ensure only the donors who have requested reminders will receive them. Salesforce will automate reminders and manage preferences and service indicators to exercise control of automated actions. In this way, Salesforce will provide the benefit of automation and reduce manual reviews. The report capturing donors who do not want reminders will be shared with Development Officers to facilitate special handling. Donors will also benefit from the ability to receive combined receipts for pledge payments and gifts. The new CRM will provide the ability to track metrics such as pledge fulfillment, allowing more transparency and the ability to use data to adapt and take actions to meet goals.
Proposals
Process Overview
The lifecycle of a pledge includes the following stakeholders:
- Development Officers
- Prospect Development Department
To enter a proposal, current policy requires that the constituent record be assigned to the development officer entering the proposal. There is an automated process to check entries and manage proposal statuses, but management of proposals (checking them for completeness) is a manual process completed by the prospect development office. If the record is not assigned to the development officer entering the proposal, he or she can request assignment through the ANDI system through the entity record. After the entity record is assigned, the proposal can be added to the record. Proposals require the following information:
- Title
- School/Campus
- Status
- Type
- Expected Close Date
Opportunities
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Roll Up Functionality
- The ability to add proposals to subsidiary records of corporate entities is lacking.
- Family hierarchy functionality would allow the ability to track giving for multiple members of the same family.
2. Electronic Gift Agreement Functionality
- Currently the ability to edit agreements is limited and would benefit from the ability to edit appropriate areas of the document.
3. Connectivity in the Solicitation Process
- The process would benefit from the ability to connect contact reports to proposals.
- The ability to connect alumni affairs and stewardship details to proposals would be a benefit.
- Prospect development would like the ability to attach gift transactions directly to the proposal as the current process of connecting gifts to a proposal is time intensive.
- Staff would benefit from the ability to connect potential influencers or other involved parties (e.g., financial advisors) to proposals.
4. Proposal Statuses
- Currently, not all proposal statuses are used, limiting the ability to optimally track proposal progress.
- Current proposal statuses do not fully identify the true stage of a proposal (e.g., “in preparation” status) Staff may have the opportunity for higher resolution view of proposal progress by reexamining standard proposal stages.
5. Proposal Assignment
- Staff would like more flexibility in the proposal assignment process.
6. Proposal Allocations
- Without the ability to easily split and share credit, development officers enter more proposals than necessary when a donor intends to give to multiple campuses/areas.
- Splitting allocation would also provide a better system for crediting development officers instead of development officers unnecessarily creating multiple proposals.
7. Increased Controls
- Standard processes around time to withdraw a proposal across campuses would allow more efficient tracking of proposal status.
Final Summary
The analysis shows that the current process possesses inefficiencies related to the reliance on manual processes, due to a lack of standardized operating procedures in proposal statuses, documentation, system functionality and ability to connect elements of the solicitation process. Currently, all proposal statuses are not fully utilized, and statuses are not fully reflective of the nuances of the proposal lifecycle, making it harder to succinctly track the progress of a proposal. In addition, proposals can be managed via gift agreement or manually. The manual management of proposals can create issues with documentation.
Proposals can be funded with a supporting verbal agreement, email or an EGA but proposals not managed by an EGA can require time-intensive research and/or status rollbacks. Time-intensive research could be remedied by standardizing the proposal management process i.e., requiring documentation before proposal reaches funded status, and/or attaching contact reports to all proposals. Next, there are limits in ANDI’s functionality: limited ability to facilitate annual giving proposals, limited ability to track giving for multiple members of the same family, and difficulty in adding proposals to corporate subsidiaries. Lastly, the system could be improved by allowing for a more seamless connection of elements of the solicitation process. Improvements would manifest in the ability to connect contact reports to proposals, the ability to track alumni affairs and stewardship details on proposals, and the ability to attach gift transactions directly to proposals.
Future State Process Overview
Development officers will create a proposal in Salesforce, and at that point, they will be able to assign a proposal team to reflect the parties that may be involved in various capacities of the proposal. Here, the primary driver of the proposal can indicate the information necessary to track the preparation of the ask and provide the information needed for planning and reporting. When the development officer presents the ask to the prospect, the he or she will mark the proposal as submitted.
Proposals that have been created, but not submitted to the prospect, will be reviewed regularly to ensure the development officer has all the support and information needed to present the ask. The proposal can be revised any time during the proposal lifecycle and changes appropriately tracked. If the development officer learns that the donor does not have an intent to give, the proposal is marked withdrawn.
In the future state, proposals submitted to donors will ideally have a gift agreement/pledge form associated with the proposal; the gift agreement/pledge form will have been generated by information housed on the proposal record, yet it will be editable where appropriate by the development officer. Gift agreements and pledge forms will be accessible from the donor’s record and associated to the proposal and future gift/pledge. If the donor agrees to fund the proposal, the proposal is will be marked with a status of “closed/won” or equivalent in Salesforce to indicate that the donor has confirmed a desire to give.
When the gift is processed by the Constituent Management team, the proposal status is automatically updated to “funded.”
Key Changes
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Roll Up Functionality
- Currently the ability to add proposals to subsidiary records of corporate entities is lacking.
- In the future state, development staff will have the ability to add proposals to any organization or subsidiary. Salesforce roll-up functionality will allow for viewing action taken on the subsidiaries on parent records.
- Currently, family hierarchy functionality is limited and does not allow the ability to track giving for multiple members of the same family.
- In the future state, staff will be able to manage family hierarchies and track giving for multiple members or units of a family.
2. Electronic Gift Agreement Functionality
- Currently the ability to edit agreements is limited and development staff would benefit from the ability to edit appropriate areas of the document.
- In the future state, staff will have more flexibility to edit gift agreements, where appropriate.
3. Connectivity in the Solicitation Process
- Currently, contact reports are not connected to proposals.
- In the future state, staff will have the ability to connect contact reports to proposals.
- In the current state, the ability to connect alumni affairs and stewardship details to proposals does not exist
- In the future state, staff will be able to connect appropriate stakeholders to proposals including alumni affairs, stewardship and potential advisors or other involved parties.
- Currently, Prospect Development cannot attach gift transactions directly to the proposal.
- The future state will require less time-intensive effort as staff will be able to connect gift transactions to proposals.
4. Proposal Statuses
- Currently, not all proposal statuses are used, limiting the ability to optimally track proposal progress.
- Future state functionality will allow for updated statuses to improve proposal tracking.
5. Proposal Assignment
- ‘Currently, there is limited flexibility regarding proposal assignment, as a record must be assigned to a development officer to establish a proposal.
- In the future state, development officers will be able to establish proposals without requiring constituent records to be directly assigned to them, if appropriate.
6. Proposal Allocations
- In the current system, development officers find it difficult to easily split and share credit, entering more proposals than necessary when a donor intends to give to multiple campuses/areas.
- In Salesforce, splitting allocation will provide a better system for crediting development officers and tracking giving to various units when gifts are directed to multiple areas.
7. Increased Controls
- Currently there are not standardized processes around the amount of time needed to pass before marking a proposal as “withdrawn.”
- In the future system, standardizing the process of withdrawing proposals, will allow efficient tracking of proposal statuses.
Considerations
- What data or actions are required at each stage of a proposal?
- How would you like to indicate when a proposal is closed vs. funded?
- Where would you like to track proposals? On the individual constituent or at the household level?
- How would you like to associate actions with proposals? Constituent actions? Development officer actions? Campaigns?
- What reporting needs do you have to have robust understanding of asks in flight and expected gifts within and across portfolios?
- What reports will help drive efficiencies in the proposal process from a managerial perspective?
- How are proposals tied to development officer metrics?
Final Summary
Currently, all proposal statuses are not fully utilized, and statuses are not fully reflective of the nuances of the proposal lifecycle, making it harder to succinctly track the progress of a proposal. Staff may have the opportunity for higher resolution view of proposal progress by utilizing the new proposal stages.
Additionally, proposals will be managed via gift agreement or pledge forms in Salesforce, erasing the need to manually manage proposals and reducing documentation issues. The ability to easily connect documentation like contact reports to proposals will reduce the current time-intensive research and status rollbacks.
UT Foundation will benefit from the ability to facilitate annual giving proposals, track giving for multiple members of the same family, and utlize rollup functionality that allows adding proposals to corporate subsidiaries. Overall, the system will seamlessly connect all elements of the solicitation process including the ability to connect alumni affairs and stewardship details on proposals, and the ability to attach gift transactions directly to proposals.
Prospect Management
Process Overview
When a development officer identifies a prospect (mostly major gift, although some annual giving officers do have prospect assignments) they wish to cultivate, they submit an assignment request. All assignment requests are completed by the Prospect Development (PD) team. Currently, one PD staff member completes assignment requests, and one staff member serves as backup.
Prospect Management is tracked in ANDI through the creation of prospect records and prospect assignments. A prospect record is attached to an entity record but can include multiple entities. Once the prospect record is created, prospect assignments can be added. Prospect assignments designate development staff who will work to cultivate the prospect, so they are typically major gift officers. There is one primary assignment on each prospect record, and there can be one or more secondary assignments. Once a prospect assignment is created, that prospect is then part of the development officer’s portfolio. Prospect records are required for the creation of proposals.
Assignment requests are submitted in ANDI. Any required documentation or written permission for the assignment is sent to the Prospect Development email account. To initiate the request, the development staff selects the “Add/Remove Assignment Request” button on the entity record. An assignment request is automatically generated. From there, the development staff can add additional details to the request where it is housed on the “Next Steps” screen. Once submitted, a PD staff member receives the request on their home screen in ANDI. After checking that appropriate permissions have been granted where necessary, the PD staff can add the assignment. If the entity does not yet have a prospect record, they create the prospect record and link any additional entities. Then, they add the prospect assignments. Once all data has been added or updated, the request is marked complete on the Next Steps screen. The PD staff then sends an email to the development officer stating the request is complete.
There are pain points for both development staff and prospect development staff in this process. Documentation of permission for prospect assignments is required to make any changes or additions to an existing prospect record. However, this documentation cannot be submitted in the system. So, even though prospect assignments can be requested in ANDI, the process requires additional email communication. There is also no way to confirm in the system that the request is complete, so email notification is also required to finish the process.
Portfolio reviews are conducted on a unit-by-unit basis by PD staff. These reviews are usually conducted by sending an Excel file of all assignments, stages, and visit dates to the development officer. The development officer sends the spreadsheet back with any requested changes, and the PD staff makes the updates. The only way for a development officer to view their portfolio is to pull an excel report from ANDI or to open the staff metrics dashboard.
Prospect stages are used to note where the prospect is in their relationship with UT development. Some prospect stage changes are automated. When a contact report is entered, the prospect is moved to “cultivation.” When a proposal is entered, the prospect is moved to “solicitation.” If a proposal is funded, the prospect is moved to “stewardship.” However, most development staff indicate that they prefer manual changes to the prospect stage.
Opportunities
In-System Workflow & Communication: When a development officer is requesting an assignment to an existing prospect, allow for a workflow that prompts the current primary assignment to approve the secondary assignment or changes to the prospect. Once the primary assignment has approved the changes, prospect development will then be alerted to make the updates. Development officers could also send messages directly that could serve as a paper trail or permissions for documentation purposes.
Prospect Update Timeline: Allow for a historic record of changes on the prospect record. Have a separate section where current managers can see the updates made to a prospect over time. This will allow them a better understanding of the relationship the prospect has had with UT.
Prospect Management Workspace: development staff would like to be able to view their entire portfolio on a single screen that would include pertinent information such as assignment status (primary, secondary), stage, active proposals, visit dates, next steps, etc. They could easily sort and filter their portfolio by these criteria. They could also submit update requests directly from this screen (changes to stage, changes to assignments, etc.)
Complex and Personalized Portfolio Segmentation: Allow development staff to create their own “segments” in their portfolio. This would allow the development staff to view their portfolio in customized groups according to criteria that is valuable to their own workload (businesses vs. Individuals, proposals to be delivered this FY vs. those not being solicited this year, prospects that might support a specific initiative, etc.). This would avoid having to create special codes so different units can pull special lists of prospects.
Suspect Lists/Pools: PRM spends time validating and researching potential development suspects. Create an easily accessible list of validated suspects that can be pushed to relevant development staff. This pool could also include individuals that have positive changes in their wealth screening or engagement scores. These individuals could automatically be flagged for attention by unit.
Improve Prospect Record Coding: Remove the active/inactive designation on prospects – this will be determined by an active prospect assignment. Remove the start dates and stop dates – this will be noted in historical changes to the prospect record. There is no need to continue coding prospects as “multiple” or “single” (to denote number of associated entities). There is no need to code every prospect by campaign code (which is currently just used to denote fiscal year). Streamline the prospect record to only include the most important data. Allow development staff to use the segmentation feature to categorize prospects in their own portfolio.
Prospect Disqualification: Sometimes prospects are completely disqualified, but it can be difficult to find the reason since it might be buried on the entity record. Allow for more descriptive coding when a prospect is disqualified.
Mass Prospect Transfers & Updates: It is difficult to move a prospect portfolio from one assigned DO to another. All changes must be made manually, one record at a time. Allow for access at the PD staff level to modify assignments in a batch (either to inactivate, or to update assignment to a different development officer).
Prospect Data Pushes: Notify assigned development officers when a birthday is coming up, when a pledge payment is coming up/is overdue, when a change is made to their entity record (new employment, new address, etc.). It would be ideal for notifications to be pushed to the home page when updates are made on a shared prospect. This could include when someone visits a prospect, when a next step is entered, or when a proposal is entered. This will keep all development staff assigned to the prospect up to date on the prospect’s moves.
Giving Analysis: Provide a better overview of an entity’s giving, not just totals or allocations, but consecutive years of giving, areas of interest, day of giving participation, event giving, telefund pledges, payroll deduction or recurring pledges, and responses to solicitations.
Contact Report Drafts: Many DOs go on visits and want to be able to enter quick notes or voice memos in the system before returning to flesh out a contact report/next step. Allowing them to save this info in the system would streamline their process.
Constituent Photos: Include photos of prospects on their record.
Recognition Societies
- Central IT Office (Internal)
- UT Campus Departments (Internal)
- Constituents (External)
Opportunities
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
- Real-time Data Updates
- Membership updates occur only once per fiscal year
- Real-time updates would allow for more robust engagement activity planning (particularly with planning donor recognition events and updating the donor wall)
- Donors would see benefits of their society membership at an earlier stage
- Real-time data updates would meet constituent expectations (i.e., they expect to be treated as a member of a recognition society immediately upon making a donation)
- Data Centralization
- In the current state, not all recognition society data is tracked in ANDI; data not tracked in ANDI requires manual tracking on a spreadsheet
- Athletics has a separate tracking system for the Shareholders Society; it would be ideal to see membership for all recognition societies in one place
- Contact Reporting
- Contact reports and communication with constituents related to society membership (such as a welcome letter) are added to record manually; ideally this type of communication would be batch loaded or automatically added
- Streamlined Reporting
- Currently, reporting on recognition society membership is a very manual process; stakeholders will benefit from more robust, streamlined reporting capabilities, especially as the university moves toward the campaign launch in 2025
- Targeting/Tracking
- Not all recognition societies are tracked on a donor’s ANDI record; tracking giving toward membership levels would allow for more targeted solicitations
- Real-time tracking would allow for enhanced constituent experience
- Communications
- The current system does not have a donor portal containing recognition society details; ideally, donors would have access to a portal through which they could view all their society memberships and associated benefits
- Better tracking/targeting presents opportunities to create/improve campaigns and communication plans
- Automation
- Some campuses and departments have not created recognition societies (i.e., UTIA)
- A more robust system to track giving programs and stewardship activities would increase the feasibility of establishing and managing recognition societies
- Central IT Office (Internal)
- UT Campus Departments (Internal)
Key Changes
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:- Real-time Data Updates
- Currently, membership status updates are processed once per fiscal year due to the manual nature of managing membership. b. In the future state, Membership updates will occur automatically and in nearly real time.
- Data Centralization
- In the current state, not all recognition society data is tracked in ANDI; data not tracked in ANDI requires manual tracking on a spreadsheet
- In the future state, all recognition society data will be tracked in Salesforce. In addition to membership status, additional information can be managed in ascend such as Membership Levels, Membership Benefits, Membership Beneficiaries, and Membership Stewardess.
- Contact Reporting
- In the current state, contact reports and communication with constituents related to society membership are added to records manually
- In the future, contact reports and communication with constituents related to society membership (such as a welcome letter) will be connected to constituent records.
- Streamlined Reporting
- Currently, reporting on recognition society membership is a very manual process
- In the future, reports can be easily built, maintained, and easily shared with staff.
- Targeting/Tracking
- Currently, not all recognition societies are tracked on a donor’s ANDI record
- In the future, all recognition society membership information will be available and tracked on a donor’s record.
- Constituent Portal
- Presently, the system does not have a donor portal containing recognition society details
- The future state will include a donor portal for donor engagement membership management.
- Automation
- Currently, some campuses and departments have not created recognition societies,
- The future state will provide new, efficient functionality will make it easier to do so. (i.e., UTIA)
- A more robust system to track giving programs and stewardship activities would increase the feasibility of establishing and managing recognition societies.
Considerations
- How will you onboard recognition societies to Salesforce that are not currently tracked in ANDI?
- How will you manage the future recognition society creation process?
- What society/membership information would you like your constituents to be able to view and manage in a future constituent portal?
Core Impact Summary
The future state of this process addresses challenges in the current state with respect to manual processes, data centralization, reporting and communication. Automation solves the problem of manually tracking membership via Excel spreadsheets. Centralizing all giving information will ensure that donor records contain all giving data. This change will reduce the number of systems used by different advancement entities and improve contact reporting capability—allowing for better communication, targeting activities and donor engagement. Improved reporting capability will provide better tracking toward membership levels and the ability to easily and quickly share data with internal stakeholders. Additionally, as reporting and tracking capabilities are utilized, opportunities will expand to create and improve campaigns and communications plans.
Volunteer Management and Confidentiality Processes
Process Overview
Stakeholders:
- Development Staff (development officers, support staff, alumni programming, etc.)
- Central Advancement Services
- External Volunteers (alumni, donors, friends, etc.)
Volunteers are currently identified and engaged by different development staff across the system. Most volunteer relationships are generated based on personal relationships between alumni/donors and either development staff or academic faculty/staff. Based on that personal relationship, development staff determine if the alumni/donor would be interested in participating in a volunteer activity. Other volunteers are identified through referrals from existing volunteers.
Some volunteers are identified from data currently in the database, but this is mostly limited to broad classifications (ex. Reunion volunteers can be identified by class year). Campus career centers help identify professional volunteers that are willing to work with students or visit classrooms. Student activity data also helps identify potential volunteers. Student activity data in the CRM is limited and inconsistent. There is no guarantee that information will be connected to the alum’s entity record. Due to the lack of data that might indicate constituent interest in being a volunteer, it is difficult to find volunteers in the database through any standard query or report.
Volunteer activities can be recorded in ANDI, but that data is not always entered in the database. Many formal and informal volunteer activities are not added to the database by development staff. Factors that might prevent this data being entered in ANDI:
- Many development staff have not been encouraged to document these activities in the database – there is no incentive to track and enter this information.
- They might not know that these interactions with alumni/donors can be classified as a volunteer activity – there is no consistent, dedicated training for this process.
- The process of entering engagement data such as volunteer activities can be time consuming – users must request the volunteer code if it has not been created and then add the participation codes one by one to each entity record.
Opportunities
Volunteer Activity Interest Coding: Create ability in the CRM to record volunteer activity interest rather than just volunteer activity participation. Information about individuals who might be willing to participate in volunteer activities is currently not recorded. Rather than being lost in conversation or in a contact report, it would be ideal if development staff could record these interests directly in the CRM.
Actively Solicit Volunteer Interest: UT webpages or alumni portals could be used to post forms for alumni and donors to indicate volunteer activities in which they might be interested. This data could then be imported to the CRM to be used for identifying volunteers in the future.
Streamline Volunteer Management: Allow users to request volunteer codes directly in the system. Allow users to add volunteer codes to groups of records at one time.
ConnectUT: Use ConnectUT to identify professional specialties to drive volunteer identification. This is a new system that will provide valuable information.
Process Overview
Stakeholders:
- Development Staff (development officers, support staff, alumni programming, etc.)
- Central Advancement Services
- Faculty/Staff that receive data from the CRM
Many fundraising units use faculty and staff in the fundraising process. Some units share donor information with academic leadership to assist with the stewardship process. Some faculty members contact donors directly, while others write communication that is then sent centrally from the fundraising unit: for example, UTK TCE works with faculty but sends all communications centrally; UTM sends donor data to academic leaders to send out stewardship directly.
Some academic units request fundraising and financial information from development staff. This data can come from the CRM or IRIS (financial database). Other faculty and staff request lists of alumni for contact purposes. Currently, most automatic reports are sent to UTFI staff. However, there are some automatic reports generated for external faculty and staff.
Faculty and staff often work with alumni boards and advisory councils. There are many different types of boards: some recorded in the CRM, others are unofficial and not tracked. Some advisory boards or alumni councils participate in stewardship activities, sending thank you notes or other communication to alumni and donors.
Opportunities
Faculty/Staff Indicators: Add coding in the CRM to indicate whether a faculty or staff member is participating in stewardship or solicitation activities. Tracking faculty that participate in fundraising or receive CRM data would be useful for Advancement Services staff as well as in the onboarding process for fundraisers.
- Confidentiality forms are located at services.utfi.org.
- Click on the “Policies” link in the menu at the top. You will be asked to enter your net ID and password.
- Scroll to the bottom of the page. Confidentiality forms are located under “ANDI Security Forms” in the right column.
- “Data Confidentiality Agreement for UT Employee/Volunteer” should be used for non-foundation employees and volunteers. Click on the link to access the form.
- Under “Foundation Staff Information,” fill out your information and reason for requesting access for the employee or volunteer.
- Under “UT Employee/Volunteer Information,” enter information for the individual that needs to sign the agreement.
- The employee or volunteer will receive notification via email, so make sure the email is entered accurately.
- Confidentiality form indicators are now in ANDI. Make sure to enter the accurate ANDI ID number so that the indicator will display on the correct record.
- Once all of the information is entered, hit “Send.”
- The employee or volunteer will receive an email notification in order to complete the form.
- It is recommended to alert the employee or volunteer to expect an email from the “University of Tennessee Foundation – ANDI Help Desk.”
- These emails can sometimes end up in the individual’s spam folder. Let them know to check the spam folder if they do not find it in their inbox.
- Recipients will receive automatic reminder emails if they do not complete the form. The emails will be sent after two and four days.
- Once the employee or volunteer completes the form, Advancement Services will be notified to approve it. Once it is approved, both the foundation staff and the employee/volunteer will be notified by email.
- Any questions about what type of information can or should be shared with non-foundations staff should be directed to Advancement Services (email: [email protected]).
- Go to the individual’s ANDI record.
- On the entity overview, a “Confidentiality Form on File” indicator will appear under the “Update the Record” link if the individual has an active form on file.
- To find details about when the form was filled out or who requested it, open the “Biographic” menu from the left-side of the entity overview and select the “Comments” section.
- On this screen you will find the date that the confidentiality form was approved, the staff member that submitted the form (listed in the Description field), and the Advancement Services staff member that approved the form and activated the indicator (listed by Author ID).
- Confidentiality forms for employees and volunteers expire after one year.
Process Overview
Stakeholders:
- Development Staff (development officers, support staff, alumni programming, etc.)
- Central Advancement Services
- Volunteers (alumni, donors, friends, faculty, staff, etc.)
Once volunteers have signed a confidentiality agreement, development staff can share necessary data with them from the CRM. This can include alumni names, contact information, and donor status. Per UTFI policy, this data should be shared through the UT Vault system or through an encrypted email. However, that poses problems for some users. They are not always familiar with opening encrypted emails, and not every user has access to the vault. Additionally, there’s no way to remove access to a data file once it’s been shared and downloaded.
Opportunities
Shared Data Page: Volunteers cannot access the CRM directly, but it would be ideal if data could be shared through the CRM to avoid having to email or otherwise insecurely share this data. If development staff could establish a secure webpage or some other access method with the data they want to share, the volunteer could log in to view the information. Central Services would also then have more control over the data and would be able to “inactivate” the data once it was no longer necessary to share. The volunteer could also potentially share updates and information they obtain through fundraising activities on this page.