A Peer Guide for Citygate Network Leaders
A technology and AI strategy guide for rescue missions — building deliberate systems that free your team for the work only humans can do.
What This Guide Is
Most technology decisions in this sector happen reactively — under deadline pressure, with limited expertise, and without a clear evaluation framework. This guide is for organizations that want to change that. It's built around one central argument: the right technology, chosen deliberately, doesn't just solve operational problems. It systematically buys back your team's time — time that can only be invested one way: in the human connections that drive lasting mission impact.
About EGM
Everett Gospel Mission has served Snohomish County, Washington since 1961 — ten program locations, a small development team, and the same technology pressures every peer organization in this network knows firsthand. This guide comes from our experience navigating those pressures. It's peer-to-peer sharing of what we learned — and what we're building toward.
The Opportunity
There is a version of technology adoption that looks like progress but functions as burden. New platforms get added to existing workflows. Integrations are configured but never validated. Staff build workarounds. Knowledge accumulates in the memory of whoever set things up — and leaves when they do. The technology is present. It just doesn't serve.
The organizations making the most meaningful strides in donor stewardship aren't necessarily the ones with the largest technology budgets. They are the ones who have learned to ask better questions before committing — and to build with the long game in mind. They treat their CRM not as a database to maintain but as the foundation everything else stands on. They build integrations that actually close the loop. They govern their AI tools deliberately, before those tools begin governing their workflows by default.
Every development professional pays it. Hours each week spent pulling reports manually, reconciling data across platforms that don't speak to each other, re-entering information that should have synced automatically, searching for a giving history before a call that starts in ten minutes. This isn't incidental — it's structural. The systems most organizations inherited were built for data management. They were not built to surface relationship opportunities.
The cost isn't just efficiency. It's presence. According to AFP research, personalized donor stewardship — knowing a donor's history, their motivations, and the right moment to reach out — increases re-engagement rates by 20–35% compared to generic outreach. That isn't a technology result. It's a human result, made possible by technology that handles the mechanical layer so the human can show up fully informed and genuinely present.
Before
Tuesday morning, 8:15 a.m.
Three major donor calls today. The development officer spends 90 minutes pulling giving histories from DP, checking the contact log across three tabs, cross-referencing Constant Contact engagement data manually (it doesn't sync back), and looking up the last board discussion about the downtown campus. By the time the first call starts, the brief is incomplete, the day is already behind, and the officer is scattered rather than present.
After
Tuesday morning, 8:50 a.m.
Three briefing documents waiting — each one a single page pulling from every DP table, the contact log, CC open history, and volunteer records. Giving trajectory, last conversation, two suggested talking points, and a recommended ask based on RFM signals. Ten minutes to review. First call at 9. The development officer arrives at that conversation fully present — not assembling facts, but ready to listen.
Penelope Burk's research at Cygnus Applied Research found that personalized acknowledgements referencing a donor's specific giving history increase the probability of the next gift by 15–25%. That personalization doesn't require more staff hours. It requires the right data, organized and surfaced by technology — so the humans writing those letters can focus on the one thing technology can't provide: genuine relationship.
Consider the compounding effect. Donors notice when someone calls knowing their history. They notice when a thank-you letter references what they care about, not a mail-merge field. They notice when they're treated as a relationship, not a data point. These moments convert annual givers into planned giving prospects. They sustain engagement across economic cycles. They build the deep trust that produces major gifts. None of this happens in the absence of good technology infrastructure — because without it, the humans doing relationship work are too buried in administrative overhead to do it well.
AI tools that would have required a dedicated engineering team three years ago are now accessible to organizations of any size. Tools that draft stewardship communications, score constituent engagement, identify lapsed-donor patterns, and surface major gift candidates are available today. According to the M+R Benchmarks Study, nonprofits integrating automated donor communication touchpoints are seeing consistent gains in retention and engagement.
The question isn't whether to engage. It's how to engage deliberately — with clear governance, a defined role for human judgment, and the same evaluation rigor you'd apply to any other technology decision.
About This Guide
Generic technology advice misses the conditions rescue missions operate under. Small teams wearing multiple roles. Thin IT capacity. Regionally concentrated donor bases built on personal relationship. Program complexity spanning multiple service types tracked against shared constituent records. Faith-based stewardship expectations that shape how every resource is used and reported.
And most of us don't choose our systems from scratch. We inherit them. When we do evaluate something new, it usually happens under pressure — a contract deadline, a staff departure, a feature gap that's finally become untenable. This reactive posture is the operational reality of small organizations doing serious work. But it has a real cost — and that cost is increasingly visible as the tools available to us become more capable. This guide is our attempt to share what a more deliberate approach looks like.
Evaluating a New CRM
Use the blind spots to calibrate what you're likely to miss. Then use the question bank groups to structure your vendor conversations. Read the DP case study for a real-world account of what to watch for.
Already Deployed, Managing Friction
Use the case study to recognize your own patterns, then apply Group 3 questions to assess whether your current friction is manageable or structural. Review the "egm's Response" section for ideas.
AI Is the Immediate Question
Ground yourself in the human connection argument first, then use Group 4 to build a governance framework, then read the full AI section for the augmentation-versus-automation distinction and deployment checklist.
Need a Practical Tool Now
The evaluation worksheet on the last page consolidates the key questions into a single printable tool. Complete it as a team before any vendor meeting or internal planning session.
A Note on DonorPerfect
DonorPerfect is named throughout as a real-world case study — not as the subject of a complaint. The friction we document traces largely to our own evaluation failures. A DP account manager reading this should recognize most of what we describe as accurate, if incomplete. The lessons are transferable to any CRM evaluation.
Section 1 · Five Blind Spots
These patterns describe assumptions that felt reasonable at the time and became costly in practice. Each one describes a class of question that almost every rescue mission fails to ask during technology evaluation.
Blind Spot 01
The Assumption
We watched vendor demonstrations and saw the platform handle every scenario cleanly. We left with confidence.
The Reality
Demos are built for the happy path. Daily work is edge cases: the donor who gave to three funds in one transaction, the report needing rolling 12-month logic, the form field that should appear only for certain gift amounts. We didn't bring any of those scenarios — and they were exactly where the friction lived.
Carry Forward
Ask vendors to run your three messiest real-world examples — not their best-prepared ones. The gap between a polished demo and a typical Monday morning is where the real evaluation happens. Bring your edge cases. That's where the truth is.
Blind Spot 02
The Assumption
We asked whether the platform could perform specific functions. We received affirmative answers and moved forward.
The Reality
A system can technically "support" reporting and still lack OR logic across filter categories, dynamic rolling-window filters, and customizable column sets — all three of which we needed in production. The question is never just "can it do X." It's "how does it do X, and what breaks when we need X and Y simultaneously?"
Carry Forward
For every capability that matters, ask to see the failure mode. The workaround hiding behind the "yes" is where the long-term cost lives. "How does it do X?" reveals more than "Does it do X?" — and it's the question vendors least expect.
Blind Spot 03
The Assumption
When a vendor described an integration with an email platform or matching tool, we understood that to mean the systems would share data.
The Reality
Many integrations are directional. Our email integration pushed contacts out but engagement data never returned to donor records. Our employer matching tool placed a widget on the form but produced no reporting data inside our systems. We had integrations that created blind spots we didn't discover until we tried to build on top of them.
Carry Forward
For every integration, ask specifically: what data flows in each direction, and what data never returns to the system of record? "Connected" and "synced" are not the same thing — and the difference has direct consequences for what you can measure and act on.
Blind Spot 04
The Assumption
We thought of reporting as one capability among many — important, but comparable to gift entry or acknowledgements in evaluation priority.
The Reality
Reporting is the infrastructure everything else runs on. When it fails, you can't measure impact, identify lapsed donors, or make the case to your board. Reporting limitations compound faster than any other constraint. In our five-month audit, 18 of 61 support cases — nearly 30% — traced back to reporting. The friction wasn't obscure: it was OR logic, rolling date windows, and sortable analytics. Routine monthly needs the native system couldn't meet without workarounds.
Carry Forward
Spend disproportionate time testing reporting. Bring ten real monthly reporting scenarios to every vendor evaluation. Treat any limitation as load-bearing — it will compound with every additional capability you try to build on top of it. The ability to answer questions about your donor base is the prerequisite for every sophisticated stewardship strategy.
Blind Spot 05
The Assumption
We budgeted time and attention for implementation. When the system went live, we considered that phase closed.
The Reality
Go-live is the beginning of the real work. Configuration decisions made at setup compound for the life of the database. Workarounds built in Year One become institutional dependencies. In our audit, 10 of 61 cases had no documented resolution — resolved by phone with no written record. Every one of those represents knowledge that lives only in someone's memory and leaves when they do. That's not a platform problem. That's a Year One investment we didn't make.
Carry Forward
Budget explicitly for Year One operations, not just implementation. Ask at setup: which configuration decisions are permanent? Document every workaround before the person who built it leaves. The most valuable Year One investment isn't learning the system's features — it's documenting what the system can't do, and how your team is working around it.
The Thread Running Through All Five
Every blind spot points to the same underlying shift: from evaluating technology on what it does today to evaluating it on what it costs your team over three years. The platform that looks cheapest at the demo can become the most expensive at Year Three when workarounds, undocumented resolutions, and integration gaps have all compounded into a full-time tax on relationship work. The questions in Section 2 are built to surface that cost before you sign — not after.
Section 2 · The Question Bank
Organized into four decision groups. These aren't just evaluation questions — they're the prerequisite to building the foundation that makes the innovations in Section 3 possible. Under each question: why it matters and what a thin answer reveals.
Group 01
Internal assessment — before any vendor conversation begins
Document what you run, not what you wish you could. OR logic, rolling windows, and cross-field conditions are primary evaluation criteria. If you can't answer this before the demo, the vendor will define the scope for you.
A thin answer is a name. A substantive answer is a knowledge base that survives their departure. "Nothing is documented" is your highest-priority technology problem, regardless of which platform you're evaluating.
List every connected platform. For each: does data go out, come in, or both? Uncertainty about directionality is already a live blind spot in your reporting.
Complexity you underestimate in evaluation becomes the limitation you hit hardest in production. Be honest about your edge cases before anyone sells you on clean-looking demos.
Account for realistic turnover, onboarding time, and the cost of knowledge concentrated in a single person. The system that works at launch but not after a staff change is a system that doesn't actually work.
Group 02
Platform and partnership — the questions that reveal what a demo never shows
About the Platform
Test this with a real scenario before signing. If OR conditions require custom SQL, that workaround needs to be rebuilt and re-explained every time staff changes — turning a platform limitation into a permanent knowledge dependency.
A specific test for rolling-window logic. This is a recurring monthly need for most development teams. "Approximated with a workaround" is not native support — it's a recurring staff cost.
The answer determines the entire scope of what automation is actually possible when you connect third-party tools. This constraint is invisible at purchase — and it was one of the most consequential discoveries in our audit.
A setup mistake with immutable field types requires building a new field and migrating all historical data. The cost compounds with every year of database age. Know this before Year One configuration begins.
Anything that doesn't log back creates a blind spot that undermines every personalization strategy built on top of the data. Quantify what you're willing to manually reconcile before you sign.
Giving USA data shows DAF giving has grown consistently for over a decade. If your platform doesn't support DAF Pay natively, those transactions happen outside your form — and potentially outside your attribution data. Processor lock-in is a compounding problem.
About the Partnership
Ask before you sign. A thin answer is "you can export it." A substantive answer specifies format, completeness of historical interaction data, and the timeline and cost of a full migration out.
Enterprise SLAs and small-shop reality are often different things. Ask peer organizations using the same platform at a similar scale before relying on what the vendor tells you.
An evasive answer tells you what the roadmap actually looks like for organizations your size. A real example is evidence of a feedback loop that works.
For platforms where direct vendor support is limited, the third-party ecosystem is effectively your support floor. A thin ecosystem means you're concentrated on one source of help.
The question vendors least want to answer is often the most important to ask. An evasive answer tells you something real about the relationship you're entering.
Group 03
Contract, implementation, and Year One — the phase where most organizations lose ground
Year-one pricing frequently doesn't represent Year-three reality. Add-ons that appear optional at purchase often become operationally necessary. Understand the full 5-year cost before signing any 1-year contract.
Implementation partners and vendors often operate with separate accountability. Know who you call when things go wrong, and what recourse exists, before you need to exercise it.
Ask the implementation team to identify every decision that is hard to undo. Field architecture and data structure choices fall in this category in most platforms. Get the answer in writing before setup begins, not after Year One.
Every workaround living only in one person's memory is a single point of failure — and a direct tax on your team's capacity for donor work. Build a shared knowledge base in Week One, not Year Three.
Not every limitation warrants a platform change. Define the threshold in advance. Without a clear standard, friction accumulates silently until it's structural — and by then, it's much harder to address.
Custom SQL and workaround reports are only as durable as the staff who understand them. A working report is not the goal — a documented, maintainable report is.
Group 04
Governance questions most organizations haven't fully worked through — but need to before deployment
AI tools outside your CRM create the same integration-directionality risk as any other third-party connection. Outputs that don't write back to your donor record aren't in your institutional memory.
Augmentation: a human reviews the output and acts. Automation: the tool acts without that step. Both have appropriate uses, but the distinction must be deliberate. Organizations that drift into automation without deciding to create new risks in place of the old ones.
Wrong outputs in relationship-based fundraising have real costs to donor trust that don't show in an efficiency metric. Define accountability before deployment, not after the first error surfaces.
Your donors' trust transfers to every vendor you connect them to. Understand the consent implications and what the contract actually says before any donor data touches an AI system.
A thin answer is trust in the tool. A substantive answer names a specific person, a review cadence, and a written override standard that exists before deployment, not after the first problem.
Section 3 · A Grounding Case Study
Between December 2025 and April 2026, egm submitted 61 support cases to DonorPerfect. We weren't cataloguing grievances — we were trying to understand our platform. When we reviewed all 61 cases at the end of that period, we found 25 distinct platform limitations, 10 cases with no documented resolution, and a pattern running through almost every friction point: we hadn't thought to ask the right questions at evaluation. Not vendor failures — evaluation failures. The lessons are ours to own, which means they're transferable.
DonorPerfect is a donor management platform with a long track record in smaller and mid-sized nonprofits. It offers gift entry, donor records, acknowledgement workflows, reporting, and a connected giving platform (GiveCloud) for online donations. For an organization with straightforward reporting needs and limited integration complexity, it is functional, accessibly priced, and reasonably supported. It's not a bad product. It's a product with a defined capability range — and we didn't fully understand that range before we needed it.
| Friction Area | What We Found in Practice | What to Ask at Evaluation |
|---|---|---|
| Reporting logic | 18 of 61 cases — nearly 30% — fell here. The Report Center lacks OR logic across filter categories, rolling consecutive-month filters, and real-time sortable analytics. Routine monthly queries required custom SQL or manual Excel exports that only work as long as the staff who built them are still there. | "Show us a dynamic rolling 12-month consecutive-giving filter. Can we use OR logic across different field categories? What happens when we need to exclude soft credit records from a giving report?" |
| Integration directionality | Email platform (Constant Contact) integration is one-way — DP pushes contacts out, but engagement data never returns to donor records. GiveCloud receipt emails are logged nowhere in DP. Employer matching tool (Double the Donation) places a widget on the form but produces no data inside our systems. No matching activity, no request status, no ROI visibility. | "For each integration: what data flows in each direction? What touchpoints never return to the system of record? Show us where a Constant Contact open rate appears on a donor record." |
| API automation limits | DP's SmartActions do not fire when records are updated via API. Any third-party platform updating donor records via API — including the volunteer management system, POINT — bypasses all automation triggers. Invisible at purchase. Only surfaces when automation becomes a goal. | "Do automation triggers fire on API-based record updates, or only through the UI? Show us what breaks when data comes in from outside the platform." |
| Field architecture | Field types cannot be changed after creation. A text field cannot become a dropdown; single-select cannot become multi-select (native multi-select is not supported). A setup mistake requires building a new field, migrating all historical data, and retiring the original — a cost that compounds with every year of database age. | "Which configuration decisions made during implementation are permanent? What is the actual process and cost to correct a field type error two years in?" |
| Knowledge fragility | 10 of 61 cases had no documented resolution — resolved by phone with no written record. Custom SQL templates, calculated fields, and workarounds built by support staff exist only in individual memory, not in any system egm owns. Each undocumented resolution is a potential repeat ticket — and a direct cost to the team's capacity for relationship work. | "What do we own after implementation? What is documented, where does it live, and what is our plan when the staff member who configured this system is no longer here?" |
egm's Response
The limitations documented above didn't become the end of the story — they became the brief. egm is actively developing AI-assisted workflows using Claude Code and Claude Cowork that directly address each friction point, not as replacements for DonorPerfect but as an intelligent layer alongside it that does what DP's native architecture cannot. The goal in each case is the same: restore time to the humans doing relationship work.
Response to · Reporting Logic
Python scripts query the DP XML API with full OR/AND/NOT logic, rolling consecutive-month windows, and hard credit isolation by record type. Results paginate past DP's 500-row limit and output to Excel, CSV, or narrative PDF. Every report is saved with a timestamp and query parameters — creating the audit trail DP's native system doesn't provide. Routine monthly queries that previously required support intervention now run in minutes. Cowork schedules the recurring ones automatically.
Response to · Integration Directionality
egm operates across five systems: DP, GiveCloud, Constant Contact, POINT, and Double the Donation. A monthly Claude workflow pulls engagement data from all five and writes summary scores back to DP UDF fields — making email engagement, volunteer hours, and employer matching status visible on the donor record without rebuilding any integration. The Double the Donation API bridge surfaces matching ROI for the first time, flagging donors who gave but never submitted a matching request.
Response to · API Automation Limits
Because SmartActions don't fire on API updates, a weekly Claude workflow syncs POINT volunteer activity to DP donor records directly — volunteer hours, engagement scores, and program participation are now visible alongside giving history. A separate weekly workflow surfaces LYBUNT donors with dynamic rolling date logic and generates one-paragraph stewardship briefs per donor, including a suggested ask amount based on individual giving history. Staff review and send every note.
Response to · Knowledge Fragility
Every DP limitation identified in this audit is now documented in LIMITATIONS.md — a living file that includes the limitation, the Claude workaround, and the query logic. Every recurring report exists as a saved prompt in a shared Claude project accessible to all staff. A Cowork workflow drafts a resolution summary after any support session. When a new team member joins, they can ask Claude for egm-specific answers before opening a support ticket.
Response to · Recurring Donor Payment Failures
GiveCloud sends payment expiration emails to donors but no staff notification exists (confirmed in our audit). A weekly Claude Cowork workflow queries the GiveCloud API for failed and expiring plans, cross-references DP to flag primary recurring donors, and generates a Monday "at-risk" list with draft re-authorization language per donor for staff review. According to Bloomerang's 2024 data, recurring programs see 10–15% annual churn from payment failures alone — and outreach within 48 hours recovers approximately 60% of those donors vs. 20% after 30 days. Staff make every call. The workflow ensures they know who to call before the window closes.
Companion Document
The workflows above are drawn from egm's internal AI Integration Proposal — a 17-page implementation document covering 8 specific use cases, a comprehensive data risk and mitigation framework, innovative capabilities beyond the audit findings (constituent 360, donor sentiment analysis, predictive signals, mission-to-donor storytelling), and a phased implementation roadmap. Available to Citygate Network members through egm upon request.
Section 4 · A Short Word on AI
The organizations using AI tools most effectively in relationship-based fundraising aren't using them to replace human connection. They're using them to create the conditions for more of it — and better quality versions of it. That framing matters. It reframes AI not as a labor-replacement technology but as a presence-recovery technology: tools that handle the mechanical layer so your people can be fully available for the work that only humans can do.
AI capabilities are entering the nonprofit technology stack faster than most governance frameworks can keep up with. According to research from Double the Donation, 84% of donors are unaware their employer matches charitable gifts. A well-built AI workflow that identifies eligible donors who haven't submitted a matching request — and surfaces them to a development officer — can effectively double the value of those gifts. That's not automation. That's intelligence in service of relationship. We're actively working through these questions at egm. What follows is the framework we're applying.
Before deploying any AI capability, one question determines everything that follows: should a human be in the loop here? For anything touching donor relationships, the answer is almost always yes. But "human in the loop" isn't a binary. It describes a spectrum — and understanding where each workflow sits on that spectrum is the foundation of responsible AI deployment.
AI Augmentation
Claude handles preparation, synthesis, and drafting. A human staff member reviews, refines, and acts. The relationship and the decision always belong to your team. The AI makes the human more capable — not less present.
Examples from egm's Integration Work
AI Automation
Claude executes a complete task on a schedule — querying data, generating a report, exporting a file — without requiring staff to initiate or monitor each run. Frees human attention entirely from the mechanical loop.
Examples from egm's Integration Work
The Right Question
Before deploying any capability: should a human be in the loop here? For anything touching donor relationships, the answer is almost always yes. Augmentation should be the default. Automation is an exception that requires an explicit decision — not an assumption you drift into because the tool makes it easy. The distinction matters most in the moments it's hardest to enforce: when a workflow is running smoothly and the temptation is to remove the review step that was always the point.
The augmentation/automation distinction isn't just philosophical — it determines how you staff and structure each workflow. A development officer using Claude to prepare for a major gift call is augmentation. The same officer not reviewing a Claude-generated acknowledgement before it goes out is automation — even if it wasn't designed that way. The drift from one to the other is the primary governance risk in AI deployment for small nonprofit teams.
Consider the difference in practice. A Claude-generated lapsed donor brief tells a development officer: this person gave $500 annually for four years, then stopped 14 months ago; their last contact note mentions a recent job change; their email open rate is still high. The officer reads it, makes the call, and connects. That's augmentation — the technology amplified the human's preparation. The result is a conversation that feels personal because the officer arrived informed, not because a script was followed.
Now consider what happens if that brief is never reviewed — if the officer relies on it without verification, or if it's generated with a data error that goes unnoticed. Wrong gift total, wrong lapse date, wrong attribution. The consequences aren't hypothetical. In relationship-based fundraising, a single misinformed interaction can damage a relationship that took years to build. The review step isn't friction. It is the governance.
Before any AI workflow goes live, three governance structures need to be in place. These aren't technical requirements — they're accountability requirements, and they apply equally to a simple weekly report and a complex donor briefing system.
Structure 01
For each use case, one named staff member is accountable for reviewing outputs before any action is taken. Not "the team" — a specific person. Their name is documented alongside the workflow description. When they leave, ownership transfers explicitly, not by default.
Structure 02
Every quarter, audit which workflows have shifted from augmentation toward automation — where review steps have been quietly removed, or where outputs are being acted on without verification. The scope of AI access should only expand through deliberate decision, not gradual drift.
Structure 03
For every workflow that produces a recommendation or output, document in advance: what is the escalation path when staff judgment contradicts the AI's output? "Override it" is not a sufficient policy. The standard should name who decides, how it's documented, and what triggers a review of the underlying workflow.
A Note on Data and Donor Trust
Every AI workflow that touches donor data raises a stewardship question: does our use of this data match what our donors would expect if they knew about it? For faith-based organizations, this isn't just a legal or compliance question — it's a mission question. Before deploying any AI capability that processes donor information, review your data use policies, understand your vendor's terms regarding model training, and consider whether a brief disclosure in your privacy policy reflects the integrity your donors have come to expect from you.
Full Implementation Resource
egm's companion implementation document includes a ten-risk data and security framework (covering API key exposure, bulk write operations, PII handling, scope creep, and donor trust), a five-phase implementation roadmap from foundation setup to innovative capabilities, and specific governance policies for each workflow category. Available to Citygate Network peer organizations through egm upon request. Contact through the Citygate Network member directory.
Section 5 · Closing
We want to close with honesty about our own unfinished thinking. These are questions egm has raised internally and not yet fully answered. We share them because intellectual honesty is what makes peer guides worth reading — and because the field benefits when organizations name the edges of their own clarity.
What it looks like when this works.
The rescue mission that has done this well looks different in a specific way. The development officer isn't behind before the day starts. Lapsed donors are surfaced before they're fully gone — not in a year-end scramble, but in a weekly digest that takes ten minutes to review. Recurring givers whose cards quietly fail get a personal call within 48 hours, not a form email three months later when the lapse finally shows up in a report. The pre-call brief for a major gift conversation takes five minutes to prepare and contains information from every system the organization uses. Acknowledgements reference something specific and true about each donor. The board report tells a story instead of delivering a table.
None of this requires a large team. None of it requires an IT department. It requires a foundation built deliberately — the right questions asked at evaluation, the right configurations documented at setup, the right governance structures in place before AI capabilities go live. That foundation is what this guide is trying to help build. The relationship work is still yours. The technology just needs to stay out of its way.
egm intends to bring these questions into the Citygate Network community — not as an expert presenting answers, but as a peer organization sharing work in progress. We're proposing a dedicated technology working group within the Citygate Network for member organizations actively navigating CRM decisions, AI governance, and integration strategy. If you're working through any of these questions at your organization and would be willing to share what you're learning, we'd welcome the connection.
To request egm's full AI Integration Proposal, to share your own organization's experience with the questions in this guide, or to express interest in a Citygate Network technology peer group: reach out through the Citygate Network member directory, or flag your interest at the next annual conference.
Appendix · One-Page Evaluation Worksheet
Print and complete as a team in vendor meetings or internal planning sessions. H = verified and tested · M = heard but not verified · L = needs testing before signing.
| Question | Our Answer / Current State | Vendor Answer | Confidence (H/M/L) | Follow-Up? |
|---|---|---|---|---|
| What reporting do we run monthly — does it require OR logic or rolling date windows? | — | — | — | — |
| How does this platform handle field type changes after initial setup? | — | — | — | — |
| What integrations are one-way vs. two-way — and what data never returns? | — | — | — | — |
| Do automations fire on API updates, or only through the UI? | — | — | — | — |
| What donor-facing giving experience do we need? (DAF, matching, mobile wallets) | — | — | — | — |
| What's our staff capacity to maintain this system over 3–5 years? | — | — | — | — |
| What happens to our data if we leave — format, completeness, migration cost? | — | — | — | — |
| How is pricing structured over 5 years, including add-ons and fee change history? | — | — | — | — |
| What's the real support experience for an org our size and ticket volume? | — | — | — | — |
| How will we document workarounds before the person who built them leaves? | — | — | — | — |
| For any AI tool: is this augmenting a human decision — or replacing one? | — | — | — | — |
For estate, planned (tax mitigation) and legacy giving, vehicle donations, and corporate partnerships, contact:
We’re grateful to receive donations of food, clothing, and toiletries alongside financial support. Every item below helps us serve up to 300 people each night across snohomish county.
Click here to view the list of items needed most.
It’s easy to do good when you use our Amazon wishlists to help us get our most current needs. You select what you want to purchase from our list, pay for it through amazon and ship it right to our door.
Help us be ready for the men, women, and children at the Mission and in the community who come here every day for desperately needed help.
We are grateful to receive donations of food, clothing, and toiletries alongside financial support.
