Discovery Sessions
Individual Updates
Process Overview
Bio/demo data is manually updated on constituent records by constituent management staff, as well through update requests from development officers and administrative staff. It is common practice for departments outside of the constituent management department to designate a team member who is responsible to generate update requests. This practice is in place to limit duplication of effort and control for errors. The process of updating bio/demo information for individual records involves three stakeholder types:
- Central IT Office (Internal)
- UT Campuses (Internal)
- Vendors (External)
The process begins with one of three inputs that are categorized as internal or external. External information comes from constituents via email, voice notes, or documentation related to gifts. Internally, departments can submit updates to a specific set of data directly within ANDI for review and approval by constituent management staff or can send an email directly to the constituent management department. Data updates submitted through ANDI are limited to basic contact information, employment data and spouse details. Sending an email allows the requester to propose an update to any bio demo field.
Once information is received by the constituent management department, requests are collected in a queue. From the queue, records are evaluated individually via a manual review process. The information received is reviewed to determine if duplicate information exists in the system. If duplicate information or errors in the data exist, the requested update is denied and not entered in ANDI as an approved change/update. However, if duplicate information does not exist, the requested updated is entered and approved.
Opportunities
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Duplicate Records/Manual Review
- Currently the matching logic to look for duplicate records and duplicate data is not robust. A manual review process is necessary to ensure accuracy. Manual review is time intensive and possesses a higher risk of inaccuracy.
2. Limitations of System
- Currently users are only able to update select fields directly in ANDI. Ideally, they would have ability to update more than basic contact and biographical data.
- Fields such as prefix and gender are currently required due to system functionality, however this data is often not available. Ideally, fewer fields would be required when creating new records.
3. Joint Salutations
- Currently, the system does not create automatic joint salutations.
- There is currently no policy in place as to who should be listed first in a joint salutation.
4. Notifications
- There is currently no automated notification system for the approval, denial or completion of data update requests.
Final Summary
The analysis shows that the current process possesses inefficiencies that increase the effort and time needed to update records. Currently, this process meets intended objective, goals, and customer requirements but could benefit from the addition of automation and out-of-the box functionality delivered in implementation of the new CRM. UT Foundation can expect to benefit from increased speed of entry, reduced time and effort spent in manual processes, defined business processes for handling different types of constituent data, and transparency surrounding the approval, denial or completion of update requests.
Future State Process Overview
Bio/demo data will be manually updated on constituent records by constituent management staff, as well through updates submitted by development officers and administrative staff. The process of updating bio/demo information for individual records involves three stakeholder types:
- Constituents (External Communication)
- Development Staff (Internal Communication)
- UT Foundation Constituent Management Department (Internal Communication)
The process begins with one of three inputs that are categorized as internal or external. External information comes from constituents. In the future state, this will include information communicated via email, documentation related to gifts, or via updates made in the constituent portal. During implementation, Huron will partner with UT Foundation staff to establish matching logic to govern how the system handles duplicate and erroneous information. This matching logic will act as a point of data validation when staff members submit updates to constituent records so that duplicate data will not be entered into Salesforce.
Certain data will require manual review to maintain the Foundation’s expectation related to data integrity. These items will be reviewed directly in Salesforce and the appropriate action determined by Constituent Management staff.
Key Changes
During discussion about the process, several improvement opportunities to address inefficiencies in the current state surfaced. The points below indicate key future state changes:
1. Automation and Matching Logic
- Currently the matching logic to look for duplicate records and duplicate data is not robust. A manual review process is necessary to ensure accuracy. Manual review is time-intensive and possesses a higher risk of inaccuracy.
- In the future, only a small amount of critical information will be manually reviewed. This review will happen directly in Salesforce eliminating duplicate data entry and opportunities to introduce human error.
2. Constituent Portal
- Currently, constituent can provide updates to their information by emailing Foundation/campus staff or communicating with their relationship manager. This data then must be entered into ANDI and reviewed.
- In the future, constituents will be able to access a constituent portal that allows them to submit changes to their own personal information directly into Salesforce. In addition to traditional Bio updates, constituents will be able to provide more robust information back to the Foundation as well (e.g., Interests, Communication Preferences)
3. Creation of Records
- Currently, ANDI’s minimum requirements to create records are not in alignment with business needs. In the future, UTF will be able to customize the minimum information requirements need to create a record in Salesforce to better reflect their policies.
4. Joint Salutations
- Currently, the system does not create automatic joint salutations.
- In Salesforce, the system will allow automatic joint salutations.
5. Notifications
- Currently, there is no notification system to alert or inform staff or constituents of changes made or fulfilled requests. Notification regarding the fulfillment of a request is a manual process of emailing individual staff members or constituents to inform them of the status of their request. Because this process is not consistently applied, staff may receive duplicate requests to complete an update.
- In the Future, notifications of actions taken can/will be automated to send to internal stakeholders and constituents.
Key Considerations
1. Matching Logic
- Huron will partner with Central IT and Foundation staff to develop matching logic. Staff will want to consider potential criterion this might include. This will impact training opportunities in the future for staff tasked with entering data.
2. Security/Visibility/Edit Rights
- The current system limits the information that can be edited, a determination will need to be made as to which information will continue to be limited.
- UT Foundation will need to determine if there is information that should not be affected by visibility restrictions and to whom visibility restrictions will apply.
- It needs to be determined how to distribute the right to edit information, including what information can be edited/updated and which stakeholders will have the right to make edits/updates.
3. Requirements
- Determine the minimum data points needed to create a record.
4. Joint Salutations
- It will be helpful to establish/revise a policy for the order of joint salutations.
5. Notifications
- ‘It needs to be determined to whom, when, and by what method it is appropriate to send notification of actions taken to update records.
Core Impact
The out-of-the box functionality delivered in implementation of the new CRM will address most of the challenges of updating individual records. UT Foundation will benefit from increased speed of entry, reduced time and effort spent in manual processes, defined business processes for handling different types of constituent data, and automated matching logic to validate data inputs. Robust automation and matching logic will ensure that records will no longer be evaluated individually via a manual review process. The information received is reviewed to determine if duplicate information exists in the system, so that duplicate inputs will not be accepted. One of the new benefits of the CRM will be the creation of a constituent portal that will allow for constituents to directly manage changes to their personal information. Also, a new notification system will be automated to track and communicate changes to constituent data quickly and efficiently.
Batch Updates
Process Overview
It is common practice for campus departments and vendors to send CSV files to the Central IT Office for updating bio/demo data in the ANDI system. The process of updating data through batch upload involves three stakeholder types:
- Central IT Office (Internal)
- UT Campuses (Internal)
- Vendors (External)
The process begins with one of two inputs that are categorized as internal or external. External information comes from vendors; internally, departments submit CSV files containing bio/demo information directly to the Central IT Office for review and approval. The Central IT Office runs a script to validate the data. The data is placed into staging tables and goes through a validation process. Data that passes validation is then uploaded into the ANDI system.
Opportunities
During discussion about the batch update process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Duplicate Records/Duplicate Data
- Currently there is not robust matching logic for all fields
- Data such as student activities can be batch loaded on records, but the system does not check to make sure that data is not already on the record.
2. Required Fields
- Currently the system requires that certain fields, such as prefix and gender, be populated in order to create a record; this is a point of frustration, as many external sources often do not provide this information (examples: 4H Alumni, Health Sciences alumni)
- Currently the system requires that all records have a home address; ideally this would not be a requirement, as sometimes the only known address is not a home address.
- The vet hospital receives donations from “grateful clients” (owners of pets); however, due the nature of the data, the minimum data requirements such as gender and prefix aren’t available. As such, a lot of manual manipulation to add the records.
- Parent association data often does not meet minimum requirements for entry, so therefore admissions data is typically used for parents instead. Would be ideal to be able to use the parent association data.
3. External Address Validation
- Every two weeks, information is batch loaded from NCOA; errors in the load require manual review, which is a time-consuming process.
4. Documentation
- The current system does not retain/produce a record of who completed a batched record or when it was completed
5. Notification Systems/Error Reporting
- There is no functionality that reports errors in uploading records
6. Parent Data
- Need to determine a policy for how to handle parent data for students who have not graduated and are no longer attending the university
7. Student Data
- Student data is usually linked to student ID numbers. However, a policy needs to be determined for handling of students who leave the university before graduation.
Athletics would like to contact former athletes, but many of them did not graduate from the university; a system needs to be in place to be able to track these records.
8. VIP Records
- There is no consensus definition for a VIP. Usually, VIPs are considered donors who make very large gifts, or donors who require special handling. There needs to be one common definition for this designation, in order to ensure data integrity. Currently special handling codes are available, but not used. Information regarding special handling is entered as comments on a donor’s record by development officers
- There is no way to protect the VIP data from being overwritten during vendor loads
9. Lost Records
- A record can be saved as an active record, even if it doesn’t have an active phone number, email address or address. This goes against Foundation policy; ideally they would not be able to save a record as active without one of these three fields.
- The ability to have the system prompt a user to change the status to “lost” if the record does not have an active phone number, email address or address.
10. Relationships/Spousal Linking
- There is currently no way to create relationship records, such as spouses and children, during batch loads; users must manually link the records in ANDI.
Final Summary
The analysis shows that the current batch process possesses inefficiencies that increase the effort and time needed to update records. These inefficiencies include the inability to batch load entities, resulting in the need to use staging tables. This process could benefit from the addition of automation and out-of-the box functionality delivered upon implementation of the new CRM. UT Foundation can expect to benefit from reduced errors, fewer required fields, more robust matching logic, CRM-contained address verification, as well as reduced time and effort spent in manual processes.
Future State Process Overview
It will continue to be the practice for campus departments and vendors to send CSV files to the Central IT Office for updating bio/demo data in the Salesforce system. The process of updating data through batch upload involves three stakeholder groups:
- Central IT Office (Internal)
- UT Campuses (Internal)
- Vendors (External)
The process will begin with one of two inputs that are categorized as internal or external. External information comes from vendors; internally, departments will continue to submit CSV files containing bio/demo information directly to the Central IT Office for review and approval and uploading. The Central IT Office will no longer run a script to validate data, but instead will rely on matching rules. During implementation, Huron will partner with the Central IT Office to determine and implement the matching logic that underpins the validation process. The data will enter staging tables, go through a validation process, and be uploaded to Salesforce. Data that does not pass validation will be automatically shared with Central IT, allowing for any necessary manipulations to the CSV, based on the error reasons provided and the ability to reupload manipulated data fields. Salesforce will maintain a record of what data has been uploaded, when it was uploaded, and who completed the upload.
Key Changes
During discussion about the batch update process, several improvement opportunities to address inefficiencies in the current state surfaced:
1. Duplicate Records/Duplicate Data
- Currently there is not robust matching logic for all fields
- In the future, Salesforce will allow for robust matching logic for all fields to automatically validate imported data. There will also be flexibility to allow record by record reviews of imported data within Salesforce before updating data where appropriate.
2. Required Fields
- Currently the system requires that certain fields, such as prefix, home address and gender, be populated in order to create a record; parent data also does not usually meet minimum requirements and becomes unusable
- The future state ability to control required fields will allow for importing of data from internal and external sources that have not historically provided this information
- Currently, due to the minimum data requirements such as gender and prefix not being available for grateful patients, uploading this data requires a lot of manual manipulation to add the records.
- The future state ability to limit the required fields only to those defined as necessary, according to the university policy for creating a new constituent in the database, will eliminate the need manual manipulation
3. Salesforce-Native Address Validation
- Currently, every two weeks, information is batch loaded from NCOA; errors in the load require manual review, which is a time-consuming process.
- Leveraging ascend’s Interims object will allow streamlining of the regular load of NOCA data and update of records.
- In the future state, Salesforce will house native address validation tools, lessening the burden of manual reviews.
4. Import Records
- In the current system, documentation is not retained/produced to record who completed a batched record or when it was completed
- In the future, Salesforce will produce a record of who completed an import and when it was completed.
5. Student Data
- In the current system, student data is usually linked to student ID numbers with no policy to determine handling of students who leave the university before graduation; non-graduated athletes are also difficult to track
- The future state will allow an opportunity to realign Constituent Types and other relationships to the university across various objects in ascend’s data model. This will allow for simpler reporting for those current segments that are difficult to track and report on in ANDI.
6. VIP Records
- There is currently no consensus definition for a VIP.
- This implementation will provide opportunity for staff to establish one common definition for this designation, in order to ensure data integrity. This will be easily tracked and managed in Salesforce.
- Currently special handling codes are available, but not used. Information regarding special handling is entered as comments on a donor’s record by development officers
- In the future, special handling code will be applied to donor records and be easily accessible to development officers and other staff reviewing VIP records
- Currently, there is no way to protect the VIP data from being overwritten during vendor loads
- In the future, Salesforce functionality can limit the editability of VIP records.
7. Lost Records
- Presently, a record can be saved as an active record, even if it doesn’t have an active phone number, email address or address. This goes against Foundation policy; ideally, they would not be able to save a record as active without one of these three fields.
- The future state will provide the ability to have the system prompt a user to change the status to “lost.” or automatically update the status, if the record does not have an active phone number, email address or address. These can be presented in a list view or report to be regularly reviewed by staff.
8. Relationships/Spousal Linking
- There is currently no way to create relationship records, such as spouses and children, during batch loads; users must manually link the records.
- The new system will allow for batch loading of relationship records.
- Ascend will allow for the creation of households, account hierarchies, and roll up reporting of giving that will provide Development Officers insight to complex family giving.
9. Notification Systems/ Error Reporting
The current system does not produce an import error record
In the future, Salesforce will produce a record of upload errors, allowing staff to view reasons for errors correct errors, and re-upload data.
Key Considerations
1. 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.
