Dokan adds layered status fields on top of WooCommerce. Vendors live as WordPress users with the seller role and an enable_selling meta flag plus a vendor row carrying publish for approved or pending for under review. Sub orders are shop_order posts with WooCommerce statuses but tied to a vendor through seller_id. Withdrawal requests live in dokan_withdraw with statuses of 0 for pending, 1 for approved, and 2 for cancelled. Three different admin screens handle three different review workflows.

SleekView Kanban reads each of these sources directly. Point the board at vendors and approval becomes a single drag from Pending to Approved. Point it at sub orders and you see one vendor's fulfillment queue, grouped by WooCommerce order status. Point it at withdrawals and the finance team works Pending requests left to right, dragging each to Approved as the payout batch clears. Cards can show vendor name, payout method, requested amount, order total, customer, and the date the record was created.

Dragging a withdrawal from Pending to Approved fires the same Dokan API calls the admin uses, which updates the database, deducts the vendor's available balance, and triggers Dokan's notification hooks so the vendor sees the change in their dashboard immediately. Vendor approvals call dokan_post_to_vendor and the seller dashboard activates. Sub order status changes fire woocommerce_order_status_changed exactly as a normal WooCommerce order would.

A Dokan marketplace is really three businesses stacked on top of each other: a vendor signup funnel, a fulfillment operation per vendor, and a finance department running weekly payout batches. The default Dokan admin gives each of those a separate screen, and each screen is a list. That works fine for a marketplace with ten vendors and twenty orders a day.

It breaks the moment the marketplace passes a hundred active vendors and a few hundred daily orders, because the operational team is suddenly trying to track three separate queues across three separate admin sections, each with its own filters, its own pagination, and its own visual style. Mistakes compound. Vendor applications go unreviewed for days.

Payout batches get processed but never marked Approved in Dokan, so vendor balances drift. Sub orders sit in Processing for a particular vendor because nobody noticed the cluster. A board view per source surfaces the right queue at the right time.

Vendor approvals are a column to drain. Withdrawals are a column to clear weekly. Sub orders are a vendor-scoped board the support team can pull up per ticket.

The underlying database stays exactly as Dokan maintains it. The interface finally fits a real marketplace operations team.