How to Manage Multiple Sales Pipelines in DenchClaw

Most CRMs assume you have one pipeline. If you're running enterprise sales alongside a self-serve motion, managing partnerships alongside direct deals, or running separate processes for different products, that single-pipeline model breaks down fast. DenchClaw handles multiple pipelines natively—each with its own stages, fields, and views, all queryable together when you need a unified picture.

When You Need Multiple Pipelines#

You probably need multiple pipelines if:

• You have different sales motions (enterprise vs. SMB, inbound vs. outbound)
• You sell multiple distinct products with different stages and timelines
• Your sales team handles both new business and renewals/expansions
• You track partnerships separately from direct sales
• You're building a services business alongside a product business

A single pipeline with "type" tags can work at small scale, but as volume grows, mixed-type pipelines become confusing. Stages that mean something for enterprise deals are irrelevant for self-serve, and vice versa.

Approach 1: Multiple Objects (Recommended for Very Different Processes)#

The cleanest approach is separate objects for truly different pipelines.

"Create an enterprise_deals object with stages: Discovery, Technical Evaluation, 
Business Case, Legal Review, Closed Won, Closed Lost. 
Fields: Deal Name, Company, Primary Contact, Deal Value, ARR, 
Contract Length (enum: 12mo, 24mo, 36mo), Close Date, Owner."

"Create a self_serve_deals object with stages: Trial, Active Trial, 
Upgrade Prompted, Converted, Churned. 
Fields: User Email, Plan (enum: Free, Pro, Team), MRR, Trial Start Date, 
Converted At."

Each object has its own kanban, its own views, its own action fields. They live side by side in your DenchClaw sidebar. Switch between them instantly.

When to use this approach: When the two processes are genuinely different—different fields, different stages, different workflows, different owners. The overhead of maintaining two objects is worth the clarity.

Approach 2: One Object with a Pipeline Field (Recommended for Similar Processes)#

If your pipelines share most of their structure but need different views:

"Create a deals object with a Pipeline field (enum: Enterprise, SMB, Partnership). 
Stages are shared: Discovery, Proposal, Negotiation, Closed Won, Closed Lost."

Then create separate saved views for each pipeline:

"Create a view called 'Enterprise Pipeline' in my deals object: 
Pipeline = Enterprise, Stage not in (Closed Won, Closed Lost), 
kanban by Stage."

"Create a view called 'SMB Pipeline' in my deals object: 
Pipeline = SMB, Stage not in (Closed Won, Closed Lost), 
kanban by Stage."

Each view shows its own kanban, filtered to the relevant pipeline. You can also create a "All Open Deals" view that shows everything in one place.

When to use this approach: When the pipelines are similar—same stages, mostly same fields—but you want to manage them separately day-to-day.

Step-by-Step: Setting Up Two Pipelines#

Here's the practical setup for a company running both enterprise and SMB pipelines:

Step 1: Create or update your deals object with a Pipeline field.

If you already have deals in a single pipeline, ask: "Add a Pipeline field (enum: Enterprise, SMB) to my existing deals object and set it to 'SMB' for all existing deals."

Step 2: Create stage-specific views for each pipeline.

"Create three views in my deals object: 'Enterprise Active' (Pipeline = Enterprise, Stage not Closed), 'SMB Active' (Pipeline = SMB, Stage not Closed), and 'All Active' (Stage not Closed)."

Step 3: Create per-pipeline kanban boards.

"Set the Enterprise Active view to kanban layout with Stage as the kanban field." "Set the SMB Active view to kanban layout with Stage as the kanban field."

Step 4: Set up pipeline-specific reports.

"Show me enterprise pipeline value vs SMB pipeline value this month." "What's the win rate for enterprise deals vs SMB deals this quarter?"

These cross-pipeline queries are the advantage of keeping both pipelines in the same object—you can compare them with a single query.

Managing Cross-Pipeline Deals#

Sometimes a deal starts as SMB and becomes an enterprise deal. Or a partnership opportunity turns into a direct sales opportunity. Handle transitions cleanly:

"Move the Acme Corp deal from my SMB pipeline to Enterprise. 
Update the Pipeline field, change the Stage to Discovery (reset), 
and add a note that it was originally an SMB inbound."

Because it's the same object, the deal history stays intact. You can see the full record of the deal regardless of which pipeline it was in at any point.

Building a Unified Dashboard#

The real power of managing multiple pipelines in DenchClaw is the ability to see them together:

"Build a pipeline overview dashboard showing: 
total open deal value by pipeline (bar chart), 
deal count in each stage for each pipeline (grouped bar chart), 
closed revenue this month broken down by pipeline (pie chart), 
and a table of the top 5 open deals by value across all pipelines."

This dashboard becomes your weekly pipeline review artifact. No exporting, no BI tool—just a SQL query against your local DuckDB.

Partnership Pipeline: A Special Case#

Partnerships often need their own pipeline with different fields:

"Create a partnerships object with stages: Identified, Intro Made, 
Agreement Drafted, Active Partner, Inactive. 
Fields: Partner Name, Company, Type (enum: Referral, Integration, 
Co-Marketing, Reseller), Est. Revenue Impact (number), 
Partner Owner (text), Agreement URL (url), Notes."

Partnerships evolve slowly, so the kanban here is less about daily management and more about visibility. Set a weekly reminder to review the "Intro Made" and "Agreement Drafted" stages for partners that may need follow-up.

Renewals Pipeline#

If you sell subscriptions, renewals are a distinct sales motion that deserves its own pipeline:

"Create a renewals object with stages: Healthy, At Risk, In Negotiation, 
Renewed, Churned. 
Fields: Customer Name, Company, Current ARR, Renewal Date, 
Account Owner, Health Score (number), Churn Risk (enum: Low, Medium, High), 
Notes."

Pull from your customer list: "Create renewal entries for all customers whose subscription expires in the next 90 days."

This becomes your Customer Success pipeline—separate from new business, but queryable alongside it for full revenue visibility.

Frequently Asked Questions#

How many pipelines can DenchClaw support?#

As many as you need. Each object is independent, and DuckDB has no meaningful limit on the number of tables. You could have 20 distinct pipeline objects if your business requires it.

Can different team members own different pipelines?#

Yes. Add an Owner field to each pipeline object and filter views by owner. In team settings (with Dench Cloud sync on the roadmap), each person sees their pipeline without seeing others' deals by default.

How do I consolidate revenue reporting across pipelines?#

Use a SQL query that unions across your pipeline objects:

"Show me total closed revenue this quarter across all my pipeline objects."

DenchClaw handles cross-object queries by referencing multiple views in DuckDB.

What's the right moment to split into two pipelines vs using one?#

When the two processes need materially different stage names or fields, split them. If they share 80%+ of their structure, use one object with a pipeline filter. The operational clarity of seeing "Enterprise Pipeline" vs "SMB Pipeline" separately is often worth the minor overhead even when the schemas are similar.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →