Request For Proposal Alumni Development Information System: Glassboro, NJ April 19, 2001

Request for Proposal
Alumni Development Information System
Glassboro, NJ
April 19, 2001
Rowan University
Alumni Development Information System Request for Proposal
Table of Contents
EXECUTIVE SUMMARY......................................................................................................................................................................................1
1.
OVERVIEW OF UNIVERSITY ADVANCEMENT.....................................................................................................................................1
2.
OBJECTIVES OF THE ALUMNI DEVELOPMENT INFORMATION SYSTEM.................................................................................2
3.
SCOPE OF THE PROJECT...........................................................................................................................................................................2
4.
CURRENT SYSTEM STATISTICS...............................................................................................................................................................3
5.
EXPECTED TIMETABLE.............................................................................................................................................................................3
6.
REQUIREMENTS...........................................................................................................................................................................................4
6.1. Instructions for Completing Requirements....................................................................................................................................................4

6.2. Technical Requirements...................................................................................................................................................................................4
6.2.1. Hardware.................................................................................................................................................................................................6
6.2.2. Database Management System (DBMS)................................................................................................................................................6
6.2.3. System Administration and Security......................................................................................................................................................7
6.2.4. Application Performance........................................................................................................................................................................8
6.2.5. Customization and Programming..........................................................................................................................................................9
6.2.6. Vendor Support (Implementation and Ongoing).................................................................................................................................10
6.3. General/Overall System Requirements.........................................................................................................................................................11
6.3.1. User Interface and Data Entry.............................................................................................................................................................12
6.3.2. Names, Addresses, and Biographical Information..............................................................................................................................14
6.3.3. Searching and Constituent Lookup.....................................................................................................................................................17
6.3.4. Reporting, Labels, Mailings, and Holds..............................................................................................................................................18
6.3.5. Links with other Systems......................................................................................................................................................................20
6.3.6. Documentation and Training...............................................................................................................................................................21
6.4. Functional Module Requirements................................................................................................................................................................22
6.4.1. Events Management.............................................................................................................................................................................22
6.4.2. Alumni...................................................................................................................................................................................................23
6.4.3. Organizations........................................................................................................................................................................................24
6.4.4. Campaigns.............................................................................................................................................................................................25
6.4.5. Prospect Management..........................................................................................................................................................................26
6.4.6. Planned Giving.....................................................................................................................................................................................29
6.4.7. Stewardship...........................................................................................................................................................................................31
Rowan University
6.4.8. Pledge and Gift Processing...................................................................................................................................................................32
7. INSTRUCTIONS TO VENDORS....................................................................................................................................................................37
7.1. Outline for Submittal......................................................................................................................................................................................37
7.1.1. Company Information..........................................................................................................................................................................37
7.1.2. Product Information.............................................................................................................................................................................37
7.1.3. References.............................................................................................................................................................................................37
7.1.4. Proposed Implementation.....................................................................................................................................................................37
7.1.5. Sample Agreements...............................................................................................................................................................................38
7.1.6. Costs......................................................................................................................................................................................................38
7.1.7. Response to Requirements....................................................................................................................................................................38
7.1.8. Appendix................................................................................................................................................................................................38
7.2. Technical Questions.........................................................................................................................................................................................39
7.3. Procedural Questions and Proposal Submittal Address..............................................................................................................................39
7.4. Deadline for Submittal....................................................................................................................................................................................39
8. EVALUATING APPROACH AND CRITERIA..............................................................................................................................................39
9. PROPOSAL CONDITIONS.............................................................................................................................................................................40
ii
Rowan University
Executive Summary
Rowan University seeks a comprehensive information management system to support alumni and fund-raising activities. This document is the Request for
Proposal (RFP) for that system and is being sent to selected vendors of non-profit fundraising systems and administrative systems which include a fund-raising
component. Vendors are asked to review this RFP to determine if they believe their system can be used to meet the needs of Rowan University and respond
according to the guidelines within the document.
1.
Overview of University Advancement
The Division of University Advancement is the Universitys central planning and coordinating office for activities and relations with prospects, donors, alumni,
and the community.
The Executive Vice President for University Advancement oversees the offices of Alumni Relations, Development, University Relations, University Publications
and University Marketing. In addition to securing support from private sources, the Division also involves in developing proposals for government grants.
1.1. The Alumni Relations Office sponsors a number of programs for a network of 55,000 living alumni of Rowan University. These programs include reunions,
homecomings, regional events, luncheons and receptions, professional sports events, educational programs, golf outings, and distinguish alumni awards. This
office manages alumni directories as well as special projects such as alumni credit card and a membership club for young alumni who graduated during the past
decade. Through the alumni web site at http://www.rowan.edu/alumni, this office communicates with alumni through web announcements, e-mails, and web
submissions. This office can also send out mass e-mail to a targeted group of alumni, normally by a radius from the event venue, for event announcements. The
Alumni Relations office is involved with a twenty-five-member Alumni Board. The director, an associate, and a secretary staff the Alumni Relations office which
endeavors to maintain communication with alumni, correspond with regular mailings, and gather updated information.
1.2. Development functions consist of Major Gifts, Corporate and Foundation Relations, Annual Fund as well as Development Information and Research.
1.2.1. The Major Gifts area includes gifts which are made through wills and bequests, with trust instruments, annuity agreements, insurance policies, and forms of
giving in addition to outright gifts. This office sends out a planned-giving publication called Hollybush Herald three times a year to alumni graduated before
1960 as well as retired faculty and administrators. The Director of Major Gifts and a secretary staff this area.
1.2.2. The Corporate and Foundation Relations area solicits support from corporations and foundations. A proposal writer prepares and works with faculty and
administrators to develop the solicitation documents. The Director of Development oversees this area as well as the Annual Fund. A secretary supports this
function.
1.2.3. The Annual Fund office solicits funds through mail and phonathon programs from alumni, friends, graduating students, parents of students, faculty and
staff, and corporate matching gifts for current operations. Students staff the phonathon operations. The Coordinator of the Annual Fund operates the program.
1.2.4. The Development Information and Research area directs and administers services that assist and support alumni and development officers with information
systems designed in FileMaker Pro (FMP), including phonathon tracking, alumni activity log, gift and pledge acknowledgements, pledge reminders, and prospect
tracking. The Office also uses FMP to provide graphical user interface for alumni development data maintained in the mainframe SCT IA-Plus system to
April, 2001
Page 1
Rowan University
enhance multiple-field searching and keyword searching. By adopting AccuZip bulk mail software as well as Zip Select zip codes by radius software, the Office
saves the Division a lot of resources through target mailing and bulk rate processing. This Office identifies and profiles individual donor prospects for cultivation
and solicitation of gifts. The Information Resources Manager performs all these functions. Two program assistants enter pledges, payments, and gifts as well as
produce daily acknowledgements and weekly reminders.
1.3. The Alumni Development System used by the Division is a module in the SCT IA-Plus integrated administrative system. The ADS module is supported by a
programmer in the Management Information Systems Department under the Division of Information Resources. University Advancement staffs use FOCUS
programming language to pull data from the SCT application and then incorporate the data in FMP for data manipulation and routine printouts. We use bar codes
and hand held scanners to process pledge and gift forms.
1.4. All University Advancement staff are equipped with Macintosh Power PCs (G3, G4, iMac) and the machines are connected to the campus-wide network via
ethernet protocol. We use Novell Groupwise for e-mail.
2.
Objectives of the Alumni Development Information System
The Alumni Development Information System is intended to meet the following objectives:
3.
Provide a contemporary centralized base of information that is easy to use by fundraising and alumni relations officers.
Aid the Development Office in the attainment of its fund-raising goals by providing timely and efficient monitoring and analysis of activities and
programs, gift and payment acknowledgements, pledge reminders, solicitation tracking, and other analysis for campaigns, special projects fund raising,
and annual fund with support for matching gifts.
Provide efficient standard reporting and ad hoc reporting capabilities at the user level.
Provide timely and easily obtainable information on screen as well as printouts on donors and prospective donors through online inquiry and selection.
Provide up-to-date biographical information, especially addresses, affiliations, and relationships for donors and prospective donors.
Provide systematic prospect management (moves management) tools for planning, tracking, and reporting.
Provide a flexible system that supports the business rules of the University (without dictating those rules) and one that will change with the needs of the
University and the users.
Provide a means for supporting the management of special events.
Provide a means for managing membership clubs.
Provide a means for linking and interfacing other information systems on campus.
Scope of the Project
The scope of this project is wholly on selecting the best possible system for University Advancement. With that in mind, we are NOT tied to a solution for the
Macintosh platform only. Rowan University is amenable to purchasing a system that is exclusively fund raising in nature or part of an integrated administrative
system. Rowan University has no preference for either a stand alone or integrated system provided that the fund-raising module(s) of an integrated system can
act equally well as a stand alone product.
April, 2001
Page 2
Rowan University
The Alumni Development Information System that Rowan University seeks must include but need not be limited to modules or functionality in these major
areas:
4.
alumni relations management

pledges and gifts management
annual fund and phonathon management
capital campaign management
prospect management
planned gifts management
events management
stewardship management
Current System Statistics
Pertinent statistics for the current Alumni/Development system follow:

DESCRIPTION
Constituents
Gifts & Payments
Pledges
Solicitations
Funds
Number of Users
5.
Number of Records
65,000
70,000
25,000
--400
15-20
Approx. Number 1999-2000

1,800 (new alumni)
7,000
4,200 (annual fund only)
35,000 (annual fund only)
---
Expected Timetable
Rowan University expects to have a new Alumni Development Information System selected in advance of June 30, 2001, with conversion, implementation, and
training lasting through April 30, 2002, the target date to discontinue processing in the existing environment.
April, 2001
Page 3
Rowan University
6.
Requirements
6.1. Instructions for Completing Requirements

In prioritizing the requirements for the Alumni Development Information System, the following ranking was used:
Rank
Meaning
must
Describes a critical requirement essential in the system because of its impact on the overall functionality needs of the
university.
should
Describes a requirement which is expected in the system though not critical to the overall functionality.
desired
Describes a requirement which would be helpful but is neither expected nor critical.
Vendors should review the following requirements and answer the narrative questions with short sentences, a paragraph, or a segment of the system
documentation that is included within the vendor response to the questions. Unspecific references to vendor documentation shall be treated as a non-response.
For the itemized entries, ranked must, should, or desired as above, please fill in the column Always, Sometimes, or Never with the ending to this sentence:
Our system can provide this function Use the comment section for further explanation as desired. At the least, most "sometimes" answers should have
qualifying comments. Samples follow:
#
1
2
Rank
Requirement
should provide expert user shortcuts or drilldown menus (e.g. go right to

a favored report or screen with minimal key strokes).
must have easily accessible documentation which is searchable, indexed,
printable, etc.
Always,
Sometimes
Vendor Comment
or Never
S
available in next update due to be released in January, 2002.
A
For the convenience of vendors, this portion of the RFP is available in Microsoft Word 97 format via e-mail (request from au@rowan.edu) or via
http://users.rowan.edu/~au/rfp.doc. The vendors must use this document to record their answers, using an appendix if necessary for figures, comments, etc.
Both a printed and electronic version (Microsoft Word 97 or Excel preferred) are required with vendor responses.
6.2. Technical Requirements
1.
The system must be of an open architecture as design based upon industry standards. That is, no part of the system or database should be "locked out" and
accessed only by the vendor. We expect to be able to add tables, fields, etc. and to connect to the database via industry standard methods (e.g. ODBC). The
vendor must describe the implementation of their database in this area as well as describe the "openness" of their system regarding industry standard
compliance, portability, scalability, and interoperability.
April, 2001
Page 4
Rowan University
2.
The system must be technically stable and have regular updates and enhancements to fix bugs, grant user requests, etc. The vendor must include a history
of recent release dates for upgrades or enhancements. Please include the top 5 items from your user wish list. How does an item make it to the wish list?
How are they addressed?
3.
The system must run on a multi-tasking network-enabled operating system over our existing Ethernet backbone with Ethernet LANs running under TCP/IP.
The vendor must describe the network and server operating system requirements of their system.
#
Rank
Requirement
must
must
must
must
must
9
10
must
must
11
12
13
14
must
must
must
should
15
16
should
should
17
should
18
19
should
should
20
desired
provide ROWAN the ability to add and store business rules as

objects (e.g. via database elements, table driven, program library,
middleware, etc.)
allow for the running of background or detached processes (e.g.
batch jobs).
have a report writer or have inherent third-party tools for same; the
report writer must include formatting for titles, headings, totals,
subtotals, etc.
must have a unique system assigned ID as well as alternate IDs
(SSN, and others).
provide the ability to use alternate IDs in an update of current
records from imported data (e.g. use SSN as the key).
allow connectivity to Excel & Word via downloads and uploads.
have connectivity to database via the network which is seamless to
users.
be a 32 bit application on the client side (i.e. native to newer clients).
allow SQL database access, preferably non-proprietary.
use at least level 2.0 ODBC support (both client and server).
allow connectivity to office productivity tools (e.g. Excel & Word)
directly (e.g. via ODBC).
use table driven custom business rules.
be a heterogeneous system providing us the ability to write
reports/queries against multiple databases.
use an intuitive, GUI environment for ad hoc queries and report
writing.
use integrated file and print services for NT if Unix-based.
use 3-tier client/server architecture with ability to divide system
processing for optimization.
use OLE capabilities (if on a Windows machine).
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 5
Rowan University
6.2.1. Hardware
1.
The vendor must have well-documented and tested choices for server machines (memory, speed, etc.) including benchmark tests for upgrading, etc. The
vendor must describe the recommended server hardware for their system. Please detail how upgrades in the system can be accomplished, including
increased memory and additional disk storage, CPUs, connection, etc., as well as indicate maximum upgrade potential.
2.
The vendor must list the requirements for the installation environment: temperature range, humidity range, power requirement, space requirement, external
connections for work stations.
3.
The vendor must describe the typical client machine.
4.
The vendor must list the types of printers that are supported/suggested? Currently, the Division has HP networked printers, including a LaserJet 5SiMX with
an envelope feeder.
5.
The vendor must list other hardware that is required (e.g. tape drives, modems, etc.)?
6.2.2. Database Management System (DBMS)

1.
The system must run on a current version of a fully relational, widely used and stable database, which will continue to be upgraded and supported. Rowan
University must be able to administer the database without additional staff. The vendor must describe the database management system used by their system
and how it meets these requirements.
#
2
3
4
5
6
7
8
Rank
Requirement
Always,
Sometimes
or Never
Vendor Comment
must
provide standard, proven, and efficient system for backup and

recovery, preferably implemented via vendor supplied application
and/or vendor provided user customizable script.
must have minimal causes for record locking, and should have userrecoverable procedures for locks caused by other users.
must allow for the addition of tables, fields, and indices including the
application of security features on those additions.
must use permission groups, preferably operating system level groups
(rather than application level groups).
should provide for easy backup & recovery at a transaction level.
should handle improper disconnects easily or via automation.
should use a data dictionary, linked to or part of database table definitions
that automatically stay in sync.
April, 2001
Page 6
Rowan University
Rank
#
9
Requirement
Always,
Sometimes
or Never
Vendor Comment
should use flexible ROWAN-determined security at the database level, by

table, by record, and/or by field which can be assigned by OS-level
group or individual.
should have no disabled database management system features.
should have vendor-supported database upgrades.
desired be a multi-platform database (runs on multiple OS/platforms).
desired allow database mirroring.
desired have a single point vendor support.
10
11
12
13
14
6.2.3. System Administration and Security

1.
The system must be of an open, yet secure architecture with multiple security features that may be incorporated per ROWAN's choice. The vendor must
describe the available security features of their system. Describe the methods used to set security features, especially those outside the network or operating
system level. Describe the level of upkeep and staffing required to incorporate both the most and least stringent security settings.
2.
The vendor must describe the staffing and knowledge or training required for system administration.
3.
The vendor must provide a description of the auditing capabilities of their system. Identify what audit data is stored (e.g. user ID, time, date). Is this
auditing part of the database or the application? Can auditing be turned on/off and/or tailored by the system administrator? How does auditing affect
performance?
#
Rank
must be able to set security restrictions by group or individual, preferably

using OS level groups.
must allow access to specific components of the database to be restricted
on the levels of: no access, read-only access, and update access.
must use follow through of security settings to applications, output media,
batches, etc. including those written by the user.
must have queue management tools for night queue, prioritizing of users
and reports, automating run-times, etc.
must not allow overriding of database security by any program or process.
should use a single, network level password for password security.
should have simple data warehousing-type features and summary fields and
tables available.
5
6
7
8
9
10
April, 2001
Requirement
Always,
Sometimes
or Never
Vendor Comment
Page 7
Rowan University
#
Rank
11
should have a means for backing out transactions and restarting failed batch
processes without a complete system recovery.
should have tools available for maintaining metadata and/or warehousing
extracts and loads.
should use consistent security from application to database to OS,
preferably same and settable at OS level (i.e. database and
application use OS level security).
should supply end-user and report usage statistics (i.e. who, what, how
often).
12
13
14
Requirement
Always,
Sometimes
or Never
Vendor Comment
6.2.4. Application Performance

1.
The system must support up to fifteen simultaneous users with at least the response time in our current system, ie mainframe and FMP applications (see
examples below). What benchmarks are applied to predict system performance? What factors have the hardest hit on system performance?
Rank
must
must
must
must
April, 2001
Requirement
Always,
Sometimes
or Never
Vendor Comment
complete a search for a constituent lookup in no more than 2

seconds.
complete a search and produce a ready-to-print report with home
and business addresses of, for example, 1,000 alumni (two classes)
in about 3 minutes.
be able to run up to 3 reports (e.g. daily gift transaction report of
about 100 records, biographical profiles of 1,000 annual fund
prospects, and quarterly fundraising report of about 1,500 records)
without affecting performance of other functions (e.g.
drawing/loading user screens and data entry).
be able to run on the client with at least 2 other client applications
without significant performance degradation.
Page 8
Rowan University
6.2.5. Customization and Programming
1.
We do not anticipate a need for pre-installed vendor customization of the system. However, should this situation arise, please describe how it would be
carried out and how these changes will be supported into the future. Are customizations covered under an additional maintenance agreement? If so, how are
upgrades handled?
2.
The system must allow for the use of vendor-provided or third party programming tools with which to manipulate data, create screens, menus, batches, etc.
as desired by Rowan University. These tools can include but are not limited to programming languages, 4GL, SQL, helper applications, etc. Please describe
the programming tools provided with your system or available through a third party. Describe any additional enhancements to third party tools such as
existing libraries for macros, applets, scripting, etc.
#
Rank
must
4
5
6
7
8
9
10
11
12
13
14
15
16
Requirement
Always,
Sometimes
or Never
Vendor Comment
be able to build custom views (screens) of the data to be used as

Rowan standards, speed data entry, and allow easy checking and
entry from existing paper forms.
must be able to create menus and sub-menus.
must be able to add whole new modules (with their own sub-menus,
reports, screens, tables, fields, etc.).
must be able to design multiple step processes (scripting).
must have the ability to do inner and outer joins.
must have the ability to join multiple tables (at least 10).
must have the ability to do set operations (e.g. union, intersection,
subtraction).
must allow for multidimensional arrays of any data type.
must allow the creation and use of stored, reusable code (e.g. objects,
applets, macros, sub-functions) to be used later in a query or
program.
must allow for the creation and management of code libraries.
must have reporting extension capabilities for building complex reports.
should use a debugger to help the user to set breakpoints, print out values,
etc.
should allow for both production and testing environments.
should have additional user help by being integrated with or have vendorenhanced features for third party vendor tools.
April, 2001
Page 9
Rowan University
6.2.6. Vendor Support (Implementation and Ongoing)
1.
The vendor must give evidence of being responsive to emerging user needs and having those needs reflected in future versions of the application. The
vendor must describe a project currently in development that meets this requirement. How have users been involved in the development of this
enhancement? How will it be tested? How will it be released?
2.
The vendor must specify the software warranty period.
3.
The vendor must be capable of providing training, custom programming, upgrades, and other services at reasonable rates. Please describe how your
company handles these types of requests from clientele. What are the basic rates?
4.
It is expected that the vendor will have knowledge of and provide some level of support and troubleshooting for the hardware, operating system, database,
security at all levels, backup and recovery procedures, systems management, and all devices used in the operations of the entire system. The vendor must
describe their offerings in this area as covered by "subscription service" and those services that are optional or fee-based. At what point does a customer
"question" turn into a billable item?
5.
The vendor must identify, sponsor, or support a users' group to foster shared ideas for using the application, database, etc. at both the user and technical level.
It is expected that the vendor participate in the sharing of information with the users' group via the group's activities--involvement in list services, web site
development, user meetings, etc. The vendor must provide pertinent information regarding the users' group(s) for your system.
6.
Software bugs reported by users must be acknowledged by the vendor and reported to other users. (Each customer must not be left to discover the bug
independently.) Patches or upgrades to address these problems should be distributed as soon as possible. The vendor must provide a description of the
companys procedure for dealing with user-reported bugs.
7.
The vendor must provide a telephone response time for problems and questions. What are the hours for your help line?
#
Rank
9
9
must
must
10
11
12
13
Requirement
Always,
Sometimes
or Never
Vendor Comment
provide timely (less than a day) help for emergency problems.

provide printed/printable end-user help which is both screen and
process oriented.
must provide printed/printable technical and user-level documentation.
should allow technical questions to be answered directly by vendor's
technical people.
should provide technical documentation separate from end-user
documentation.
should provide searchable, indexed online technical and user-level
documentation.
April, 2001
Page 10
Rowan University
#
14
15
16
Rank
Requirement
Always,
Sometimes
or Never
Vendor Comment
desired utilize a user panel to determine program weaknesses and to

prioritize future enhancements.
desired provide additional support options via e-mail or fax, searchable web
site, periodic FAQ, etc.
desired provide support for the entire database engine, even for unused
features.
6.3. General/Overall System Requirements

1.
The system must be a contemporary Alumni Development information system, combining demographic, biographic, and financial data into a single
relational, normalized database, linking together all the information therein. The vendor must describe the basic design of your system.
2.
The system must be cost-competitive with other systems having similar capabilities and features. Describe what you believe gives your system a distinctive
advantage over similar priced system.
3.
There must be consistency in the design of the system, in the programming approach throughout the system, and in the user interface, including screen
formats, documentation, and help facilities. The vendor must describe the consistent "look and feel" of your system.
4.
Currently, we can filter records with a temporary file of zip codes in FMP to identify alumni within a certain radius from the event venue. Also, we can use a
file in FMP with SSNs provided by another system to filter records in our system. The vendor must provide a description of how the system works with
temporary tables and filters.
5.
Exceptionally good multiple address management is of utmost importance. The vendor must provide a description of how the system deals with multiple
addresses for individuals. How are the unique situations for businesses and organizations handled (e.g. with multiple locations, branches, etc.)? Which
features are automated and which must be manually set?
6.
The system should have features built in that will help eliminate duplicate record entries. We would also expect a report or batch job to help flush out
possible duplicates (e.g. using matching logic to identify duplicate address). What preventive measures are incorporated into your system to prevent
duplicate records? How is the system checked for possible duplicates?
7.
The system should have web interfaces available. These interfaces should run on a web server (hardware and software) chosen, owned, and maintained by
the University. The web-interfaces can include output files but must be more than mere output files (e.g. reports saved as HTML and copied to a web
server). In other words, web interfaces must include data input, lookup, or other interactive access to the database (or a mirror or copy). Examples of such
interfaces might include:
security-enabled constituent lookup for executives, on-the-road access, or volunteers who will not have access to our network or vendor client
software
April, 2001
Page 11
Rowan University
electronic change of address form for constituents (placed in a hold area or table for review before being committed to database)
The vendor must include a list of web interfaces available. Are the web interfaces add-on items with separate costs? Are additional client licenses required?
What drives the interfaces (e.g. C, Perl, Java, etc.)? Are they enabled for Intranet (secure), Internet, or either? Are templates available?
#
Rank
must
9
10
11
12
13
14
15
16
17
18
Requirement
Always,
Sometimes
or Never
Vendor Comment
be capable of managing 70,000 constituents to begin with, and

expandable to three to five times that number over time.
must support unlimited addresses per constituent.
must support unlimited contacts for businesses and organizations.
must allow for multiple contacts in single company or organization and
use contact relationships with links to company address(es).
must be able to override all of the automatic functions to address the
exception.
must allow alternative methods of entry of information (e.g. optical
scanning, bar code reading, web forms, batch entry, etc.).
must supply user-definable and user-maintainable tables of codes used
throughout the system.
must provide for mail merges directly to Microsoft Word or create tab
or comma delimited ASCII files.
should provide interactive processing, allowing updates to be immediately
reflected across the entire system.
should use a zip code table to fill in city, state with ability to turn off and/or
override for multiple towns in same zip.
desired create a contact record automatically (on demand) from e-mail in or
out.
6.3.1. User Interface and Data Entry

1.
The user interface must be GUI (i.e. non-text based) and use interface standards accepted for computer platform (Windows/Mac) on which it runs to allow
users to transfer knowledge from PC tools to the system. Please describe the features of your system which mirror the standards of desktop productivity
tools (e.g. menu at top of screen, "file" choice being left most, tabs to move to additional screens/data, etc.).
2.
The user interface must be clear, intuitive, "friendly," and encourage user self-reliance. Consistency in commands and icons must be used throughout the
product. Please include several screen snapshots of different parts of the system which illustrate "friendliness" and consistency. Include narrative with the
snapshots if desired.
April, 2001
Page 12
Rowan University
#
Rank
Requirement
must
must
must
6
7
must
must
8
9
10
11
12
13
14
must
must
must
must
must
should
should
15
16
17
should
should
should
18
should
19
should
20
should
21
should
22
should
23
desired
provide ways to navigate easily from one place to another (e.g. from
prospect rating to giving records, to report templates, to financial
accounting entry, to campaign pledges, etc.).
include shortcuts (e.g. backwards, forwards) and keyboard
equivalents for mouse movement.
have the ability to put a running report/query in the background
(multi-tasking).
allow the user to preview queries and reports before printing.
provide coded, table-driven fields that facilitate customizing of
applications, and speed data entry.
have data integrity checks, table-driven when appropriate.
use a verification process to validate the entry of coded values.
allow user to view and search all possible responses for coded fields.
support wild card lookups and searches anywhere within fields
be accessible from off-campus/on-the-road.
use smart search for "sounds like."
support Rowan University data entry standards via data checks at
time of entry (e.g. auto correct "street" to "ST" or "Street").
be a visual (drag and drop) and object-oriented environment.
provide customizable macros for frequently run tasks.
provide expert user shortcuts or drilldown (e.g. go right to a
favored report or screen with minimal key strokes).
provide ability to view table values for non-data entry end-users (i.e.
view available codes and translations in pull-down menu even
without write access to data or while in view-only mode).
allow seamless integration (direct connection) to desktop
applications (Word, Excel, FileMaker Pro, etc.).
have the flexibility to change or add additional code values on the
fly (i.e. add to code/translation table while entering data) provided
the user has the permission to do so.
provide ability to set custom business rule triggers (i.e. data entry or
modification triggers entry of something else).
assist the user with "smart" data entry (e.g. fill-in, series completion,
etc.).
use customizable toolbar buttons, tab order of fields, color, font, and
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 13
Rowan University
#
24
25
26
27
Rank
Requirement
Always,
Sometimes
or Never
Vendor Comment
other visual configurations.

desired have convenient integration to PC/Mac products such as mail clients
and calendar programs.
desired allow user to set repeating value defaults at the start of a session (i.e.
all elements being entered during a particular session will be coded
same).
desired have off-line compact versions with reconnect merge capability for
on-the-road productivity.
desired allow "clickable" opening of external documents (e.g. word
processing documents) stored within application.
6.3.2. Names, Addresses, and Biographical Information

1.
The system must allow for joint as well as individual constituent options (e.g. allow one record to represent 2 people) so that one ID can be used to represent
a couple where only one is the constituent (or both are one constituent together). Both single and joint names must be stored (e.g. John Smith is the
constituent but "John and Mary Smith" are the couple) and joint or single salutations (Mr. or Mr. and Mrs.) used as chosen by the user, with ROWAN chosen
defaults. Salutations should be viewable on screen and alert the user if missing data is being replaced by defaults. Non-spousal relationships must be
allowed as well (friend, parent, etc.). The vendor must indicate any limitations their system has in this area.
2.
The system must allow for recording unlimited involvements such as student activities (social organizations, sports, band, etc.), start and stop dates, status
(current/former), office (e.g. club president), and comments. In addition, an unlimited number of accomplishments such as awards, scholarships, graduation
honors, fellowships, professional awards, etc. must be allowed with the same sort of additional information recorded. Thirdly, an unlimited number of
interests such as hobbies, cultural, athletic, and civic interests, again with the same sort of additional information recorded. All must be differentiated
between ROWAN and non-ROWAN items. The vendor must provide information on the capability of their system to perform this task.
3.
An unlimited number of external affiliations (DAR, Elks, etc.) must be allowed, with hard links to the organization where desired (may qualify as a
matching donor) as well as start and stop dates, status (current/former), office (e.g. board member), and comments. The vendor must provide information on
the capability of their system to perform this task. How are external affiliations treated similarly to employers? How are they treated differently?
4.
The system must accommodate home, business, seasonal, and reference addresses that are definable in terms of preferred mailing address and can hold up to
4 street address lines and allowing for foreign addresses. Telephone, fax, and e-mail addresses must be able to be stored with each along with which address
is preferred, seasonal routing schedules, etc. The vendor must provide information on the address storage features of the system.
April, 2001
Page 14
Rowan University
Rank
Requirement
must
must
7
8
9
must
must
must
10
11
12
must
must
must
13
must
14
must
15
must
16
must
17
must
18
must
19
must
20
must
allow for the storage of multiple names (unlimited number

preferred) of virtually any type: nickname, maiden, birth, ROWAN
name, current name, preferred name, former name, professional
name, doing business as, formal, informal, special names, aliases
(A.K.A).
have separate fields for first name, last name, middle name, suffix,
title and professional suffix mapped to a full name.
have table driven suffix, title and professional suffix.
allow hyphenated names.
capture gender, ethnicity, marital status (including ROWAN
Couple), birth date and place.
record death and date of death.
allow general comments.
record number, names, birth dates, gender, status (deceased, lost,
active), SSN and comments for non-ID children of alumni.
allow multiple class years (actual college, preferred, honorary, prep
school, seminary), multiple majors, multiple degrees (bachelor or
graduate degrees).
have ability to mark and easily determine couple as "ROWAN
Couple."
allow gender-based relationships (e.g. father-daughter), handle all
possible family relationships, handle friendships, roommates, etc.
and allow histories.
allow full spouse information storage (i.e. education, employment,
etc.) tied to spouse link with ID.
allow non-employment business affiliations with hard link to
organization record.
have hard-link between employee and employer but not required
(ability to store employer name without an associated ID).
have generic business information, matching gift policy, and ratio
included automatically (e.g. translate or "flow through") on the gift
entry screen.
allow primary/secondary/former employer designation, status, dates
of employment, flag self-employment, field of work and specialty,
position description, title, position level (e.g. manager), with
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 15
Rowan University
#
Rank
21
must
22
must
23
must
24
must
25
must
26
must
27
must
28
must
29
should
30
should
31
should
32
should
33
should
34
should
April, 2001
Requirement
Always,
Sometimes
or Never
Vendor Comment
comments.
allow employee links to local business address of employee and
employer's headquarter address.
allow storage of additional schools and degrees (unlimited in
number), table driven with degree, degree year (year graduated),
majors (up to 3), honors (up to 3), start and stop dates, non-grad
flag, school-type indicator, and allow comments.
allow both CAE and ROWAN-chosen affiliations (e.g. alumnus,
parent, trustee), unlimited in number, with ROWAN-chosen primary
affiliations.
be able to record source of address change and date for changed
addresses (e.g. call-in, forwarded mail, etc.).
have the ability to flag address as non-mailable or mail eligible (e.g.
flag an address as correct, incorrect, temporarily away)
have fields for e-mail (home and business), www page (home and
business), phone and fax number (business and home) with
extension, unlisted flag, and ability to include foreign phone and fax
numbers (e.g. extra digits).
have the ability to see all addresses for one constituent at the same
time (via scroll through if necessary).
have record usability status (lost, active, deceased, purge-able) and
status date with status stored only once but follow through entire
system and the staff who makes changes.
have automated past-naming and addressing; system takes a new
name or address just entered and makes it current and takes the old
name or address and makes it past.
have choice of free-form or coded comments which would indicate
general type, author of comment and one line description.
have automatic update or on-screen calculation of age based on birth
date and current date.
have ability to add non-spousal/child relationships without needing
to create a new constituent record (e.g. deceased parents,
grandparents, aunts, uncles, sisters, brothers etc.).
have the ability to add multiple relationships between people and
organizations.
have the ability to easily change non-ID relationships to ID-based
Page 16
Rowan University
#
Rank
35
should
36
should
37
should
38
39
should
desired
40
desired
41
desired
42
desired
43
desired
44
desired
45
desired
46
47
desired
desired
Requirement
Always,
Sometimes
or Never
Vendor Comment
relationship if non-ID person becomes constituent (e.g. grown child,

widow of constituent now becomes constituent).
allow for storage of research data for lost alumni to store degree of
"lostness," status of research, etc.
link employment information to individual's business address upon
update of either employment or business address information.
have security options to determine who can review comments based
on type.
have security options to keep address available to only select people.
handle "private addresses" which are in the system for reference but
not normally used in mailings except when specified (e.g. when a
constituent asks for alumni magazine but doesn't want anyone
knowing his address).
allow someone to appear to be anonymous in the system with
storage of the actual name in a secure area open to only select
people.
allow soft links to multiple IDs for ROWAN relationships (e.g.
students to advisors).
allow general comments and comments based on names, addresses,
salutations, etc.
allow SSN, nickname, class year, secondary school, other college for
non-ID'd other relationships (i.e. store same data as for ID'd
relationships).
be able to store name of administrative assistant/secretary for
executives.
"build" an address from company records and constituent records
(for several constituents within same company and location but
different mail stops).
validate address according to USPS standard
look at stop and start dates on home addresses automatically with
ability to add a future home address.
6.3.3. Searching and Constituent Lookup

1.
The system must provide name search features allowing us to find entities under a variety of names, such as birth, former, married, and corporate names,
first, middle, and last names, nicknames, etc. Virtually any field must be available for searching as part of the standard online lookup capabilities. The
April, 2001
Page 17
Rowan University
vendor must provide information on the searching features for a standard lookup screen. Are "smart searches" available to non-power users that can be used
to search multiple fields? Are "smart-searches" available for handling variations in the data (e.g. IBM vs. I.B.M. vs. International Business Machines)? How
do these work?
2.
The system must be able to provide users with multiple field searches which include combinations of tables and fields and using boolean and comparison
operators (and, or, not, greater than, etc.). These searches must be able to be saved globally as well as by an end-user for future use. The vendor must
provide a description of or a snapshot of a complex search screen or example.
#
Rank
3
4
must
must
5
6
7
8
9
10
Requirement
Always,
sometimes,
or never
Vendor Comment
make search results immediately available on-screen.

allow user to choose one record from a search from which to
proceed to other parts of the online system (e.g. gift history).
must have the ability to subtract, intersect, or join populations of selected
records.
must provide critical information in the match list including, for example,
but not limited to: name, address, address type, alumni/ae class year,
primary constituency, lost/active status.
must be able to search and/or select records on virtually any data element
contained in the records.
should allow user to switch between case-sensitive/case-insensitive queries.
should make the match list from a search available for input to a report.
desired support searchable full text and keywords (e.g. for trip reports).
6.3.4. Reporting, Labels, Mailings, and Holds

1.
One of the primary needs for the new system is to go beyond traditional transaction processing. Thus, reporting tools will play a critical role for each and
every user of the system and will be widely used for decision support. The system must use flexible user-oriented reporting tools (rather than programmeroriented tools). These may include vendor-written or third party tools. Vendor templates, macros, or examples must support the use of third party tools.
Reporting tools should be menu-driven, use context-sensitive help, and/or wizards to assist users in a step by step manner. Users should be able to write
many of their own ad hoc reports (after a day or so of training). Please describe the reporting tools used by your system and how they meet these goals.
2.
Reports should be definable in terms of format, location of data elements, sort order, totals and subtotals, and selection and exclusion of data. Reports should
be available on paper, on screen, and in files. There should be a library for standard reports that can either be used as is or serve as templates for the
development of new reports. The vendor must provide a description of how the system's reporting meets these goals.
3.
The system should come with a variety of pre-defined biographic, giving, and financial reports, all of which are user modifiable. These should include but
not be limited to daily phonathon report, year-end performance, balance reports, campaign reports, audit reports, accounting reports, and CAE reports,
April, 2001
Page 18
Rowan University
available on-demand or system-scheduled to run automatically at set intervals. The vendor must describe the "canned" reports included with the system.
Include a list if desired.
4.
Output format for reports must allow for virtually any type of user-defined form, eg pledge form, reminders, payment receipts, mail merge, standard and
custom-sized labels, envelopes, badges, and cards. Other desirable features include font settings, text color, italics, etc. Do your reporting tools support
these types of formats and features? Are direct connections (e.g. ODBC) to PC productivity products available to achieve these types of output?
5.
The system must provide the ability to choose virtually any population or combination of populations for label and envelope. The user must have the choice
of fields to print (e.g. class year, ID#, etc.) and be able to view labels on-screen before printing. The vendor must provide a list of system-provided label and
envelope formats and outline the procedure a user would go through to produce non-standard labels or envelopes. If a third party tool is used, please indicate
preferred tools and what vendor-supplied templates are available.
6.
The system must be able to create an unlimited variety of readily accessible presentation-ready reports (e.g. individual prospect reports for various
audiences, fund raising progress reports, prospect tracking reports). This will require that the system store useful summary information about a prospect or
campaign and that it provide the tools to retrieve this information easily and in a visually appealing way. Are special reports for summary information
included with the system? The vendor must provide a sample.
#
Rank
must
8
9
10
11
12
13
14
15
16
Requirement
Always,
Sometimes
or Never
Vendor Comment
have ability to produce address labels or envelopes fully adhering to

postal regulations (including bar codes) for best pricing options.
must have the ability to join mailings for couples (one mailing per
address).
must allow single line and split lines for joint labels.
must provide ways of dealing with exceptions (e.g. names too long for
label).
must allow the use of bar codes for ID Numbers
must allow use of all types of industry-standard labels for mailings (i.e.
some post cards require smaller labels).
must allow an unlimited number of holds (no solicitation, no mail, no
contact with ROWAN, no mail solicitation, no phone solicitation, no
e-mail contact) with dates, status, source of information, and
comments.
must allow hold histories with dates and Staff Name.
should have flags and dates for tracers sent and returned mail (bulk vs. first
class return vs. magazine); source of information (e.g. self reported,
post office, etc.).
should keep records of mailings and who received what (e.g. via mailing
April, 2001
Page 19
Rowan University
#
17
18
19
20
21
22
23
Requirement
Rank
Always,
Sometimes
or Never
Vendor Comment
history records).
should have ability to queue reports for execution immediately or at a later
time (i.e. night queue).
should include a cover or trailer sheet with selection details and other userchosen properties which determine the outcome.
should construct foreign addresses in acceptable, mailable format, not
simply "retro fitted" into USA address format.
desired provide report usage statistics to identify what reports are used by
who, when, etc.
desired have the ability to access additional databases in report creation.
desired use "smart" sorting of names to deal with deMarco, Smith-Jones,
etc.
desired provide for user-designated sorting options such as a user-chosen
sort name to allow for exceptions such as foundations known
better by last word name, corporations by first word in name,
government agencies by second word in title, etc.
6.3.5. Links with other Systems

1.
Procedures for data sharing and links with other offices/systems would need to be established. The anticipated scenarios are listed below. At the current
time, some electronic "transfers" are possible through the integration of and among the SCT modules (e.g. Student Information System and Financial
Records System). The vendor must provide information on how their system might be used to handle the following needs for sharing and linking data.
Indicate the level of complexity to automate each (easy, moderate, or difficult) as pertaining to your system and which can be accomplished directly through
open systems (e.g. ODBC).
Direction
2.
Office
System
from
registrar
SCT
from
to
to
human res.
business off.
business off.
SCT
SCT
SCT
What
new alumni (including vitals, degree, honors,
student activities, and contact information)
employees
daily gifts and payments
yearly pledge summary (FASB)
Complexity
Direct
(Y/N)
Comment
The system must allow easy integration with other applications, e.g. no more than two steps to import into a desktop application with direct connection being
preferable over import. Current standard applications are Microsoft Office Professional Suite (Word, Excel, and PowerPoint) and FileMaker Pro database
software. The vendor must describe how the system integrates with desktop tools.
April, 2001
Page 20
Rowan University
3.
The system must provide for auto/mass load of new records (including ID records), matching on IDs where necessary (non ID records) to obtain data from
external sources. Users must be able to perform the load, preview it online, and set additional rules before committing it to the database. It is preferable that
a wizard or other user aid be available for this purpose. Some "uploads" may be updating existing records (e.g. obtaining new addresses from a credit
bureau), adding new records (e.g. adding involvement records for attendees), or both (e.g. obtaining an updated employee feed). Please describe a typical
scenario for mass updating existing and new records and the steps the user takes to accomplish this.
#
4
5
6
7
Requirement
Rank
Always,
Sometimes
or Never
Vendor Comment
should have automated import information from directory publishers (e.g.

Harris) or other sources such as DIALOG, Lexis/Nexis,
Econometrics.
desired automated updates to corporate information, matching gift
information, prospect screening and research information, from
services like HEP, Marts & Lundy, CDA/Investnet.
desired accept information from other software electronically (e.g. trip
reports from a word processor).
desired have ability to link to digital phone system for automatic dialing of
phone number chosen on screen.
6.3.6. Documentation and Training

1.
A user who has been thoroughly trained must be able to perform simple queries, run a simple report, and be able to attempt more complex operations. What
can users expect to learn during basic training? Do the training materials support the documentation and vice versa? The vendor must describe how the
documentation for your system enables users to continue to learn on their own after training, particularly for reporting and output of data.
2.
The vendor must describe the training options and environment(s). Is it a hands-on session in a lab environment? If so, who are the instructors and how are
they trained? Do you use third-party trainers? Are there any self-paced training programs (e.g. computer-based training, videos, etc.)? What levels of
training are offered (e.g. general user, system administrator, executive, power users, technical, etc.)? The vendor must include a schedule with one year's
worth of offerings (current or past year).
#
Rank
Requirement
must
must
have easily accessible documentation which is searchable, indexed,

printable, etc.
have independent learning and review resources available (in
addition to or in lieu of classroom training) particularly to jumpstart
new learners or re-learning.
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 21
Rowan University
#
5
6
7
8
9
10
Requirement
Rank
Always,
Sometimes
or Never
Vendor Comment
must be targeted at specific levels of expertise.

must have data element dictionary available for reference online.
should provide detailed, online help which is linked to related help text
topics and an online index.
should allow for a train-the-trainer approach so that the University can
develop its own trainers.
should have integrated training for third-party applications or tools with
emphasis on specific use of vendors system.
desired allow for the addition of Rowan custom help, either by the end-user
or by technical staff.
6.4. Functional Module Requirements

6.4.1. Events Management
1.
The system must maintain a variety of events of many types (e.g. receptions, building openings, graduations, reunions, breakfasts, lunches, dinners, media
events, public events, etc.) for many purposes (e.g. stewardship, cultivation, recognition, tradition, public awareness, communication, etc.). Events may last
hours or days and may include many mini-events within the whole. The vendor must provide an overview of the events management function of the system.
#
Rank
Requirement
must
must
must
must
6
7
8
must
must
must
generate invitation lists, invitations, reply cards, envelopes, name

tags, name cards, etc.
be able to track attendance (numbers) and/or names of guests
(may or may not have an ID record on the system).
track budget information and revenues such as: item, type,
budgeted amount, amount expended, status (paid, unpaid,
committed, available).
maintain facility management information, such as: reserve room,
catering, staging, tables, chairs, decorations, parking, etc.
generate follow-up correspondence.
track event evaluation information.
be able to record attended/invited/declined, dates, comments.
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 22
Rowan University
#
Rank
Requirement
must
10
should
have the ability to link event attendance with giving details for
reporting.
have batch entry mode (ability to enter event attendance
efficiently for information that repeats from record to record).
maintain seating assignments, dietary requirements (vegetarian,
allergies, etc), and special instructions (handicapped, wheelchair,
etc.).
can associate people attending special events with the event, but
not actually be part of the main database.
maintain event plan (task list), such as: activity, date, person
responsible, status (i.e., completed, to be done, canceled, etc.).
have comments for everything.
handle pre-registration (e.g. through web interface) and actual
registration (e.g. on site at the event).
maintain records for contact information for external vendors and
internal offices (phone, mail, dining service, rental company, etc.)
have an events and planning calendar.
use a pre-existing event as a template for a new one ("clone" an
event setup).
maintain historical records for comparisons between similar or
repeating events.
11 desired
12 desired
13 desired
14 desired
15 desired
16 desired
17 desired
18 desired
19 desired
Always,
Sometimes
or Never
Vendor Comment
6.4.2. Alumni
1.
The alumni module must be capable of maintaining multiple ROWAN degrees for individuals.
Rank
Requirement
must
be capable of maintaining all of the degree-related information for

each individual, including the school from which the degree was
obtained, type of degree, area of study, honors, and date the
degree was conferred.
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 23
Rowan University
#
Rank
Requirement
must
must
desired
desired
7
8
desired
desired
provide for the recording and maintenance of memberships and

payment information for sustaining alumni association
memberships (e.g. GOLD Club).
able to manually change the reunion year which is different from
the year when the Rowan degree is conferred.
allow multiple class agents per class with one identifiable head
agent.
automatically assign alumni regional chapter clubs by system
based on table-driven zip code regions but allow override and
secondary manually assigned clubs.
show alumni distribution in the state of New Jersey and in the US
allow unlimited committee assignment (e.g. trustees, admissions
recruiter, phonothon volunteer, alumni club officer, alumni
council, reunion committee, class agent, etc.), term dates, office
(e.g. president, associate agent, etc.).
Always,
Sometimes
or Never
Vendor Comment
6.4.3. Organizations
1.
Users must be able to easily distinguish multiple records which appear to belong to the same organization but instead identify the corporate headquarters,
subsidiary or branch offices, matching gift foundation, etc. particularly in search results. The vendor must provide information on how the system can
accomplish this task.
#
Rank
Requirement
must
must
must
must
be able to easily distinguish organizations, corporations, and

foundations, from individuals.
link matching gift information: ratio, show where matches are
processed, distribution dates, min/max matched.
show subsidiary relationships (parent corporation, etc.), link
unlimited number of contacts to organization (who gets mail for
that organization, officers, directors).
show gift summary of an organization including its subsidiaries on
screen or on printout.
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 24
Rowan University
#
Rank
should
desired
desired
Requirement
Always,
Sometimes
or Never
Vendor Comment
Always,
Sometimes
or Never
Vendor Comment
store holdings, nature of business (text), comments, number of

employees.
allow organizations to have all the same linked information as
individuals (e.g. invitations, holds, etc.).
maintain organization contacts (relationships to people) for
alumni/ae matching gift company coordinators, who to mail to,
foundation contacts, etc.
6.4.4. Campaigns
#
Rank
Requirement
1
2
must
must
3
4
5
must
must
must
must
7
8
must
must
9
10
must
must
11
must
support alumni regional campaign management.

determine regions by zip code ranges (non-contiguous and
contiguous).
be able to assign staff and volunteers to regions.
be able to create regional goals and results scenarios.
accommodate gift clubs with years; allow multiple gift clubs for a
given year; lifetime, annual and capital gift clubs, type of gift
club.
be able to choose constituents by region based on their home
and/or work address (mailable or not) and their relationship to the
college (alumnus/a, parent, etc.) and their prospect level (major
gift, special gift, annual gift).
match regional goals against results.
maintain history of proposals, solicitations, etc. for each campaign
or proposal.
track solicitation techniques (e.g. phone, mail, personal visit).
track and maintain prospect base and designate constituent status
(i.e. corporation, foundation, alumni, parent, friend, etc.)
maintain fund status and fund transfer status (i.e. hold, pending,
transferred, etc).
April, 2001
Page 25
Rowan University
#
Rank
12
must
13
14
15
must
should
desired
16
desired
Requirement
Always,
Sometimes
or Never
Vendor Comment
monitor and track annual vs. campaign vs. planned giving for all
constituents.
track cash flow status by project.
provide automated pledge analysis (pledge fulfillment rates).
maintain fields for tracking cultivation and effectiveness, such as
fund-raising results (# of donors, % of goal), participation rate,
statistics (average gift, e.g.), evaluation of scheduling, attendance
and/or satisfaction, trend analysis, dollars raised by constituent,
effectiveness of staff, effectiveness of volunteers.
maintain programs recorded with their associated activities,
including: goals, methodology, results, evaluation,
recommendations.
6.4.5. Prospect Management

1.
The system must provide prospect tracking management (moves management) capability with detailed support for the identification, planning, segmentation,
and tracking of cultivation and solicitation efforts. A donor may have any number of solicitations with each having any number of actions associated with it
to store relevant information regarding planned contacts, actual contacts, proposal submissions and dates, etc. The vendor must provide a move management
scenario as can be achieved with the system.
Rank
Requirement
2
3
must
must
must
must
must
directly link a gift or pledge received to the correct solicitation.

allow the coding of activities that should take place or have taken
place with an entity for prospect tracking (e.g. setting up
reminders to send invitations for a special event, "call reports,"
etc.).
be able to assign up to 4 solicitors to a prospect; one primary staff
solicitor, 1 other staff solicitors, trustee solicitor (sometimes),
volunteer solicitor (sometimes).
have the ability to distinguish between major and annual giving
solicitor and volunteer assignments with room for both.
have the ability to have a history of solicitor/prospect assignments
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 26
Rowan University
#
Rank
must
must
10
must
11
must
12
13
must
must
14
must
15
must
16
must
17
18
must
must
19
must
April, 2001
Requirement
Always,
Sometimes
or Never
Vendor Comment
with begin and end dates.

allow multiple active solicitations in various phases of
completion, distinguishing between annual and capital
solicitations.
maintain solicitation/proposal: ask amount, status (e.g. solicit in
current fiscal year), campaign and department assignments,
segmentation (e.g. major gift, special gift, annual gift, etc.),
solicitation method (letter, phonathon, etc.), purpose (linked to
purpose table for gifts and pledges), and comment.
be able to identify LYBUNTS, SYBUNTS, New Donors and Non
Donors.
store phonathon status (i.e. pledge, maybe, refusal, no contact, or
mail) with date, student caller or volunteer, campaign, appeal, ask
amount, and pledge amount.
provide spouse linkage for joint and single asks.
separate historical (complete/deleted) solicitations from
current/active solicitations.
provide profile information displaying a brief summary for each
entity (person or organization) that is ROWAN customizable.
handle electronic screenings (e.g. Marts and Lundy,
CDA/Investnet), ROWAN screening programs (off-campus),
suspect review screening(on-campus).
store type and source, screener, rating, initial ask amount, prospect
status (rejected, in-progress, accepted), comments.
store unlimited screening estimates.
store unlimited Prospect Management comments assignable to key
areas (e.g. relations, historic research, business information, etc.)
and allow some comments to be made "confidential" for viewing
and printing only by selected individuals.
have the ability to see and to print as much information about a
prospect in one place as possible, without doing continual
searches through different parts of the system for the same
prospect.
Page 27
Rowan University
#
Rank
Requirement
20
must
21
must
22
must
23
must
24
must
25
must
26
must
27
must
28
29
should
should
30
should
31
desired
32
desired
33
desired
have the ability to easily see which prospects and solicitations are
assigned to a solicitor and which solicitors are assigned to a
prospect.
automatically determine what annual giving solicitation letter
should be produced when solicitations are produced based on
ROWAN defined criteria (e.g. previous gifts and demographics).
allow for the setting of data entry triggers based upon critical
paths and moves management (i.e. ability to set what is triggered
and when).
have the ability to automatically "roll" annual solicitations from
year to year with the capability of basing default asks on an
ROWAN-defined formula that may vary over time.
easily re-assign staff or volunteer solicitor prospects to a new
person due to turn-over (e.g. via batch entry).
track the productivity of individual solicitors (i.e. # of prospects, #
of solicitations completed, # of solicitations declined, total amount
raised, # of new pledges, etc.).
allow trip and contact reports in essay-form with unlimited text
attached to solicitation.
provide a method for storing, sorting and manipulating trip
reports.
allow for temporary coding of prospects.
store and display solicitation status and date associated with
pledge along with how it is progressing through the pipeline.
have a proactive visit/travel tickler system including a system for
entering and recalling next steps for prospects.
have fields for lifestyle indicators (e.g. country club member,
length of yacht, year of airplane and number of engines, etc.).
have fields for philanthropic indicators (e.g. gives to cultural
causes, environmental causes, etc., amount donated, etc.).
have fields for securities summary across all companies (market
value, dividend, past stock sales, net value of options, grand total,
number of stock gifts, total stock gifts, largest gift, largest gift
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 28
Rowan University
#
Requirement
Rank
34
desired
35
desired
36
desired
37
desired
38
desired
Always,
Sometimes
or Never
Vendor Comment
Always,
Sometimes
or Never
Vendor Comment
date).
have links to companies for which holding stock: insider name,
company name, ticker symbol, exchange code, CUSIP, industry
code, industry description, title of insider, business address and
phone, form-144 address and phone.
have links to companies from which stock gifts were given:
number of stock gifts, total stock gifts, largest gift, largest gift
date.
have linkage from constituent to organization as stock holder with
stock information from CDA/Investnet: last transaction date,
current shares ownership, security type, ownership code, current
share price, current market value, one year high price, one year
low price, estimated dividend, vested shares, non-vested shares,
average exercise price for vested, average exercise price for
non-vested, vested transaction date, non-vested transaction date,
vested shares to expire, non-vested shares to expire, possible
vested net gain, possible non-vested new gain, vested expiration
date, non-vested expiration date.
have automated procedures for assigning staff to prospects via
ROWAN chosen criteria and with over-ride capability.
can show potential connections (e.g. system shows if person is in
same city, on same board, in same company, etc. as a major
donor, staff member, or other ROWAN chosen individual).
6.4.6. Planned Giving

#
Rank
1
2
must
must
3
4
must
must
April, 2001
Requirement
have the ability to track bequests.
distinguish between realized bequest and bequest expectancies
and track date of both.
have the ability to handle outside managed trusts.
have ability to record the amount of a bequest expected, as
reported by a living donor and distinguish between a specifically
Page 29
Rowan University
#
Rank
must
must
must
must
must
10
must
11
must
12
13
must
must
14
must
15
must
16
must
April, 2001
Requirement
Always,
Sometimes
or Never
Vendor Comment
reported amount and the default value.

have ability to record the actual dollar amount of a matured
bequest as reported by the executor and the actual dollar amount
of the bequest when received at ROWAN.
track type of bequest (e.g. contingent, outright, pecuniary,
residuary, unknown).
be able to associate a bequest with a campaign, purpose, and
allocation.
link bequests to resultant distribution/gifts and distinguish
between value expected and value received.
be able to distinguish between anonymous and known will
provisions.
maintain bequest status (e.g. known copy of will, distributed in
full) and maturity (e.g. formal notice, informal notice, no longer in
will, verbal notice, written notice, etc.)
track historical bequest status with dates through the life of the
bequest (i.e. each status change is recorded for historical purposes
along with the date of status change); specific dates of interest
include: the date ROWAN was first informed that a bequest is
coming to the University and the date of any information updates
(i.e. when the bequest was created, when updates occur).
have the ability to track life income plans (LIPs).
track a trust, gift annuity, or pooled income fund (e.g. Charitable
Lead Annuity Trust, Charitable Lead Unitrust, Charitable
Remainder Annuity, Charitable Remainder Unitrust, Deferred Gift
Annuity, Gift Annuity, Pooled Income Fund A, Pooled Income
Fund B, externally managed trusts).
track the status of the trust (e.g. active, complete, matured,
pledged, or refused).
maintain face value, present value, estimated maturity date and
estimated maturity value.
link to trustee(s) and contact(s).
Page 30
Rowan University
#
Rank
Requirement
17
18
19
20
21
must
must
must
must
must
22
23
24
must
must
should
maintain pay-out rate, remainder interest (deduction factor).

maintain multiple contributions to the same LIP.
maintain beneficiary name and date of birth.
track life insurance.
link to resultant gifts and pledges with checks and balances to
ensure referential integrity.
track planned giving inquiries (who requested what when).
have the ability to produce receipts with planned giving language.
have the ability to store and access text descriptions of endowed
funds.
Always,
Sometimes
or Never
Vendor Comment
Always,
Sometimes
or Never
Vendor Comment
6.4.7. Stewardship
#
Rank
Requirement
must
must
3
4
5
must
must
should
desired
desired
have allocations that include ability to categorize funds, details of

fund restrictions, date fund was established, full name of fund for
acknowledgment and reporting purposes, stewardship status,
original donor, stewardship action required, estimated donor
value.
have the ability to determine who signs the acknowledgment and
what type of special handling a gift or pledge reminder receives.
have tickler system for stewardship activities done and to-be done.
have the ability to track and report on inactive stewardship funds.
track stewardship to show what forms of stewardship a person has
received (invitations, campus visits, letters from recipients, etc.).
have the ability to generate a report identifying the fund, criteria,
budgeted and spendable amounts, students and their grant
amounts which would require interfacing with both the financial
aid and accounting modules in CARS as well as the fund-raising
system.
track all donors who gave in memory and in honor of to the
April, 2001
Page 31
Rowan University
#
Requirement
Rank
desired
desired
10
desired
Always,
Sometimes
or Never
Vendor Comment
Always,
Sometimes
or Never
Vendor Comment
Annual Fund or to a general endowment by the name of the

individual in whose memory or honor the gift was made.
be able to flag a person as being interested in a particular project
(like a building).
have a rules-based system for defaulting in several standard
scenarios of stewardship with ability to override. For example,
standard stewardship for endowed scholarships is that the donor
receives the annual report from Financial Aid and an invitation to
the Scholarship Donors lunch.
link students awarded prizes to the associated sponsors.
6.4.8. Pledge and Gift Processing

#
Rank
Requirement
must
must
must
4
5
must
must
must
must
must
support gift entry and posting, giving inquiry screens, reports of

giving and maintenance of related information such as accounts,
funds and campaigns.
include comprehensive support for matching gifts, as well as
facilities for joint, group, honorary and memorial credit for gifts.
follow established general ledger account structure and protocols
and allow further breakdown of General Ledger account codes
into "allocations" with name and ultimate purpose.
map allocations to CAE codes for reporting purposes.
be assignable to ROWAN-specific: purpose, motivation code,
campaign, project, solicitation to indicate what appeal elicited the
gift or pledge (e.g. leadership letter).
accommodate hard and soft credit for any constituent, pair of
constituents, or group of constituents.
provide for spouse or other splits and group gifts and pledges with
total settable by group.
provide a way to determine amount due from each member of a
group including over a payment schedule.
April, 2001
Page 32
Rowan University
#
Rank
Requirement
9
10
must
must
11
must
12
must
13
must
14
must
15
must
16
must
17
must
18
19
20
21
must
must
must
must
22
must
provide a way to identify the primary donor (for reminders).

allow for special handling (e.g. no reminders, monthly or
quarterly reminders, etc.)
allow for anonymous donors which transfers from pledge, to gift,
to associated donor and allow multiple levels of anonymity (show
name not amount, show amount not name, don't show name or
amount, etc.).
be able to automatically produce a gift acknowledgment based on
information already on constituent's record.
be able to record different types of gifts, such as memorials,
honoree, gifts-in-kind, credit cards, securities, quid pro quo,
payroll deductions, and electronic transfers.
have the ability to see summaries of all gifts and pledges received
from a person and/or a couple with gift and pledge clearly
identified as such, and relationships between pledges and pledge
payments shown as well as date, paid status, and allocation.
have the ability to see where matching gift and soft credits are
coming from as well as the linked company without having to go
through additional lookups.
allow any number unfulfilled pledges to be supported
simultaneously for any constituent.
display the donor's outstanding pledges during gift entry, so that
the operator can indicate the pledge being paid (or create an
outright gift).
link pledges and their payments.
allow for daily posting of all gifts received.
generate audit trails for all online activity.
provide for batch balancing reports, gift receipts, pledge
acknowledgments, management summaries.
include giving screens with composite giving record, gift
summary, and gift totals. Additional views must include hard
credit (actual dollars given), matching gift company, giving for a
particular year, and recognition credit (soft) shared between
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 33
Rowan University
#
Rank
23
must
24
25
must
must
26
27
28
29
30
must
must
must
must
must
31
must
32
must
33
must
34
must
35
36
must
must
37
must
38
must
39
must
April, 2001
Requirement
Always,
Sometimes
or Never
Vendor Comment
parent/child, spouse, employee,

be capable of supporting multiple pledges for each entity and
providing easy access to ancillary information, such as pledge
payments and honored/memorialized entities.
be able to customize pledge acknowledgments and reminders.
accommodate multi-year pledges with or without payment
schedules.
have easily accessible amount due/paid together on one screen.
have easily accessible link between payments on a pledge.
have means to determine if claim received on anticipated match.
provide for regular posting to the University's accounting system.
perform monthly reconciliation by project code for checking
against general ledger.
handle prior year gift error corrections without modifying original
data.
produce pledge reminders or acknowledgments at any time of the
year with any solicitation criteria for any specific fund(s) or
solicitation code(s).
determine what annual giving solicitation, reminder, or
acknowledgement letter should be produced based on ROWAN
rules and scenarios.
automatically prepare batch sheet for cashier for daily/periodic
gift postings.
maintain donor summaries by year and campaign.
maintain donor summaries by year and allocation or purpose or
project or challenge.
maintain lifetime giving broken into pledges, pledge payments,
outright gifts, matching gifts, etc.
maintain annual, capital, lifetime and other gift clubs based on
ROWAN rules and allow manual adjustments.
record payment type (credit card, check, gift in kind, security,
etc.), transaction type (outright gift, pledge payment, bequest,
Page 34
Rowan University
#
Rank
40
41
42
must
must
must
43
must
44
45
must
must
46
47
must
must
48
must
49
must
50
must
51
must
52
53
must
must
54
55
must
must
April, 2001
Requirement
Always,
Sometimes
or Never
Vendor Comment
trust, etc.).
accommodate receipt date, date of record, and update dates.
calculate gift discount amount for planned gifts.
include General Ledger postable flag; allow gifts and pledges to
be entered into the system but not posted to the General Ledger.
handle memorial and in-honor gifts with person being
memorialized recorded.
allow gifts from individuals to pay other person's pledge.
be able to store non-postable recognition credit like accrued
interest.
have system generated receipt number.
accommodate gifts-in-kind with textual description, donor value,
inventory reference, appraised amount, liquidated amount, date
appraised, date liquidated, appraiser name.
accommodate securities with textual description, # of shares,
donor value, daily high and low of value date, value per share,
amount paid to brokerage firm, date sold.
have temporary or preliminary pledge entry area for phonathon
or other use which can be used by many volunteers. Regular
personnel should be able to review, edit, and delete the
preliminary records without further actions or ramification in the
system.
have batch gift/pledge entry with default settings for gifts and/or
pledges entered in that batch (with ability to override desired).
have the ability to book pledges with or without a payment
schedule and the ability to customize that schedule.
have the ability to indicate match form received.
have the ability to store matching gift claims and use that data as
input when matching gift arrives.
have the ability to display match ratio on claims.
have the ability to produce one receipt for the company sending
multiple matching gifts in one check.
Page 35
Rowan University
#
Rank
Requirement
56
57
should
should
58
should
59
should
60
should
61
should
62
should
63
64
desired
desired
65
66
desired
desired
automatically update gift clubs.

have the ability to incorporate two payment schedules into one
pledge (e.g. donors are: one employee with payroll deductions
monthly, one alumnus/a who makes a once-a-year gift to complete
the pledge).
prepare cumulative receipts for donors who participate via payroll
deduction or who have arranged to have their credit card
automatically charged on a regular schedule to acknowledge
several installments with one receipt.
have the ability to change payment schedules even after a
payment has been made.
have the ability to modify a pledge that already has payments
attached to it.
show annual, campaign, and total giving separately or together as
per the users choice.
have the ability to make minor changes to a gift before it is posted
to General Ledger without having to batch and change receipt
number (e.g. outright gift to pledge payment, campaign wrong,
purpose code change, split gift, etc.).
ability to easily differentiate types of payments (e.g. color-coded).
have the ability to have one total pledge split between several
allocations.
ability to credit two allocations on one receipt.
ability to have the gift linked to undecided/unspecified pledge
when entered.
April, 2001
Always,
Sometimes
or Never
Vendor Comment
Page 36
Rowan University
7. Instructions to Vendors
7.1. Outline for Submittal
All proposals must be presented in accordance with the following outline:
7.1.1. Company Information
Include the following information about your company:
a) Vendor name and address.
b) Salesperson/Contact name, title, phone, fax, and e-mail address.
c) WWW site URL.
d) Company history and organization.
a) User group affiliations (e.g. CASE, EDUCAUSE, your product users' group, etc.).
e) A statement of financial stability.
f) Explain any Chapter 7 or 11 filings during the past 10 years.
g) Business partners related to this proposal (e.g. hardware OEMs, companies for which you redistribute software, use for contract training, etc.)
7.1.2. Product Information
Provide a profile of your product(s) including:
a) Detailed description of proposed hardware and peripherals. (Note: Rowan University reserves the right to purchase hardware from any vendor.)
b) Software
i) Software product name (including current or former aliases), description, and version number.
ii) Name, description, and version number of proposed add-ons, modules, or other software which is subsidiary to the above (e.g. web interfaces).
iii) Name, description, version number, and company name of any third party tools you wish to make part of this proposal.
c) Product list of non-hardware items you are not making part of this proposal (i.e. additional software) if desired.
d) Documentation sample (5-10 pages or one section/chapter).
7.1.3. References
The vendor must provide six references with complete address, telephone number, e-mail address, and contact name. Preferred references would be universities,
similar in size and with similar administrative systems scenarios as described above.
7.1.4. Proposed Implementation
Provide a description of the proposed system implementation including the following:
a) On-site personal visit days for vendor support during installation, conversion, and training.
b) Site preparation necessary for installation, conversion, and training.
c) Timetable detailing proposed duration of installation, conversion, and training.
d) Detailed outline of proposed responsibilities for both vendor and the University.
e) Description of the recommended training program including:
i) Types (e.g. classroom, lab, video, computer-based, etc.)
ii) Levels (e.g. general user, casual user, power user, system administration, technical, etc.)
April, 2001
Page 37
Rowan University
iii) Modules (e.g. pledges and gifts, events management, alumni relations, etc.)
iv) Location (e.g. on-campus, in your facility, etc.).
7.1.5. Sample Agreements
Provide a copy of your standard contract, product license agreement, and maintenance agreement for our review.
7.1.6. Costs
Provide itemized costs for:
a) Capital costs
i) Hardware and Software (itemize each)
ii) Software only (if different from hardware and software purchased together)
iii) Software add-ons, modules, or other subsidiaries (e.g. web interfaces)
iv) Third party tools
b) Maintenance costs
i) Software and hardware
ii) Software only
iii) Upgrades
Indicate the last 3 upgrade dates
Cost of each of the above upgrades
Any hardware changes required by any of the above upgrades
c) Training costs
i) Initial training
ii) Ongoing/regular offerings
d) Conversion costs
i) Costs not included with capital costs if any
ii) Rates for consulting, contract programming, vendor-performed conversion, vendor travel, etc.
7.1.7. Response to Requirements
Provide answers to our requirements statements (section 6) as described in 6.1 above.
7.1.8. Appendix
Provide an appendix, if desired, for any information expanding on your company or offerings not requested in the above sections.
April, 2001
Page 38
Rowan University
7.2. Technical Questions
Technical questions should be directed in writing by May 11, 2001 to:
Tony Mordosky
Associate Provost
Division of Information Resources
Rowan University
201 Mullica Hill Road
Glassboro, NJ 08028
Phone - (856) 256-4401
Fax - (856) 256-4404
E-mail - mordosky@rowan.edu
7.3. Procedural Questions and Proposal Submittal Address
Procedural questions should be directed in writing to Mr. Keith Duke, Director of Purchasing, at the following address. Send six(6) complete and identical copies
of the proposal to the same:
Keith Duke
Director of Purchasing
Rowan University
201 Mullica Hill Road
Glassboro, NJ 08028
Fax - (856) 256-4443
E-mail - duke@rowan.edu
7.4. Deadline for Submittal
Proposals must be received by the Rowan University Purchasing Office, shown above, no later than 2:00 p.m. on May 25, 2001.
8. Evaluating Approach and Criteria
The University will use the following approach to evaluate the proposals:
1. Review the proposals and select the vendors who most closely fulfill our requirements.
2. Contact selected references.
3. Select finalists.
4. Schedule and attend demonstrations of selected finalists.
5. Conduct a site visit to see software and hardware in an operating environment.
6. Compare the general costs.
7. Select the vendor and negotiate the contract.
April, 2001
Page 39
Rowan University
Lowest cost will not be the sole determining factor and the award made will be made to the vendor whose proposal, in the opinion of the University, represents
the best proposal considering but not limited to the following evaluation factors:
1. System which most closely fulfills the fundraising and alumni relations objectives of the Division of University Advancement.
2. Proven operations in similar environments.
3. Overall cost of the vendor's services including purchase price, installation, conversion, expansion, operation, and maintain costs.
4. Vendor support and responsiveness as reported by references.
5. Installation, conversion, and training program proposed.
6. Quality of documentation and completeness of proposal.
7. Perceived strengths and weaknesses of vendors product.
9. Proposal Conditions
The following general conditions apply to this request for proposal:
1. Rowan University reserves the right to reject any or all proposals.
2. Rowan University reserves the right to select all or any part of equipment and software that is being offered in your proposal.
3. Rowan University reserves the right to purchase all or part of the computer hardware from any source deemed most cost effective.
4. Vendors will be responsible for all costs incurred in preparing their proposals and demonstrating their system.
5. All contracts and agreements will comply with the legal requirements of the Commonwealth of New Jersey and purchasing regulations of Rowan University.
6. This RFP will be made part of the contract.
April, 2001
Page 40

Request For Proposal Alumni Development Information System: Glassboro, NJ April 19, 2001

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Request For Proposal Alumni Development Information System: Glassboro, NJ April 19, 2001

Загружено:

Авторское право:

Доступные форматы

Request for Proposal

Alumni Development Information System

OVERVIEW OF UNIVERSITY ADVANCEMENT.....................................................................................................................................1

OBJECTIVES OF THE ALUMNI DEVELOPMENT INFORMATION SYSTEM.................................................................................2

SCOPE OF THE PROJECT...........................................................................................................................................................................2

CURRENT SYSTEM STATISTICS...............................................................................................................................................................3

6.1. Instructions for Completing Requirements....................................................................................................................................................4

Overview of University Advancement

Objectives of the Alumni Development Information System

Scope of the Project

alumni relations management

Current System Statistics

Pertinent statistics for the current Alumni/Development system follow:

Approx. Number 1999-2000

6.1. Instructions for Completing Requirements

should provide expert user shortcuts or drilldown menus (e.g. go right to

provide ROWAN the ability to add and store business rules as

The vendor must describe the typical client machine.

6.2.2. Database Management System (DBMS)

provide standard, proven, and efficient system for backup and

should use flexible ROWAN-determined security at the database level, by

6.2.3. System Administration and Security

must be able to set security restrictions by group or individual, preferably

6.2.4. Application Performance

complete a search for a constituent lookup in no more than 2

be able to build custom views (screens) of the data to be used as

The vendor must specify the software warranty period.

provide timely (less than a day) help for emergency problems.

desired utilize a user panel to determine program weaknesses and to

6.3. General/Overall System Requirements

be capable of managing 70,000 constituents to begin with, and

6.3.1. User Interface and Data Entry

other visual configurations.

6.3.2. Names, Addresses, and Biographical Information

allow for the storage of multiple names (unlimited number

relationship if non-ID person becomes constituent (e.g. grown child,

6.3.3. Searching and Constituent Lookup

make search results immediately available on-screen.

6.3.4. Reporting, Labels, Mailings, and Holds

have ability to produce address labels or envelopes fully adhering to

6.3.5. Links with other Systems

should have automated import information from directory publishers (e.g.

6.3.6. Documentation and Training

have easily accessible documentation which is searchable, indexed,

must be targeted at specific levels of expertise.

6.4. Functional Module Requirements

generate invitation lists, invitations, reply cards, envelopes, name

be capable of maintaining all of the degree-related information for

provide for the recording and maintenance of memberships and

be able to easily distinguish organizations, corporations, and

store holdings, nature of business (text), comments, number of

support alumni regional campaign management.

6.4.5. Prospect Management

directly link a gift or pledge received to the correct solicitation.

with begin and end dates.

6.4.6. Planned Giving

reported amount and the default value.

maintain pay-out rate, remainder interest (deduction factor).

have allocations that include ability to categorize funds, details of

Annual Fund or to a general endowment by the name of the

6.4.8. Pledge and Gift Processing

support gift entry and posting, giving inquiry screens, reports of

provide a way to identify the primary donor (for reminders).