Show support where the fundraising workflow broke

A fundraising software support request should show the exact step that failed, what you expected, what happened, and when. Add the minimum account and environment details needed to find the issue, with sensitive information removed.

Give support a problem they can investigate rather than a long collection of screenshots without a clear question. One well-scoped request can also become the record your own team uses to verify the fix.

Name the failed action and its effect

Write a short subject that identifies the workflow and failure. In the first paragraph, say whether donors cannot complete a gift, staff cannot access a record, or a report differs from the source. Include the campaign or operational deadline when it changes the urgency.

Separate observed facts from your theory. If the page stopped loading after a setting changed, state both observations without declaring that the setting caused the failure. If only one donor reported a problem, do not describe it as an outage affecting every donor.

Mozilla's bug-writing guidance recommends precise reproduction steps and a clear distinction between expected and actual results. That is a general software-reporting discipline you can apply to a fundraising task without asking your team to become developers.

Write the shortest safe reproduction

List the route through the workflow, including the starting URL, relevant role, selections, and exact failing action. Include the visible error text when you have it. Say whether the problem occurs every time, sometimes, or only in the original report.

Use a preview or test environment for repetition when available. Do not repeatedly submit live payments or send real acknowledgments just to build the request. If the only evidence comes from a real gift, provide its identifier through the vendor's appropriate support channel and describe what you observed.

For a browser issue, note the browser and version, operating system, device, and whether the page is hosted or embedded. Givebutter's sign-in troubleshooting article includes checking another browser, private browsing, devices, and connection conditions. Those are provider-specific troubleshooting suggestions; follow your vendor's own guidance and organizational access rules before changing settings.

Send enough context to locate the event

Include a compact evidence packet:

• Account or organization identifier.
• Campaign, form, event, or record identifier.
• Time of the failure with timezone.
• Expected result and observed result.
• Reproduction steps and frequency.
• Redacted screenshot or short recording of the failing step.
• Troubleshooting already attempted and its outcome.

A timestamp without a timezone can send support to the wrong portion of a log. A record identifier helps distinguish several gifts by the same donor. A screen showing the entire dashboard may expose more data than the investigation needs.

Crop images to the relevant area and remove unrelated donor names, addresses, payment details, access tokens, and browser tabs. Never include passwords, secret API keys, complete card numbers, or login links that grant access. If support needs a diagnostic file, ask for the approved secure collection route and scope before sharing it.

Keep operational consequences concrete

Explain what is blocked and what still works. If staff can use a verified alternative form, say so; if no safe alternative exists, say that. Avoid promising donors a workaround you have not checked.

The existing donation-form readiness checks can help you describe the failing stage. A connected fundraising export problem needs the specific missing relationship or field, rather than a broad statement that the file is wrong.

State what help you need next: confirmation of a known issue, a safe workaround, investigation of a specific record, or guidance on an unclear setting. Support can assess priority from the impact and deadline without invented counts or dramatic language.

Keep the request and resolution together

Use the vendor's official support route and keep follow-up evidence in the existing conversation. Givebutter's contact guidance explains its own available channels and how to review past conversations. Check the corresponding route for your provider rather than relying on a contact copied from an old document.

Name one person on your team to answer questions and relay updates. If another teammate discovers new evidence, add it to that same incident record instead of opening a competing explanation.

When support reports a fix, repeat the affected safe workflow and compare the result with the expectation in your original request. Record the verification date, any remaining limitation, and the staff action required. Close the request when the problem is resolved or the agreed next step has an owner.