A proposal that only describes what is included can create false confidence. If the boundaries are unclear, your team may discover too late that key work was never part of the plan.

This shows up frequently in website rebuilds, CRM implementations, and integration projects. Data cleanup may be assumed to be your responsibility. Training may only cover admins. Reporting setup may be limited. Post-launch support may not be included at all.

That does not necessarily mean the proposal is bad. It does mean the edges need to be visible before you say yes.

Better question: What are we explicitly not getting in this phase?

Some proposals stay so high-level that no one can tell what drives the timeline or cost. Others sound overly certain before requirements, data quality, stakeholder alignment, or integrations have been tested.

Both are risky. A vague estimate makes planning difficult. An overly confident one can make leadership feel safe too early.

If you are replacing a CRM, for example, the estimate should reflect real complexity: migration quality, duplicate records, custom fields, reporting expectations, integrations, and how many departments need to be involved. If none of that shows up in the estimate logic, the number may not mean much.

Better question: What assumptions drive this estimate, and what would increase cost or timeline?

This is one of the easiest places to get burned. If a vendor cannot clearly explain what data you own, what you can export, and how hard it is to leave later, that is a real risk.

A nonprofit may not plan to switch systems anytime soon. That is not the point. The point is whether you can leave without chaos if priorities change, costs rise, service drops, or the platform no longer fits.

If the answer sounds vague, overly reassuring, or dependent on professional services, keep asking.

Better question: What can we export, in what format, and how difficult is it to leave if we need to?

Integrations are often where real complexity lives. If the proposal treats them like a quick add-on without discussing dependencies, monitoring, failure points, or ownership, take that seriously.

A payment sync, CRM connection, SSO setup, or finance integration can look small in a proposal and still create major downstream issues if it fails quietly. The risk is not just technical. It affects reporting, staff trust, donor experience, and operational follow-through.

When a proposal says an integration is straightforward, that may be true. It may also mean the hard parts have not been surfaced yet.

Better question: What depends on this integration, what happens if it fails, and how will it be monitored?

Many proposals focus on launch and skip what happens after. But your staff will live with the system long after implementation ends.

If the proposal does not address ongoing admin work, reporting upkeep, permissions, training, and process ownership, you may be underestimating the true cost.

This matters especially in small and mid-sized nonprofits, where the person managing the platform is often also doing several other jobs. A system that looks efficient on paper can become a drain if it requires constant manual cleanup, workarounds, or specialized knowledge to maintain.

Better question: What ongoing work will our staff own after launch, and how much time should we expect it to take each month?

Security language can sound reassuring without being specific. If a proposal only says the vendor is secure, ask what that means in practice for your team, your data, and your configuration.

For example, are role-based permissions included by default? Are audit logs available? Is MFA standard? What requires setup by your team? What requires a higher pricing tier? What happens if staff turnover is frequent and access management gets messy?

Good security is not just a vendor claim. It is part of how the system will actually be used and governed.

Better question: What security controls are included by default, what requires configuration, and what costs extra?

A polished demo can hide weak fit. If the vendor only shows the happy path, you may never see the reporting, permissions, exceptions, or day-to-day workflow details that matter most.

This is especially risky when your team is impressed by the interface but has not seen the parts they will actually depend on. A donor acknowledgment workflow, a grant reporting process, a case note review, or a finance handoff may be where the real fit gets tested.

A good demo should help your team evaluate reality, not just admire the product.

Better question: Can you show our real workflows end to end, including permissions, reporting, and exceptions?