Skip to main content

​
Settings → Configuration

The Configuration tab is where you define how PILLAR interprets your business. Every report, score, signal, and board export is shaped by what you set here.
Who can access this tab: CRO/CEO, RevOps, and PILLAR Admin roles only. Configure once during onboarding — settings can be adjusted at any time thereafter without requiring a re-sync.
The tab contains four sub-sections, each covering a distinct configuration area:

​
Business Definitions

These settings define the language PILLAR uses across every calculation, label, and export. Set these first — they affect everything downstream.

​
Fiscal Year Start Month

The calendar month your fiscal year begins. Affects quarter labels (Q1, Q2, etc.), period-over-period comparisons, and board report date ranges. Default: January
If your fiscal year starts in July, PILLAR’s Q1 = July–September, Q2 = October–December, etc. Board reports and renewal windows will all use this calendar.
Decision question: “Does your fiscal year start in January, or a different month?”

​
ARR Definition

How PILLAR measures Annual Recurring Revenue. This drives the ARR figure shown on the dashboard KPI, in board reports, and in territory P&L. Default: Contracted ACV (the value on the signed contract / opportunity) Decision question: “Do you use signed contract ACV, trailing 12-month revenue, or MRR × 12?”

​
Churn Definition

What counts as churn for NRR/GRR calculations and churn risk scoring. Default: Revenue churn (any reduction in ARR from a customer)
This setting directly affects your NRR and GRR figures. If you switch from revenue churn to logo churn after data has been loaded, historical NRR calculations will change. Align on this definition before your first board export.
Decision question: “Do you count only full cancellations, or do downsells count as churn too?”

​
Base Currency

The currency used for all ARR displays, territory P&L, and exports. Default: USD Only change this if your organization primarily operates in a non-USD currency. Multi-currency support (per-account currency with conversion) is on the roadmap — this setting controls the display denomination for all aggregated metrics.

​
Renewal Window

How many days in advance of a contract end date PILLAR begins surfacing the account in renewal workflows — the triage board, renewal risk signals, and upcoming renewal KPIs. Default: 90 days Decision question: “When does your team typically start engaging a renewal — 30 days out? 90? 180?”

​
Quota Type

How quota attainment is measured for your sales team. Affects the quota attainment KPI, territory P&L projections, and rep performance metrics. Default: ARR Decision question: “Is your sales team on ARR quota, TCV, revenue, or activity?”

​
Segments & Thresholds

​
Segment ARR Boundaries

PILLAR scores and triages accounts differently based on their segment. These boundaries define which ARR range maps to SMB, Mid-Market, and Enterprise. Defaults: SMB below 50KARR,Mid−Market50K ARR, Mid-Market 50K–500K,Enterpriseabove500K, Enterprise above 500K
For K-12 and EdTech organizations, it’s common to map to district-level segments rather than pure ARR. Example: Districts (Enterprise), Schools (Mid-Market), Teachers (SMB) — then set the ARR cutoffs to match the revenue distribution in your portfolio.
Decision question: “How do you define SMB vs Mid-Market vs Enterprise — by ARR band, by headcount, or by account type?”

​
Signal Thresholds

Eight thresholds control when PILLAR fires a signal. Each threshold has a global default, and each can be overridden per organization.
June–August is summer break. Students and teachers are not using the product, and contacts are not checking email. If you use standard thresholds, PILLAR will generate a high volume of “no activity” and “low usage” signals every summer — most of which are false alarms.Recommended adjustment:
  • Raise days_since_activity from 30 → 60 or 90 during summer months
  • Raise usage_pct_low threshold to account for expected summer drop-off
This can be adjusted seasonally — set it higher before summer, reset in September.
For product-led growth or self-serve products, users operate more autonomously. Low direct engagement with your team does not necessarily indicate risk.Recommended adjustment:
  • Raise usage_pct_low — users at the 25th percentile may still be healthy in a PLG model
  • Lower days_since_activity is less meaningful when the product is self-serve; consider disabling this signal or raising the threshold significantly
Enterprise accounts have longer natural engagement cycles — quarterly business reviews instead of weekly check-ins.Recommended adjustment:
  • Raise days_since_activity to 45–60 days
  • Widen the renewal window (set in Business Definitions) to 180+ days
Decision question: “Does your business have seasonality or usage patterns that would cause the standard thresholds to generate noise? K-12 summer, PLG self-serve, long enterprise cycles?”

​
Deal Stages

​
Stage Probabilities

Maps each of your CRM’s opportunity stage names to a close probability. This drives:
  • Weighted pipeline calculations on the dashboard and board report
  • Forecast confidence scoring
  • Pipeline health signals
PILLAR comes with default templates for Salesforce and HubSpot. After loading a template, customize any stage name or probability that doesn’t match your org’s definition. How to configure:
  1. Click the template that matches your CRM to pre-fill standard stage names
  2. Review each stage — does the probability reflect your team’s actual win rate at that stage?
  3. Add any custom stages your CRM uses that aren’t in the template
  4. Save — changes take effect immediately on all weighted pipeline metrics
Common overrides: “Technical Validation” → 70%, “Legal Review” → 80–85%, “Verbal Commit” → 90%, “Contract Sent” → 95%. If your team uses a stage name that implies a near-certain close, make sure the probability reflects that.
Decision question: “Pull your CRM’s full stage picklist. For each stage, what close probability does your team actually believe it implies?”

​
Expansion Taxonomy

Tells PILLAR how to distinguish expansion opportunities from new business in your CRM. Default: PILLAR uses forecast category to infer expansion intent — no field required. If your CRM has an Opportunity Type field (or similar) that explicitly tags expansions:
  1. Set the Field name (e.g., opportunity_type, deal_type)
  2. Set the Expansion values — the picklist values that identify expansion (e.g., Expansion, Upsell, Cross-sell)
PILLAR will then use that field directly for expansion reporting, expansion signals, and the expansion pipeline view. Decision question: “Do you have an Opportunity Type or similar field that distinguishes expansion from new business? What are the picklist values for expansion?”

​
Contact Role Patterns

PILLAR automatically identifies executive sponsors and champion contacts by matching contact titles against pattern lists. The defaults cover standard enterprise titles. Default executive patterns: VP, SVP, EVP, CTO, Chief, Director, President, C-Suite Default champion patterns: Champion, Advocate, Power User, Project Lead Only change these if your target market uses unusual title conventions. For example, in K-12, Curriculum Director and Superintendent carry executive authority — consider adding those patterns if they’re not being caught by the defaults.

​
Pipeline Weights

​
Forecast Category Weights

Defines what percentage of face value PILLAR assigns to each forecast category when calculating weighted pipeline. PILLAR defaults: Override any category where your team’s definition implies a different close probability. For example, if your “Commit” means 100% certainty (not ~95%), set it to 100. If your “Best Case” historically closes at 35%, set it to 35.
These weights affect every weighted pipeline number across the platform — dashboard KPIs, board reports, territory P&L, and quota attainment projections. Confirm these with your CRO or VP of Sales before saving, as changes are immediately reflected everywhere.
Decision question: “When a rep calls something ‘Commit’, what close probability does that actually imply on your team? 85%? 95%? 100%?”

​
CRM Stage Mappings

Maps your CRM’s raw stage names to PILLAR’s canonical forecast categories (Commit, Best Case, Upside, Pipeline, Closed Won, Closed Lost). This runs before the weight lookup — a stage name that isn’t mapped falls back to 15% weight. How to configure:
  1. Click the template for your CRM (Salesforce / HubSpot / Microsoft Dynamics) to pre-fill standard mappings
  2. Add any custom stages your org uses
  3. Verify every stage is mapped — unmapped stages default to 15% (Pipeline weight)
  4. Save
If your CRM uses forecast categories natively (Salesforce Forecast Category field), the connector maps those directly. CRM stage mappings here are a fallback for orgs that don’t use native forecast categories, or want to override the CRM’s category assignments.
  1. Business Definitions first — fiscal year and ARR definition affect how everything else is calculated
  2. Segments & Thresholds — set ARR boundaries before scoring runs so accounts land in the right tier on the first pass
  3. Deal Stages — load your CRM template, customize stage probabilities, confirm expansion taxonomy
  4. Pipeline Weights — align forecast category weights with your CRO before saving; confirm stage mappings cover all active stages
After saving all four sections, PILLAR re-applies the configuration to all existing scores and pipeline metrics within the next 15-minute scoring cycle. No re-sync required.

​
Frequently Asked Questions

Yes — all Configuration settings can be changed at any time. Changes take effect within the next 15-minute scoring cycle. There is no re-sync or data reload required. Be aware that changing ARR definition or churn definition will alter historical metric calculations, which can affect board report comparisons.
PILLAR uses global defaults for everything. The defaults are calibrated for a typical B2B SaaS company with a January fiscal year, USD ARR, 90-day renewal window, and standard Salesforce stage names. If your org matches those defaults, you may need minimal or no configuration.
At minimum: RevOps (knows the CRM data model and stage definitions) and CRO or VP Sales (owns the forecast category definitions and quota type). The fiscal year and ARR definition should be confirmed with Finance if possible — these affect board-level reporting.
These are org-level settings — they apply to every user in your organization. A change made by RevOps to the fiscal year start month will immediately affect what the CRO sees on their dashboard.
A threshold is the value at which PILLAR decides something is worth surfacing. For example, days_since_activity = 30 means: if an account has had no logged activity for 30 days, fire a “No Recent Activity” signal. Raising the threshold to 60 means PILLAR waits longer before treating inactivity as a risk — useful for seasonal businesses or long-cycle enterprise accounts.

​
Need help configuring?

Contact your PILLAR implementation contact or email support@pillargtm.com. For white-glove implementations, your PILLAR contact will walk through every setting with you during the Day 3–4 configuration session.