PROSTrail Guide
CRM vendor addendum
This brief describes the records, fundraising functions, communication tools, workflows, staff actions, reports, and data access Proxima needs from a responsive nonprofit CRM.
It does not select a vendor or require one product's object names. Vendors may use equivalent terminology, but they must show where each record lives, how it is updated, what starts the workflow, how staff see and complete work, and what evidence can be reported or exported.
Capability categories
These categories use familiar nonprofit-CRM language so vendors can identify the relevant module, record type, configuration, and package level.
Maintain individual, household, and organization records with contact information, constituent type, relationships, roles, affiliations, interests, custom fields, assigned relationship owner, notes, and a chronological interaction timeline. Provide duplicate detection, merge controls, and a clear primary record.
Record one-time and recurring gifts, pledges, soft credits, in-kind gifts, refunds, failed or reversed payments, payment method, fund, campaign, appeal or source, acknowledgment and receipt status, and donor credit. Make first gift, latest gift, lifetime giving, consecutive giving, and recurring status available for reporting and workflow criteria.
Organize fundraising and communication activity using named campaigns, funds, appeals, source codes, events, and online forms. Every submission or transaction must retain its originating form, campaign, appeal, event, Message, and timestamp so staff can distinguish source from inferred influence.
Create saved searches, reports, groups, segments, or audiences from constituent, gift, relationship, event, preference, and interaction criteria. Support automatically refreshed membership as data changes, plus intentional static lists when exact membership must be preserved.
Support email, text, direct mail, and personal outreach with templates, personalization, scheduling, sender identity, and communication history. Track channel-specific opt-in or opt-out, do-not-contact status, valid addresses, bounces, delivery status, and exclusions before every send.
Start automation from a new or changed record, transaction, form submission, event activity, date, group membership, or scheduled search. Apply criteria and branches, wait for defined periods, update fields, add or remove group membership, send a communication, create an activity or task, pause for review, and stop when completion or suppression conditions are met.
Record calls, meetings, letters, emails, texts, notes, requests, and other interactions as dated activities connected to the constituent and relevant campaign or journey. Tasks require an assignee, due date, status, priority, purpose, completion date, outcome, and reassignment path; task assignment must not silently change the durable relationship owner.
Manage registrations, guests or attendees, attendance status, cancellations, fees, waivers or form responses, reminders, and follow-up. Keep registration, attendance, volunteer participation, and explicit requests as separate reportable facts on the constituent timeline.
Provide saved and custom reports across constituents, gifts, campaigns, communications, activities, tasks, events, preferences, and workflow results. Reports must support filters, selected columns, drill-down, grouping, calculated totals, scheduled delivery, comparison periods, and export of the underlying rows.
Provide documented APIs, webhooks or event notifications, import and batch-update tools, full exports, stable record identifiers, role-based permissions, field-level or record-level protection where needed, audit history, backup and recovery practices, and a defined method for correcting or deleting data.
Data model
Equivalent objects are acceptable. The vendor must identify where each item is stored, how it is related, and whether it is available in reports, workflow criteria, APIs, and complete exports.
| Record area | Required information |
|---|---|
| Constituent or account | Individual, household, or organization type; names; contact channels; status; roles; relationships; affiliations; interests; custom fields; assigned relationship owner; created and modified dates; source; duplicate and merge history. |
| Gift or transaction | Amount; date; one-time or recurring status; pledge or payment status; fund; campaign; appeal or source code; payment method; soft credit; acknowledgment and receipt status; failure, refund, or reversal; originating form and stable transaction ID. |
| Campaign, appeal, or journey | Purpose; owner; audience criteria; start and end dates; Message or offer; channels; source codes; intended response; workflow rules; completion definition; budget or goal when applicable. |
| Communication | Channel; template or content name; sender; recipient; scheduled and sent time; delivery, bounce, reply, click, and opt-out status; campaign or journey; source record; exclusion reason for anyone not sent. |
| Activity or interaction | Type; constituent; date and time; staff owner; campaign or journey; direction; summary; privacy level; explicit request or other outcome; follow-up required; source and attachment where applicable. |
| Task or next step | Constituent; assignee; due date; priority; status; purpose; originating signal or workflow; related campaign or journey; completion date; outcome; reassignment and exception history. |
| Event participation | Event; registrant; attendee or guest; registration date; attendance status; cancellation; ticket or fee; reminder status; form responses; explicit requests; follow-up status. |
| Preference or consent | Communication purpose; channel; opt-in or opt-out state; effective date; source; evidence; scope; expiration if applicable; last changed by; effect on delivery eligibility. |
PROS translation
PROS remains the relationship model. These are recognizable CRM functions that may implement it; the product's exact labels may differ.
| PROS stage | Common CRM terms | What the system must do |
|---|---|---|
| Purpose | Campaign, fund, appeal, event, project, or named journey | Stores why the work exists, who owns it, its timing, intended outcome, source codes, and completion definition. |
| Message | Email or text campaign, letter, mailing, form, event invitation, call script, or personal communication | Stores the actual communication, sender, channel, version, schedule, personalization, and intended response. |
| People | Saved report, query, group, segment, audience, or static list | Selects relevant constituents from current record, gift, relationship, event, preference, and activity data. |
| Delivery | Email or text send, mailing batch, form publication, event reminder, or assigned personal outreach | Records who was eligible, who was excluded, what was sent, when it was sent, and delivery or failure evidence. |
| Reaction | Gift, reply, form submission, registration, attendance, preference change, bounce, click, call, meeting, or explicit request | Preserves the constituent, source, time, context, and specific meaning of what happened. |
| Next Action | Workflow action, record update, activity, assigned task, exception queue, handoff, or intentional no-action result | Applies the approved response rule and records ownership, timing, outcome, and reason. |
| Learn | Saved report, dashboard, scheduled report, cohort analysis, or exported dataset | Compares intended and observed outcomes using reproducible criteria, periods, exclusions, follow-through, and unresolved exceptions. |
Across every trail
Trail-specific proof
These are the differentiating requirements vendors should be prepared to demonstrate for each developed relationship journey.
| Trail | Distinctive capability requirements |
|---|---|
| Gift Acknowledgment | Gift and payment status; fund, campaign, appeal or source and form attribution; donor and household identity; receipt and acknowledgment status; first, cumulative, recurring, memorial, and milestone gift criteria; same-day and next-business-day workflow timing; relationship-owner-based task assignment; exception queue; Starting Donor handoff. |
| Starting Donor | First-gift or 24-month-return report criteria; journey start and completion dates; scheduled ten-touchpoint workflow; group and audience refresh; do-not-contact and channel suppression; second-gift transaction trigger; recurring-gift status change; handoff and duplicate-journey prevention. |
| Sustaining Donor | Active recurring-gift status; installment history; amount, frequency, payment, failure, cancellation, and anniversary changes; rolling 12-month personal-contact report; assigned relationship owner; activities and completed tasks; preservation of other interests and relationships. |
| Storytelling | Interest or content-topic fields; context and consent; selected response option; source form or link; email or text history; passive activity versus explicit reply; one related story recommendation; task or receiving-journey handoff with source attribution. |
| Pray for Proxima | Prayer communication preference and consent; saved audience or live report; routine email versus urgent text eligibility; sensitive activity protection; reply or form-response options; urgent and personal-care task timing; opt-out and do-not-contact enforcement. |
| Newsletter | Quarterly saved audience; email campaign and version; person-level continuation-link or form attribution; send, delivery, bounce, open, click, reply, and preference records; review-period reports; explicit request tasks; cross-trail handoff without duplicate communication. |
| Events | Event and campaign setup; registrant, guest, and attendee records; reminders; cancellation and attendance status; next-business-day workflow branches; explicit request and preference capture; one assigned follow-up task; no-response completion; Event Invitations preference. |
Show the work
Use the same sample constituents throughout the demonstration. For every scenario, identify whether the capability is native, configured, integrated, custom-built, or unavailable; name the required package or module; and show the constituent record, workflow state, staff work, report, and export—not only slides or feature names.
| Scenario | What we need to see |
|---|---|
| Constituent and household record | Create two individual constituent records in one household and one related organization. Show relationship roles, shared and individual contact information, custom fields, assigned relationship owner, complete timelines, duplicate detection, and how a merge preserves gifts, activities, preferences, and identifiers. |
| First gift through acknowledgment | Enter an online first gift assigned to a fund, campaign, appeal or source, and form. Show the transaction on the constituent timeline, receipt and acknowledgment status, first-gift qualification, same-day automated acknowledgment, one assigned personal follow-up task when criteria require it, and the handoff to the Starting Donor journey. |
| Dynamic audience with final suppression | Build a saved report or dynamic group for a specific interest and giving condition. Change a constituent so they enter automatically, then apply an email opt-out or do-not-contact flag and show that they remain relevant to the group but are excluded from the send with a reportable reason. |
| Different reactions, different responses | Using one communication, show an email open, an explicit reply, a gift, a form request, and a bounce as separate records. Demonstrate the workflow criteria and resulting record update, task, handoff, suppression, or intentional no action for each. |
| Accountable activity and task | Create a call or meeting task from an explicit request. Show assignee, due date, priority, originating interaction, reminder, reassignment, completion outcome, and overdue reporting. Confirm that completing or reassigning the task does not change the constituent's relationship owner. |
| Recurring gift change | Show a new recurring gift, successful installments, a failed payment, a changed amount, and a cancellation. Demonstrate which fields and workflow triggers change, how communication preferences are respected, and how duplicate stewardship journeys are prevented. |
| Event registration through follow-up | Register a constituent with one guest, send a reminder, record attendance separately for registrant and attendee, capture an explicit follow-up request, create one appropriate task, and show normal completion for an attendee who made no request. |
| Reproducible reporting | Build and save a report joining constituent criteria with gifts, campaign or appeal, communications, reactions, activities, task completion, exclusions, and exceptions. Change the measurement period, drill to source rows, schedule delivery, and export the complete result with stable IDs. |
| Integration and recovery | Create or update a constituent, transaction, preference, and activity through the documented API or import tools; show duplicate and validation handling, event or webhook availability, failure logs and retry behavior, and a complete export usable without proprietary decoding. |
Vendor response format
For each requirement, classify the response as Native, Configured, Integrated, Custom, or Unavailable. State the product area, package level, configuration work, external service, implementation owner, expected maintenance, reporting access, API access, and export availability.
Equivalent capability is welcome. Fragile custom code, hidden workflow state, delayed preference enforcement, incomplete exports, vendor-only routine changes, or a feature shown only in a separate product must be identified as a limitation and ongoing cost.
Source basis
This brief expresses common technical implications of the approved PROS Operating Model, Core Operating Model, applicable Playbooks, and maintained Trail Guides. Where this addendum and a governing Playbook conflict, the Playbook governs.