Automating Key Development Functions

550 views

Published on

Contact reports and proposals are essential to the development process and are made up of many distinct pieces of data collected within the database. The process of managing the entry of these key functions can be laborious, requiring data entry from multiple sources, extensive review, and sometimes re-entry. This session will demonstrate a team-based approach that incorporated subject matter expertise from prospect management, data management, and information systems culminating with the development of an application using The Raiser’s Edge application programming interface (API). The application automated the contact reporting and proposal processes, saving substantial staff time, improving data accuracy, enforcing entry of required data, and enhancing the security around donor data.

Published in: Technology, Business
  • Be the first to comment

Automating Key Development Functions

  1. 1.
  2. 2. Our goals:<br /><ul><li>provide information to help define your key development functions
  3. 3. provide insight and inspiration on how to build an automated process</li></ul>SESSION Overview<br />
  4. 4. <ul><li>About us
  5. 5. Define our key development functions – the collection of the contact reports and proposals
  6. 6. Describe how we automated a process for collecting this data</li></ul>AGENDA<br />
  7. 7. Introductions<br />Minnesota Medical Foundation at the University of Minnesota<br />Daniel Lantz, Application Development Manager, Information Services<br />Deborah Mueller, Director of Prospect Development<br />
  8. 8. OUR MISSION<br />The Minnesota Medical Foundation (MMF) helps people live healthier lives by advancing the health-related research, education, and care at the University of Minnesota. <br />
  9. 9. OUR Objectives<br />
  10. 10. HistoryOFMMF<br /><ul><li>Founded in 1939
  11. 11. Separate 501(c)(3)
  12. 12. First staff hired in 1959
  13. 13. Raised 1/3 of the University total during Campaign Minnesota
  14. 14. Brought in 3 of the largest gifts in University history:
  15. 15. $65M for cancer research
  16. 16. $50M for U of M Amplatz Children’s Hospital
  17. 17. $40M for Schulze Diabetes Institute</li></li></ul><li>DEFINING KEY DEVELOPMENT FUNCTIONS<br />
  18. 18. A contact report is a meaningful and constructive communication between an MMF staff member and a potential donor <br />The contact report involves various data elements collected within Raiser’s Edge<br />WhatisACONTACTREPORT?<br />
  19. 19. <ul><li>Track significant information to advance a prospect towards solicitation
  20. 20. To record the history of the relationship
  21. 21. To communicate with other MMF staff
  22. 22. Establish metrics to measure performance
  23. 23. Maintain official records of the prospect relationship</li></ul>WHYCOLLECTACONTACTREPORT?<br />
  24. 24. <ul><li>Date and type of contact and by whom
  25. 25. Brief summary of contact
  26. 26. Complete narrative of visit
  27. 27. Prospect strategy
  28. 28. Next steps
  29. 29. Prospect manager, prospect classification and rating
  30. 30. Philanthropic interests
  31. 31. Basic demographic changes
  32. 32. Need to add/update prospect team</li></ul>contact report details<br />
  33. 33. NOTES<br />
  34. 34. ACTIONs<br />
  35. 35. PROSPECT INFORMATION<br />
  36. 36. A verbal or written document that defines a problem or need, proposes a solution to a problem and requests funding to implement the solution. <br />WHAT IS A PROPOSAL?<br />Mikelonis, Victoria M., Betsinger Signe T. Nielsen, and Constance Kampf. Grant Seeking in an Electronic Age. New York: Pearson/Longman, 2004. Print.<br />
  37. 37. <ul><li>Purpose/area of support
  38. 38. Proposal solicitor
  39. 39. Anticipated ask date
  40. 40. Proposal status
  41. 41. Gift type and vehicle
  42. 42. Dollar range – rating
  43. 43. Anticipated ask amount
  44. 44. Amount and date asked
  45. 45. Amount and date anticipated
  46. 46. Amount and date funded</li></ul>PROPOSAL details<br />
  47. 47. Automating KEY DEVELOPMENT FUNCTIONS<br />
  48. 48. <ul><li>MGOs enter data directly into Raiser’s Edge
  49. 49. Created e-mail template
  50. 50. Service Center approach
  51. 51. New application via API process</li></ul>History of Collecting Contact Reports/ Proposals<br />
  52. 52. <ul><li>Transition processes from current systems
  53. 53. Increase efficiency and simplicity for all staff
  54. 54. Empower major gift officers
  55. 55. Build secure process
  56. 56. Eliminate use of e-mails
  57. 57. Provide mobility and flexibility
  58. 58. Control completeness and accuracy</li></ul>OverallProjectGoals<br />
  59. 59. <ul><li>Web-delivered system
  60. 60. Remote access
  61. 61. Gather same info as currently collecting
  62. 62. Display existing data in RE
  63. 63. Allow modification of certain data elements
  64. 64. System must be flexible</li></ul>Save partially completed contact reports<br />Review before accepting into RE<br /><ul><li>Data uploaded to RE via API process
  65. 65. Easy to access and use
  66. 66. Secure</li></ul>ProjectRequirements<br />
  67. 67. Whattoputinandwhattoleaveout<br /><ul><li>Build mobile, secure application to add/modify/view specific RE data elements
  68. 68. Don’t make the application a web-based RE</li></li></ul><li><ul><li>Time savings
  69. 69. contact report processing reduced time allocated to data entry from 67% to 10%
  70. 70. Simplified interface increased speed of data entry
  71. 71. development assistants had time for other projects - data is entered directly by MGO’s
  72. 72. Metrics and other reports more accurate and up-to-date</li></ul>OutcomesofNewApplications<br />
  73. 73. OutcomesofNewApplications<br /><ul><li>Increased security
  74. 74. contact reports can wait in queue and be shared with other MGO’s
  75. 75. contact reports are no longer emailed
  76. 76. More accurate data
  77. 77. required fields are limited
  78. 78. data must accepted before entry into RE
  79. 79. RE business rules are maintained by using API
  80. 80. data entered by MGO’s, not development assistants</li></li></ul><li><ul><li>Web development skills</li></ul>Coldfusion<br />ASP.NET<br />PHP<br />Perl<br /><ul><li>Visual Basic coding</li></ul>Visual Basic 6.0<br />VB.NET<br /><ul><li>Knowledge of API</li></ul>Classes offered at Blackbaud<br />Raiser’s Edge help contains documentation<br /><ul><li>Blackbaud.com knowledgebase</li></ul>Excellent code examples for working with API<br />Resources<br />
  81. 81. User Interface – ColdFusion Website<br /><ul><li>Collect the data</li></ul>Data is collected and stored in the Contact Reporting Application database<br />Data can be reviewed and shared until the data is accepted for entry into RE<br /><ul><li>Validate the data</li></ul>Data is reviewed and can either be accepted or denied<br />API – Visual Basic application <br />Raiser’s Edge<br />ORDEROFOPERATIONS<br />Contact Reporting Application database<br />Contact Report/Proposal Approved<br />Insert the data<br />Data is inserted into the Raiser’s Edge via a VB.NET application using the RE API<br />Review the data<br /> Data can be viewed using established RE queries or via dashboard<br />
  82. 82. <ul><li>WEB INTERFACE
  83. 83. ColdFusion 9.1 – dynamic web development
  84. 84. jQuery – user interface tricks
  85. 85. HTML – core building blocks for web page
  86. 86. CSS – styling the page
  87. 87. RAISER’S EDGE
  88. 88. Visual Basic .NET
  89. 89. Raiser’s Edge API</li></ul>TOOLS used<br />
  90. 90. Raiser’sEDGEAPI<br /><ul><li>Provides an automated method of entering data into Raiser’s Edge
  91. 91. Business rules set in Raiser’s Edge are enforced via the API
  92. 92. API is accessible via code written in VB.NET or Visual Basic 6.0
  93. 93. Blackbaud offers a three-day API class</li></li></ul><li>Contact report applicationsearching for existing constituents<br />
  94. 94. creating a contact report<br />
  95. 95.
  96. 96. Validating Contact report/proposal<br />
  97. 97. CollectingProposal DATA<br />
  98. 98. ProblemstoOvercome<br /><ul><li>New systems during busy fundraising times
  99. 99. Get MGO buy-in
  100. 100. Need to be flexible while rolling out / application phases
  101. 101. Feedback and responses from MGOs
  102. 102. Trustworthy and accurate systems
  103. 103. Maintaining the application after ‘completion’</li></li></ul><li>Questions<br />
  104. 104. Thankyou<br />ContactInformation<br />MinnesotaMedicalFoundationattheUniversityofMinnesota<br />DanielLantz–d.lantz@mmf.umn.edu<br />DeborahMueller–d.mueller@mmf.umn.edu<br />

×