Staff Portal

CONTACT
1525 University Avenue
Knoxville, TN 37921
Main Telephone Line
(865) 974-2115
[email protected]

ANDI HELP
(865) 974-4153
[email protected]

Policies

Documentation

CRM: Bio Demo

The Compact View is a standard feature of the Salesforce interface that allows the user to get a quick snapshot of a constituent, household, or organization by hovering over a name. Each Compact View displays six pieces of key information. We have decided to use the following in ACE:

Constituent Compact View

  • Record Type
  • Household Name
  • Lifetime Giving
  • Preferred Email
  • Preferred Phone
  • Preferred Address


Household Compact View

  • Primary Constituent
  • Primary Relationship Manager
  • Stage of Readiness
  • Lifetime Giving
  • Most Recent Gift Amount
  • Most Recent Gift Designation


Organization Compact View

  • Organization
  • Record Type
  • Parent Record Name
  • Organization Hierarchy Level
  • Stage of Readiness
  • Primary Relationship Manager
  • Lifetime Giving

ANDI
In ANDI we have more than 40 Record Types, which includes both individual constituents (Alumni, Friend, Parent, etc.) and organizations (Corporation, Estate, Trust, etc.).

ACE
In ACE, Constituents and Organizations are separate object types. We have consolidated the list of Constituent Types to the following hierarchy:

  1. Alumni
  2. Resident/Intern
  3. Student
  4. Faculty/Staff
  5. Parent
  6. Grateful Patient
  7. Grateful Client
  8. Former Student
  9. Former Parent
  10. Friend
  11. Name Only


The hierarchy determines a constituent’s primary Constituent Type–for example, an alumnus (1) who is also a parent (5) would have a Primary Constituent Type of Alumni because Alumni is above Parent on the hierarchy.

NOTE: A constituent’s Primary Record Type in ANDI will be preserved in ACE for historical/research purposes.

ANDI
Numerous fields in ANDI have associated data source values.

ACE
A single Data Source global picklist will include all UT data sources, third-party vendors, and categories of manual changes. Having a single list will simplify managing sources and will also allow for cross-data reporting.

ANDI

  • Clipping Service (will no longer use)
  • Notified by a Family Member (will remain Notified by a Family Member)
  • Obituary (will remain Obituary)
  • University Staff (will remain University Staff)
  • Verbal and Unsubstantiated (will become University Staff)
  • Verified Other (will become Vendor Load)


ACE

  • Obituary
  • University Staff
  • Notified by a Family Member
  • Vendor Load

ANDI (Type / Status / Description)

  • PREFERRED Email / Active / Confirmed
  • Alternate Email Address / Bad Address – Do Not Use /  Permanent
  • eReceipts Email Address / Do not send receipts via Email / —

ACE (Type / Status)

  • Personal / Current
  • Other / Bad


Generally, we’re moving to Salesforce’s standard language of Current and Former to describe the status of much bio demo data.

  • Type: An email address is Personal if it belongs to the constituent; it is Other if it belongs to someone else–for example, the constituent’s accountant.
  • Status: An email address is Current if it is good/deliverable; it is Bad if it is undeliverable or if we know it doesn’t belong to the constituent. For example, John Doe’s email address, [email protected], would be marked Bad if we know it actually belongs to Jack Doe.
  • Preferred: Will now be handled with a checkbox. Every constituent who has at least one Current email address will have a Preferred address.
  • eReceipt: Will now be handled with a checkbox. Our new business processes will assume a constituent’s Current Preferred is their eReceipt address unless the eReceipt checkbox has been manually checked on another address. For example, if a constituent requests to have all receipts sent to a new accountant, we will add the accountant’s address as Current Other and check the eReceipt box.
  • Permanent: Used to prevent the overwriting of an address by any process. Will now be handled with a checkbox that can only be checked manually at the request of the constituent.
  • Valid/Verified: A Valid address is deliverable (regardless of where it’s delivered to); a Verified address has been confirmed as deliverable to the specific constituent. We don’t currently have mappable data for these fields in ACE so we will hide them until we develop strategies and business processes around them.

ANDI

  • Blank (will no longer be an option)
  • Female (will remain Female)
  • Male (will remain Male)
  • Unknown (will remain Unknown)

ACE

  • Female
  • Male
  • Non-Binary
  • Prefer Not to Disclose
  • Unknown

ANDI
~9,300 organization contacts exist in ANDI. Each is assigned a description such as Executive Vice President (EX) or General Corporate Contact (GC).

ACE
Organization contacts will be mapped as Name Only constituent types, with an employee/employer relationship to the org. The current ANDI description of the contact will become their Job Title in ACE if they don’t already have a job title.

This is a good use of the new Name Only constituent type, which will be used in ACE only when the “non-constituent constituent” has a relationship with an org or another constituent.

ANDI
~50 constituents have a Temporary or Part-Time (T) employment row.

ACE
Part-Time and Temporary will allow us to load all UT employees. Other uses will likely be discovered. Accurately loading all UT employees will improve reporting and segmentation strategy.

CRM: Resources

ACCOUNT — Record for an organization or a household in Ascend (replaces prospect record).

ACTION CENTER — Notification tool that displays a list of actions for a Primary Relationship Manager to take with their assigned accounts and households.

AFFILIATION — Relationship between a constituent and an organization. This can affect gift processing, Ex: Employee/Employer, Student/Educational Institution, or be utilized during prospecting to better understand interests, relationships, etc.

ASCEND — An application created by UC Innovation that leverages SalesForce for higher education advancement and constituent engagement.

CASES — Requests for updates or assistance submitted in Ascend. Cases are assigned to and worked by other users to help fulfill the request. Case types can include Support Request, Report Assistance, Update Request, and Prospect Research Request

CAMPAIGN — Allows users to create a static list of constituents that have received a touchpoint (an appeal, a newsletter, and stewardship piece, etc.)

CHATTER — Tool that allows users to collaborate and communicate directly or in a group with other users in Ascend.

COMPACT VIEW — The Compact View is a standard feature of the Salesforce interface that allows the user to get a quick snapshot of a constituent, household, or organization by hovering over a name. Each Compact View displays six pieces of key information.

CONFIRMED — Contact information in ACE is “confirmed” when we have determined it belongs to the constituent or organization it’s attached to. For example, if a development officer calls a prospect’s phone number and the prospect answers, the DO should mark that numbers as confirmed.

CONSTITUENT — Record for a person in Ascend (replaces entity record).

CONTACT REPORT — Report detailing any significant interaction with the constituent.

CUSTOM APPS — Group together a series of the most commonly used objects and provide for a customizable home screen that can include dashboards, reports, lists, tasks, or other standard or custom components. This helps users focus on specific functional areas without being distracted by data unrelated to their job function.

DESIGNATION — The department/unit/fund where a specific payment/pledge/gift will go (replaces allocation).

DESIGNATION BENEFICIARY — Recipient of the endowed funds – scholarship, professorship, chairmanship etc.

FUNDING INTEREST — Used to identify specific funding priorities for Accounts in Ascend.

GIVING DETAIL — Tracks specific transactions and pledges made by the constituent or account. Final state of a constituent or account’s gifts, pledges, and pledge payments.

GIVING SOCIETY — Memberships to school, college, and university wide associations using rule sets to determine the level of membership.

HOUSEHOLD — Object used to track development activities such as contact reports, opportunities, strategies, etc. in Ascend (replaces prospect record).

INTEREST — Things a constituent is interested in. This can include sports, clubs, centers, etc.

INVOLVEMENT — Activities, committees, volunteer activities the constituent or organization is involved with (replaces engagement factors).

LIGHTNING PAGES — Custom layouts that allow for pages to be customized to user specifications. Lightning pages can be thought of as page layouts with the ability to add lightning components, which allow much more flexibility.

LIST VIEW — Allows you to set filters to view records on an object tab (constituents, opportunities, etc.). List views can be customized and modified.

MEMBERSHIP BENEFIT — Benefits for giving societies, such as members-only invitation to events, wall recognition, campus parking, etc.

MEMBERSHIP LEVEL — Various levels defined for a giving society.

OBJECT — Data categories in Ascend (replaces database tables).

OPPORTUNITY — Object used to record proposals and gifts (replaces proposal).

PAGE LAYOUTS — Allow different users to see different information on the same record and allow users to see different information on different types of records (via field level security). This ensures that users only see what they are supposed to see, without additional access or extraneous information.

POST CODE — Majors, minor or specialties tied to a degree in Ascend.

RELATED LISTS — how relationships between records. They allow users to view records that are linked to the current record being viewed all on the same page. Related lists can be customized to include desired fields and the order for which they appear.

RELATIONSHIP — Connections between a constituent and another constituent that can affect gift processing. Ex: Child/Parent, Husband/Wife, Organization/Employee, Organization/Funder.

RELATIONSHIP MANAGER (PRIMARY or SECONDARY) — Individual assigned to cultivate and solicit a constituent or account. There is a single active PRM per household.

ROAD MAP — Ascend’s plans for future updates and functionality.

SALESFORCE — A customer relationship management (CRM) database.

SERVICE INDICATOR — Banner on a constituent record that is related to how to approach the constituent or account based on their preferences (replaces solicitation control codes, VIP codes, and other customized banners on the entity record).

STRATEGY — Documents any internal user’s strategy on how to approach/interact with the constituent/account during prospect management.

TASK — Actions assigned to users in Ascend.

VERIFIED — Contact information in ACE is “verified” when it is well-formed and deliverable. For example, if we send an email to an alumnus named John Doe at [email protected] and the message doesn’t bounce back, it is a verified address–even if the message is actually delivered to Jack Doe, who has no relationship with UT. We have scheduled processes that verify our data.

WORK PLAN — High level overview or goal metrics for a particular unit/division/school. This is what fundraisers/development officers are measured against per FY. It includes fundraising goals, # of visits/contact expectations.

What is the timeline? When will the new CRM go live?
February 2024. The timeline allows for pauses during days of giving, FYE and CYE reporting, and other major projects. The implementation will put significant new burdens on staff resources — many in Advancement Services will be dedicating 50% or more of their time to the project — but we’re fully committed to supporting essential fundraising, engagement, and advocacy efforts throughout the process.

How did we select Salesforce and Ascend?
The selection process was led by a CRM Evaluation Committee that represented every job area and every unit in the Foundation. We began with a comprehensive needs analysis involving interviews with 125 key stakeholders. The results of those conversations informed our Call for Proposals, which elicited responses from four vendors. After viewing more than 60 hours of online demos, the Evaluation Committee and the vast majority of respondents to our feedback survey identified a clear favorite in Salesforce and UC Innovation, whose application, Ascend, turns Salesforce into a university advancement tool.

How will the new ERP (Enterprise Resource Planning) system affect us?
Our CRM will go live before the new ERP, so we will build an integration with IRIS while also laying the groundwork for future integrations with Oracle. This is an exciting time for technology change at the University of Tennessee! In addition to our new CRM, the UT System has contracted with Oracle to replace IRIS, UT Knoxville is transitioning to Salesforce for its student experience CRM, and UT Knoxville athletics is moving to Ticketmaster. The core CRM team and Huron are collaborating closely with leaders of those projects, and we’re preparing for all potential scenarios.

Business Processes

Process Overview
Planning and execution of alumni events begins with individual campuses. Each campus’s Alumni Office controls planning.

  1. Campus Alumni Office (Internal)
  2. Central Advancement/Online Engagement Team (Internal)
  3. 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.

CRM event flow

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.

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:

  1. Central IT Office (Internal)
  2. UT Campuses (Internal)
  3. 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.

CRM event flow

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:

  1. Central IT Office (Internal)
  2. UT Campuses (Internal)
  3. 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.

CRM event flow

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:

  1. Central IT Office (Internal)
  2. UT Campuses (Internal)
  3. 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.

CRM flow diagram
CRM flow diagram

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:

  1. Constituents (External Communication)
  2. Development Staff (Internal Communication)
  3. 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.

CRM flow diagram

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.

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.

  1. UT Campus Departments (Internal)
  2. Central Advancement/Online Engagement Team (Internal)
  3. 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.

CRM flow diagram
CRM flow diagram

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

  1. What data would you like to use to drive segmentation in the future?
  2. Who will be able to create a communication campaign in the future? Who will create communication templates/content?
  3. What communication engagement information would you like visible directly on the constituent’s record?
  4. 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.

CRM flow diagram

Process Overview

Stakeholders:

  • Development Staff (development officers, support staff, alumni programming, etc.)
  • Central Advancement Services
  • Volunteers (alumni, donors, friends, faculty, staff, etc.

Before sharing any data with a volunteer (in this instance, defined as anyone that needs access to ANDI data but does not have direct access to the CRM), the volunteer must sign a data confidentiality agreement. The data confidentiality agreement was developed based on best practices and expectations in the field of data security, with involvement from the Chief Information Officer for UT and UT counsel.

The current form is filled out digitally using an electronic form created using vendor PerfectForms. The standard form is initiated by a development staff member that inputs their own contact information and the volunteer’s contact information. Once entered, an email notification is sent to the volunteer to read the terms of the agreement and digitally sign their name. The form is then sent to the User Experience team in Central Advancement Services to approve the confidentiality form. Once approved, the volunteer and the Foundation staff member are notified of the approval via email. Confidentiality agreements are valid for one year after signing for volunteers that receive data regularly. For volunteers that receive data for specific projects, development staff should initiate a confidentiality form for each project the volunteer is involved in.

Once the confidentiality form has been signed and approved, a User Experience staff member adds a row in the Comments field on the entity’s ANDI record. It contains the date the form was approved, the ID of the development staff member, and a description of the development unit name. Once entered, a “Confidentiality Form on File” indicator appears on the entity overview of that individual’s record. The indicator will remain on the record for one year after the date in the comment field. In the final month of that confidentiality agreement, an automatic report is run with a list of all records with expiring forms. An email notification with that list of individuals is sent to the relevant development staff to renew the form if necessary. Development staff members are responsible for keeping up with their own volunteers and the signing of confidentiality agreements.

The confidentiality form process was developed to ensure the Central Advancement Services office would know which development staff member was working with the volunteer, which is why development staff are required to initiate the confidentiality agreement. However, this is a time-consuming process that requires all information to be entered manually (name, title, campus/college/unit, email, and reason for initiating the form). There is no pre-fill option when a development staff is filling out multiple forms. Similarly, there is no ability to autofill a volunteer’s information (ANDI ID, name, email) on the form, so all that data must be looked up manually in the CRM.

The current vendor used for these forms does not allow the form initiator to view the status of their submitted forms. User Experience staff can see the status of the form, but other development staff can only go by email notifications. Emails are sent through the [email protected] email, but are initiated by the form vendor. Often, this causes emails to end up in a junk email folder or be flagged for quarantine by Microsoft Office. This can cause confusion for the volunteers and development staff.

Opportunities

In-System Confidentiality Form: Build a form that can be initiated directly in the CRM. Ideally, development staff would be able to initiate and track confidentiality forms using the CRM. They would be able to go to a donor record and select a button that would initiate a form pre-populated with their own information and the volunteer’s information. When the form is submitted, development staff have a space in the CRM to see where the form is submitted, signed, or approved. The form URL would be sent automatically to the volunteer to access the form, read the terms, and digitally sign the agreement.

Confidentiality Form Indicators: The confidentiality form indicator allows development staff to see at a glance if the individual has a form on file. The indicator should make it easy to view the reason the form was signed, which staff initiated it, and what date it was signed.

Automatic Expiration Notifications: Notification of signed agreement expiration should be initiated automatically in the system one month before the agreement expires. The entire process from start to finish should be initiated and managed in the CRM.

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.

Process Overview

The lifecycle of a gift includes the following stakeholders:

  1. Development officers
  2. Administrative assistants
  3. Business office
  4. Advancement Services
  5. 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.

CRM process gift flow diagram

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.

CRM pledge flow diagram

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

  1. 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?
  2. 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?
  3. 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.

CRM flow diagram

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

 

There can be multiple primary Development Officers assigned to an entity record. Along with close rates, the ability to have multiple development officers assigned in various roles helps leadership understand who is driving proposals and involvement on proposals is a factor in development officer metrics. Once the entity record is assigned and the proposal is created, the proposal enters the “submitted” status.
 
The intent to fund a proposal can be received via gift agreement, email, or verbal agreement. However, all gifts of $25,000 or more must be documented in a written gift agreement. If there is no intent to give established, over time, the proposal must be manually placed into “withdrawn” status. However, if a prospective donor has communicated the intent to give, the process varies based on if an electronic gift agreement was leveraged.
 
While electronic gift agreements are the preferred method, some development officers have more informal practices that are accommodated manually. If an electronic gift agreement is used, a gift agreement is generated via a custom application built on Adobe ColdFusion. The electronic gift agreement contains information from ANDI and manages the generation of the gift agreement and the signature process. If no gift agreement is used, the proposal is managed manually by the development officer.
 
If the donor declines to fund a proposal, the development officer must manually update the proposal status to “declined”. When a proposal is funded in ANDI via a gift transaction, the proposal status is automatically updated to “funded” based on the dollar amount being updated to reflect the funded amount. A nightly process runs to automatically mark as funded, withdrawn, or declined proposals as “closed.”
 
Prospect Development reviews funded proposals for accuracy of documentation. If a proposal does not have documentation attached, the Prospect Development team must contact the development officers to ensure that documentation exists. This process may require the DO to continue to work on the proposal, changing the status to withdrawn or, in cases where documentation can be provided, accepting the documentation, and attaching it to the proposal.
 
On occasion, a gift can be given without the existence of a proposal. In this case, a gift agreement is generated at the time of the gift and entered manually into ANDI.
 

CRM pledge flow diagram

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

  1. What data or actions are required at each stage of a proposal?
  2. How would you like to indicate when a proposal is closed vs. funded?
  3. Where would you like to track proposals? On the individual constituent or at the household level?
  4. How would you like to associate actions with proposals? Constituent actions? Development officer actions? Campaigns?
  5. What reporting needs do you have to have robust understanding of asks in flight and expected gifts within and across portfolios?
  6. What reports will help drive efficiencies in the proposal process from a managerial perspective?
  7. 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.

CRM process proposalflow diagram

Back to the top