FluentCRM Funnels is the automation layer of FluentCRM. The data sits in well-indexed custom tables: fc_funnels for funnel definitions, fc_funnel_sequences for the ordered steps, fc_funnel_subscribers for the per-contact join, and fc_funnel_metrics plus the broader email-event tables for delivery and engagement. The schema is the same shape that FluentCRM's automation engine queries directly, so direct SQL access is safe and fast.

The default FluentCRM Funnels UI is good at visualising the funnel as a diagram and at editing one step at a time. It's less good at the row-level questions ops needs to answer: which contacts are stuck on step 3 of the onboarding funnel, which funnels have the worst drop-off at a specific step, which contacts completed a funnel inside the last 30 days. Those queries exist as automation conditions but don't render as a workspace where ops can scan, filter, edit and bulk-act.

SleekView reads the funnel custom tables directly, joins funnels to their steps and to the per-contact progression, and surfaces the cross-cutting queries as saved views. Stuck-contact triage becomes one filter; drop-off audit becomes a step-by-step count column; bulk-advancing or removing contacts from a step becomes an inline operation that writes through FluentCRM's API where supported so the same automation hooks fire.

Automation builders are great for designing funnels and not great for running them. The data that matters for running a funnel (which contacts are stuck, which steps are bleeding the most contacts, which contacts completed in the last 30 days) lives in the funnel's custom tables and it lives there as rows, but the builder visualises it as a diagram. The diagram is the right tool for design and the wrong tool for ops.

SleekView's contribution is to surface the underlying rows as a real workspace where the questions ops actually asks have direct answers. Stuck-contact triage becomes one filter. Per-step drop-off becomes a column.

Bulk-advancing after a step fix becomes an inline operation. For lifecycle teams running on FluentCRM, the table is the diff between a funnel they iterate on quarterly and a funnel that just runs. For automation engineers debugging why a contact didn't progress, the join across funnel sequences and the event log reproduces the journey from data without screen-recording.

The custom-table schema FluentCRM Funnels already uses makes all of this possible at scale, the missing piece was an admin surface that treats the data as a workspace.