Built for teams running multiple parallel pipelines

When a sales team runs more than one motion, the pipeline primitive is what the CRM has to get right.

A team running new logo plus expansion plus renewal plus services plus partner-sourced deals has five pipelines, not one. Each pipeline has its own stages, its own conversion math, its own forecast methodology, and its own reporting shape. Most CRMs treat pipelines as a secondary primitive on top of a single deal object. The result is a mess of record types and workarounds. This page is for teams whose motion needs the pipeline primitive to be first class.

Start free trial See pricing
What this audience is actually dealing with

The pains that bring buyers here.

Teams running multiple parallel pipelines hit a set of friction points on legacy CRMs. The pipeline primitive is often a secondary concept on top of a single deal object with record types and page layouts simulating the shape. The friction compounds as pipelines diverge over time. The pains below are what multi-motion sales leads describe when they ask why their CRM feels like it is fighting them.

Pipelines are record types, not first class

The shape is simulated with layouts and workflows.

Most CRMs treat multiple pipelines as record types on the deal object: a page layout per record type, a workflow per record type, a report per record type. The simulation works until the pipelines diverge enough to need genuinely different field sets, different stage math, different automation. At that point the record type model collapses into a maintenance tax that nobody wants to own.

Stage math is global

The same stage definitions apply across every pipeline.

Pipeline stages (Qualified, Proposal, Negotiation, Closed Won, Closed Lost) are often defined globally rather than per pipeline. For a team running new logo plus renewal plus expansion motions, the stage shapes are different: renewal has no proposal stage, expansion has an existing-contract stage, services has a scoping stage. The global stage model forces awkward naming or empty stages per pipeline.

Forecast rollup assumes one pipeline

The exec dashboard is a single number from a single primary pipeline.

Forecast rollup at most CRMs sums across all deals on all pipelines as one number. Teams with multiple pipelines need separate forecasts per motion (new logo forecast, renewal forecast, expansion forecast) and a combined view that respects the different methodologies. The single-number dashboard misses the per-motion story that the exec review actually needs.

Reporting is pipeline-blind

Comparing conversion rates across pipelines takes a BI tool.

Standard CRM reports render well for a single pipeline (stage-to-stage conversion, win rate, cycle time). Comparing those metrics across pipelines (new logo win rate versus expansion win rate, renewal cycle time trend versus services cycle time trend) requires cross-pipeline joins that most CRMs do not render natively. The ops lead exports to Google Sheets or stands up a BI tool for the comparison.

Automation is per record type

Workflow logic duplicates across pipelines with slight variations.

Automations at most CRMs duplicate per record type (per pipeline), each with slight variations. The team ends up with 15 flavors of "stage change notification" doing nearly the same thing, which is a maintenance burden. The right pattern is pipeline-aware automations where one flow handles multiple pipelines with conditional logic on the pipeline attribute.

Permissions do not scope by pipeline

The renewal pipeline needs different access than the new logo pipeline.

Access control at most CRMs is global (all deals or by owner) rather than per pipeline. The renewal team needs to see renewal pipelines plus the new logo deals that closed and are approaching renewal. The partner-sourced pipeline needs partner visibility. The services pipeline needs delivery team access. Scoping access per pipeline requires either record ownership workarounds or custom permission logic.

The pipeline-first object model

How Strkr treats the pipeline primitive.

The cards below walk Strkr's pipeline-first design: pipelines as first-class objects with their own stage definitions, their own forecast methodology, their own automation surface, and their own permission scope.

Pipelines as first-class objects

Each pipeline has its own field set, stage flow, and automation.

A pipeline in Strkr is a first-class object, not a record type. Each pipeline has its own field set (the renewal pipeline has renewal-specific fields that new logo does not need), its own stage flow with per-pipeline stage definitions, its own default automation set, and its own permission scope. The ops lead can create a new pipeline (partner-sourced, services, product-led) without a page layout gymnastics session.

Per-pipeline stage math

Each pipeline has its own stage probabilities and forecast methodology.

Stages define per pipeline. Each stage carries its own weighted probability for the pipeline it belongs to. Commit, best case, and upside stage mapping applies per pipeline. Renewal does not need a proposal stage; expansion has an existing-contract stage; services has a scoping stage. The stage math is clean per motion rather than a one-size-fits-all compromise.

Forecast per pipeline plus combined view

Separate forecasts per motion with a roll-up for the exec review.

Forecast methodology (commit, best case, upside, pacing, risk-adjusted) runs per pipeline. The exec dashboard shows per-pipeline forecasts and a combined view that respects the different methodologies. The combined roll-up uses the right methodology per pipeline rather than averaging across. Pacing math compares against the pipeline-specific day count.

Cross-pipeline reporting native

Compare conversion, win rate, cycle time across pipelines.

The report builder treats pipeline as a dimension. Reports like "win rate by pipeline over 4 quarters," "stage conversion rate by pipeline," "cycle time trend by pipeline" render natively. For richer comparisons the warehouse connector pushes to BigQuery, Snowflake, or Redshift where the BI tool handles cross-domain joins (sales plus product usage plus billing).

Pipeline-aware automation

One flow handles multiple pipelines with conditional logic.

Flow authoring treats pipeline as a conditional attribute. A single "stage change notification" flow handles all pipelines with conditional logic on the pipeline attribute to route notifications correctly. The 15-flavor duplication pattern that record-type CRMs produce is replaced with pipeline-aware flows that stay maintainable as pipelines are added or changed.

Per-pipeline permissions

Scope visibility and edit rights per pipeline.

Access control scopes per pipeline. The renewal team sees renewal pipelines plus the new logo deals approaching renewal. The partner-sourced pipeline gives partner visibility. The services pipeline gives delivery team access. The claims-based permission model with row-level security handles this scoping natively.

Common multi-pipeline shapes

How teams actually structure their pipelines.

The cards below walk the multi-pipeline shapes teams run most often. Each shape names the pipelines involved and the structural reasons the team chose that shape.

B2B SaaS: new logo + expansion + renewal

Three motions, three pipelines, three forecasts.

B2B SaaS teams commonly run three pipelines: new logo (new accounts, full sales cycle), expansion (upsell and cross-sell to existing accounts), and renewal (contract renewal with renewal rate target). Each has its own stage flow, its own forecast methodology, and its own ownership (AE on new logo, CSM on expansion, renewal manager on renewal). The three-pipeline shape is the SaaS standard.

Services firm: new client + retainer + project

Three motions covering new business, ongoing retainers, project work.

Services firms (agencies, consulting shops, professional services) commonly run three pipelines: new client (new logo acquisition with scoping), retainer (ongoing monthly retainer sales), and project (one-off project engagements). The retainer pipeline has longer cycle time and different stage shape than new client; project is faster and more transactional.

Partner-led: direct + partner-sourced + co-sell

Three channels with different attribution and commission math.

Teams running partner-led motions commonly run three pipelines: direct (sales team closes directly), partner-sourced (partner brings the lead, sales team closes), and co-sell (joint partner and sales team selling together). Each has different attribution, different commission math, and different partner visibility requirements. The three-pipeline shape maps the channel structure cleanly.

Multi-product: product A + product B + product C

Each product line has its own pipeline with product-specific stages.

Teams selling multiple product lines (hardware plus software plus services, or distinct product families) run a pipeline per product with product-specific stages, product-specific pricing, and sometimes product-specific sales teams. The pipeline-per-product shape keeps the stage flow clean for each product rather than forcing a one-size-fits-all stage set.

Enterprise + mid-market + SMB

Three pipelines by segment with different cycle times and stages.

Teams running segmented go-to-market run a pipeline per segment: enterprise (long cycle, multiple stakeholders, custom contracting), mid-market (medium cycle, standard contracting), SMB (short cycle, self-serve-plus-sales). Each segment has different stage flow, different forecast cadence, and different automation. The segment-per-pipeline shape avoids forcing enterprise processes onto SMB deals.

Lead gen + sales + customer success

Three pipelines spanning the full customer lifecycle.

Some teams model the full customer lifecycle as three pipelines: lead gen (marketing-sourced leads progressing to qualified), sales (qualified leads progressing through the sales cycle to close), and customer success (post-close customer motions including onboarding, expansion opportunities, renewal). The three-pipeline shape covers the lifecycle without forcing all stages into a single pipeline.

How to set up multi-pipeline cleanly

The design decisions that keep pipelines maintainable.

The cards below are the design decisions that keep a multi-pipeline install clean over time. Each one is a choice the ops lead makes during pipeline design that pays dividends across years.

Decide the pipeline criterion up front

Motion, segment, product, channel: pick one axis.

Pipeline design should pick one axis as the splitting criterion: motion (new logo versus renewal), segment (enterprise versus SMB), product (product A versus product B), or channel (direct versus partner). Mixing axes creates a combinatorial explosion of pipelines. Pick the axis that produces the most structural difference in the sales process and run pipelines on that axis.

Keep stage count tight per pipeline

Five to eight stages per pipeline is the sweet spot.

Each pipeline should have five to eight stages. Fewer than five stages lose granularity; more than eight stages add complexity without proportional value. The stages should map to concrete sales milestones with observable transitions. Vanity stages (stages that nobody actively uses but exist for reporting) should be removed; they distort the forecast math.

Define the forecast methodology per pipeline

Commit, best case, upside, risk adjustment specific to the motion.

Forecast methodology varies by pipeline. New logo typically uses commit, best case, and upside with risk adjustment per stage. Renewal often uses a different methodology (expected renewal rate times contract value, with downside scenarios for at-risk accounts). Services uses different pacing math. Define the methodology per pipeline during setup rather than defaulting to one methodology across all.

Share automations where logic is common

Pipeline-aware flows beat duplicated per-pipeline flows.

Where automation logic is common across pipelines (stage change notification, task creation on activity completion, email reply tracking), build pipeline-aware flows with conditional logic on the pipeline attribute. Where logic genuinely differs (renewal-specific churn signal flow, services-specific scoping task flow), build pipeline-specific flows. The hybrid pattern keeps maintenance manageable.

Scope permissions during pipeline setup

Who sees which pipeline, who edits what, at setup time.

Permission scope decisions get easier if made during pipeline setup rather than retroactively. For each pipeline define: which roles see the pipeline, which roles can edit deals, which roles can edit stage definitions and automations. The claims model handles the fine-grained scoping. Retroactive permission cleanup is painful; up-front setup is clean.

Review the pipeline portfolio quarterly

Add, deprecate, split, merge pipelines as the motion evolves.

Pipeline needs change as the business evolves. A new product line may need a new pipeline; a sunset product may need an archived pipeline; a merging motion (sales plus services together) may collapse two pipelines into one. Review the pipeline portfolio quarterly with the ops lead, sales leader, and relevant pipeline owners. The pipeline-first object model makes additions and changes cheap.

Head-to-head

Strkr pipeline primitive versus the typical CRM pipeline primitive.

Below is the comparison between Strkr's pipeline-first object model and the typical CRM approach of simulating pipelines with record types.

Feature Strkr Typical CRM pipeline primitive (record type based)
Pipeline primitive First-class object with its own fields and stages Record type on the deal object with page layouts
Per-pipeline stage definitions Each pipeline has its own stage flow Varies; often requires workarounds
Per-pipeline forecast methodology Commit/best/upside configurable per pipeline Usually one methodology across all pipelines
Cross-pipeline reporting Pipeline as a native dimension in reports Dashboard composition; depth varies
Pipeline-aware automation One flow handles multiple pipelines with conditional logic Flows duplicate per record type
Per-pipeline permissions Claims-based with row-level security scoped per pipeline Varies; often record ownership workarounds
Pipeline-specific field sets Each pipeline has its own custom fields Shared field set with pipeline-conditional visibility
Pipeline deprecation workflow Archive pipeline with record migration Varies; often manual
Pipeline count No practical cap Varies; some vendors cap pipelines per tier
Mobile view per pipeline Pipeline-aware mobile layout Varies; often single mobile layout
How teams use Strkr

How multi-pipeline teams actually ran their install.

The common thread across teams running multi-pipeline well: they defined the pipeline criterion up front, kept stage counts tight per pipeline, built pipeline-aware automation, and reviewed the pipeline portfolio quarterly. The playbooks below are live customer motions.

B2B SaaS, 48 reps

Ran new logo + expansion + renewal pipelines after collapsing from 12 record types.

A 48-rep B2B SaaS team ran on a prior CRM with 12 deal record types representing various pipeline shapes. The record type sprawl was unmaintainable: 12 page layouts, 12 workflows per common pattern, 12 report shapes. The team migrated to Strkr with a clean three-pipeline design (new logo, expansion, renewal) and consolidated the 12 record types into 3 pipelines with pipeline-specific fields and stages. The maintenance burden dropped substantially.

Services firm, 32 account managers

Added a project pipeline mid-year after seeing the retainer pipeline fatigue.

A 32-AM services firm ran new client plus retainer pipelines for 6 months. Mid-year the ops lead noticed that one-off project engagements (6 to 12 week scoped work) were being forced into the retainer pipeline, which distorted both pipelines' forecast math. The team added a project pipeline with scoped-work-specific stages. The pipeline addition was clean because pipelines are first-class objects in Strkr.

Partner-led mid-market, 38 reps

Direct + partner-sourced + co-sell pipelines with partner visibility scoped per pipeline.

A 38-rep mid-market team running partner-led motion built three pipelines: direct, partner-sourced, and co-sell. Partner visibility scoped per pipeline through the claims model: partners saw their partner-sourced and co-sell deals, direct pipeline stayed internal. Attribution and commission math ran per pipeline. The structural clarity made partner compensation disputes rare.

Multi-product, 55 reps

Pipeline per product line with pipeline-aware automation shared across pipelines.

A 55-rep multi-product team built four pipelines, one per product line. Automation that was common across products (stage change notifications, task creation on activity completion) ran as pipeline-aware flows with conditional logic. Automation specific to a product (hardware shipping notification, software provisioning flow) ran pipeline-specific. The hybrid pattern kept the automation surface manageable at 20 total flows rather than 80.

The CRM with pipelines as a first-class primitive.

Start a 14-day Strkr trial with the pipeline-first object model, per-pipeline forecast methodology, and pipeline-aware automation turned on.

Start free trial See pricing
Common questions

What buyers in this bucket ask most.

How does Strkr treat multiple pipelines differently from a typical CRM?

Pipelines in Strkr are first-class objects, not record types on the deal. Each pipeline has its own field set, its own stage flow with per-pipeline stage definitions, its own default automation set, and its own permission scope. This differs from CRMs that simulate multiple pipelines with record types on a single deal object, where each record type is a page layout plus a workflow plus a report shape duplicated per pipeline. The pipeline-first object model keeps the install maintainable as pipelines diverge over time; the record type model collapses once pipelines need genuinely different fields and automations.

How many pipelines can a team have in Strkr?

There is no practical cap. Teams can run as many pipelines as the motion requires. The common shapes we see: 2 pipelines (new business plus renewal), 3 pipelines (new logo plus expansion plus renewal, or new client plus retainer plus project), 4 to 6 pipelines (multi-product or multi-segment teams), and occasionally 8 to 12 pipelines (very segmented enterprise teams). The practical guidance is to pick one axis (motion, segment, product, or channel) and run pipelines on that axis rather than mixing axes which creates a combinatorial explosion. Pipeline count beyond 10 to 12 usually indicates mixed axes and benefits from consolidation.

Can forecast methodology differ per pipeline?

Yes. Commit, best case, upside, pacing, and risk adjustment configure per pipeline. New logo pipelines typically use commit/best/upside with risk adjustment per stage. Renewal pipelines often use a different methodology (expected renewal rate times contract value, with downside scenarios for at-risk accounts). Services pipelines use different pacing math because the sales cycle shape is different. The exec dashboard shows per-pipeline forecasts and a combined view that respects the different methodologies, rather than averaging across pipelines with mismatched math. This is one of the structural reasons teams move from CRMs with global forecast methodology to the pipeline-aware model.

How does cross-pipeline reporting work?

The report builder treats pipeline as a native dimension. Reports like "win rate by pipeline over 4 quarters," "stage conversion rate by pipeline," "cycle time trend by pipeline" render natively. The ops lead can filter, group, and pivot by pipeline in the same way they filter by rep or by segment. For richer comparisons across sales plus product usage plus billing or support, the warehouse connector pushes to BigQuery, Snowflake, or Redshift where the BI tool handles the cross-domain joins. The pattern most multi-pipeline teams run: native report builder for pipeline-specific and cross-pipeline comparisons inside the sales domain, warehouse plus BI tool for cross-domain joins.

Can I share automations across pipelines or do I duplicate them?

Share them. Flow authoring treats pipeline as a conditional attribute. A single "stage change notification" flow handles all pipelines with conditional logic on the pipeline attribute, so the notification routes correctly without duplicating the flow per pipeline. The 15-flavor duplication pattern that record-type CRMs produce is replaced with pipeline-aware flows that stay maintainable. Where logic genuinely differs (renewal-specific churn signal flow, services-specific scoping task flow), build pipeline-specific flows. The hybrid pattern (shared where common, pipeline-specific where unique) keeps the automation surface manageable.

What about permissions scoped per pipeline?

Permissions scope per pipeline through the claims model with row-level security. The renewal team sees the renewal pipeline plus the new logo deals approaching renewal. The partner-sourced pipeline gives partner visibility to partner-sourced deals only. The services pipeline gives delivery team access to the services pipeline. Field-level permissions can scope further: specific fields visible to specific roles across all pipelines or specific pipelines. The scoping is first-class and does not require record ownership workarounds. The ops lead configures permissions during pipeline setup rather than retroactively.

Also built for

Related audiences.

CRM for sales ops RevOps leaders CRM package catalog

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing