GiveWP stores each donation as a give_payment post in wp_posts, with extensive metadata in wp_postmeta and structured rows in the dedicated donation meta tables introduced in GiveWP 2.20. Each donation carries a status like pending, processing, publish for complete, refunded, failed, cancelled, abandoned, or revoked. The default donations list is sortable but inherently linear, which obscures the funnel of money moving through your gateway every day.

SleekView Kanban reads the same donation records you would query with give_get_payments or the GiveWP REST API. Pick the donation status field as the group column and every record becomes a card grouped under its current state. Cards can show the donor name, donation amount in your form currency, donation form title, gateway, and recurring flag so the finance team and the fundraising team see the same context without switching screens.

Dragging a card between columns calls give_update_payment_status, the same function GiveWP uses internally to transition donations. Donor receipts fire, recurring donations adjust their next billing date, and any add-on listening for the status change runs normally. A failed gateway charge that resolves manually moves to Complete with a single drag, and the underlying donation post updates its status, amount, and metadata in one consistent step.

Fundraising teams measure success in relationships kept alive over years, but the daily work is granular and urgent. A first-time donor whose receipt fails to arrive on day one becomes a lapsed donor by month three. A major gift that nobody acknowledges within 48 hours becomes a board complaint by week's end.

The default GiveWP donations list treats every record as a row in a chronological log, which is correct for accounting but blind to the actual rhythm of acknowledgment, stewardship, and recovery work. Failed gateway charges sit in the same view as completed gifts. Recurring sustainer renewals scroll past at the same speed as one-time gifts that need personal handwritten cards.

A kanban board reorganizes the same data around the actions a fundraising team takes. The Complete column becomes the thank-you queue, sortable by gift size. The Failed column becomes the recovery queue, sortable by donor lifetime value.

Refunded becomes a reconciliation queue for finance. The data is the same data GiveWP already stores. The view finally matches the work and dragging a card is both the operational step and the database update at once.