Skip to main content

Documentation Index

Fetch the complete documentation index at: https://hc.pillargtm.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Frequently Asked Questions

​
Setup and Onboarding

The initial sync typically completes in 5-15 minutes depending on the number of records in your CRM. Larger CRM instances may take up to 30 minutes. You can monitor sync progress in Settings > Integrations. After the initial sync, PILLAR pulls data from your CRM every 15 minutes and pushes computed scores (health, risk, priority) back to custom fields in your CRM.
PILLAR currently supports Salesforce, HubSpot, and Microsoft Dynamics 365 with OAuth 2.0 authentication. All three integrations sync Accounts, Contacts, Opportunities, and Leads (or their platform equivalents) into PILLAR every 15 minutes. PILLAR also pushes health scores, risk scores, and priority scores back to custom fields in your CRM.
PILLAR integrates with Google Workspace and Microsoft 365 for email metadata and calendar event ingestion. PILLAR never reads email body content — only metadata (sender, recipient, timestamp, subject line) is used for activity-based scoring.
Navigate to Settings > Team to invite users by email. Each user is assigned a role (Admin, Leader, Manager, or Rep/CSM) that controls their access level. All users within your organization share the same data, isolated by Row-Level Security from other tenants.

​
Scoring Engine

Yes. Every scoring category and individual rule weight is configurable per organization. Navigate to Settings → Configuration → Segments & Thresholds to adjust signal-triggering thresholds (health score warning levels, renewal risk levels, etc.). For deal stage close probabilities, use Settings → Configuration → Deal Stages. For pipeline weighting, use Settings → Configuration → Pipeline Weights. PILLAR ships with defaults tuned for EdTech GTM teams, but you can tailor them to your specific business.
Scores are recomputed on a regular cadence for scoring-based evaluations, and in real-time for webhook-triggered events (like Starbridge district intelligence updates). The scoring engine evaluates all rules against the full context for each account.
A score is a continuous numeric value (0-100) computed by the scoring engine — for example, an account health score of 72. A signal is a discrete event generated when a score crosses a threshold or an external event is detected — for example, “Account Health dropped below warning level.” Scores measure state; signals drive action.
ICP Fit evaluates how closely an account matches your ideal customer profile across firmographic, technographic, and behavioral dimensions. The model considers organization size, budget allocation, technology adoption patterns, and decision-maker presence. All ICP parameters are configurable per organization. See the ICP Fit documentation for details.

​
Signals

Signals are routed via Slack (real-time) and email (weekly digest). You can configure routing rules by signal family, severity, and assignee in Settings > Notifications. Critical signals are always delivered immediately; lower-severity signals are batched into the weekly digest.
PILLAR uses three severity levels: Critical (immediate action required), Warning (attention needed within 24-48 hours), and Info (informational, no immediate action required). Severity is determined by the magnitude of the score change or the nature of the triggering event.
Yes. Signals follow a 7-state lifecycle: Pending, Active, Acknowledged, In Progress, Resolved, Expired, and Suppressed. You can suppress a signal to remove it from your active queue. Suppressed signals are still logged and visible in the signal history.

​
Data and Security

PILLAR uses Row-Level Security (RLS) enforcing strict multi-tenant data isolation. Every query is filtered by organization, ensuring your data is never accessible to other organizations. Authentication uses industry-standard session tokens, and all data is encrypted in transit and at rest.
Every behavior PILLAR commits to is a named, enforced, append-only invariant, and we can show you the exact test that proves each one. 66 public spec entries → 63 named Guarantees across 17 categories → 2,500+ automated tests running on every commit (unit + integration + Playwright UI). The chain is build-enforced — a spec entry without a Guarantee fails the build, a Guarantee without a matching test fails the build, an orphan test referencing a Guarantee that doesn’t exist fails the build. See The Guarantee for the full framework, invariant categories, and what each code means.
Starbridge.ai provides 120+ buyer attributes for K-12 school districts and higher education institutions, including budget data, technology adoption, procurement history, RFP activity, job changes, and conference attendance. PILLAR enriches every matching account with Starbridge data automatically via webhook and on-demand API calls.
No. PILLAR only ingests email metadata — sender, recipient, timestamp, and subject line. Email body content is never read, stored, or processed. This metadata powers activity-based scoring and engagement signals.
Yes. PILLAR provides full data export via the API. You can also export dashboards and reports as PDF. All data remains yours — PILLAR operates as a processing layer on top of your existing CRM data.

​
Business Configuration

Yes. Navigate to Settings → Configuration → Business Definitions and set your fiscal year start month. Once configured, all period-based metrics — pipeline coverage, quota attainment, budget variance, and board report quarters — compute against your fiscal calendar rather than the calendar year. For example, an organization with a February 1 fiscal year start will see Q1 as February–April, Q2 as May–July, and so on.
PILLAR supports three ARR definitions, configurable in Settings → Configuration → Business Definitions:
  • Contracted ACV (default) — Annual Contract Value from signed agreements
  • Trailing 12-Month Revenue — Actual recognized revenue over the past 12 months
  • MRR × 12 — Monthly Recurring Revenue annualized
All ARR-based calculations across the platform (NRR, churn rate, segment classification, quota attainment) use whichever definition your organization has selected.
Yes. Navigate to Settings → Configuration → Business Definitions and set your base currency. PILLAR supports USD, EUR, GBP, CAD, AUD, JPY, SGD, CHF, SEK, and DKK. All financial figures in reports, exports, and dashboards display in your configured currency.
PILLAR classifies accounts by ARR using configurable tier boundaries. The defaults are:
  • SMB: ARR ≤ $50,000
  • Mid-Market: ARR 50,001–50,001–500,000
  • Enterprise: ARR > $500,000
To override these boundaries for your business, navigate to Settings → Configuration → Segments & Thresholds and adjust the SMB and Mid-Market ARR ceilings. All segment-based analytics, cohort groupings, and playbook recommendations update immediately.
Yes. PILLAR ships with 30+ default close probabilities mapped to common CRM stage names (Prospecting, Qualification, Proposal, Negotiation, etc.). If your CRM uses custom stage names or different probability assumptions, navigate to Settings → Configuration → Deal Stages to define per-stage overrides. Any stage not in your map falls back to 15%. These probabilities feed directly into weighted pipeline calculations and forecast confidence scoring.
The renewal window is the look-ahead period PILLAR uses to identify accounts approaching renewal. Accounts with a renewal date within this window are included in renewal risk monitoring, procurement alignment scoring, and the renewal forecast. The default is 90 days. You can set it between 14 and 730 days in Settings → Configuration → Business Definitions to match your team’s engagement lead time.
Yes. PILLAR supports three churn definitions in Settings → Configuration → Business Definitions:
  • Revenue Churn (default) — Percentage of ARR lost from non-renewals and downgrades
  • Logo Churn — Percentage of customer accounts that did not renew
  • Net Revenue Churn — Net change in ARR including expansions, factoring in upsell against lost ARR
Cohort analytics, churn signals, and NRR calculations reflect whichever definition you select.
Yes. Eight signal-triggering thresholds are configurable per organization in Settings → Configuration → Segments & Thresholds:
  • Health score warning and critical levels
  • Renewal risk warning level
  • ICP fit minimum threshold
  • Engagement velocity minimum
  • Pipeline coverage ratio warning
  • Win rate warning threshold
  • CAC ratio warning threshold
PILLAR’s global defaults are used for any threshold you haven’t explicitly overridden. Override indicators appear next to each customized threshold so you always know which values are org-specific.

​
Blueprint Assessment

The Blueprint Assessment is a free GTM maturity evaluation that scores your organization across 5 pillars (Strategy, People, Process, Systems, and Metrics) with 142 questions spanning 27 categories. You receive a detailed report with pillar-level scores, strengths, gaps, and a maturity tier classification. Take the assessment.
Blueprint identifies where your GTM operations are strong and where gaps exist. Each pillar and category maps directly to PILLAR platform capabilities. For example, low Process scores indicate areas where PILLAR’s automated scoring, signals, and plays can drive immediate improvement. See the Blueprint deep-dive for the full mapping.

​
AI Agents and MCP

PILLAR ships a native Model Context Protocol (MCP) server that exposes 70+ tools spanning the full revenue architecture — core intelligence, plays, tasks, expansion whitespace, financial cascade (NRR simulation, procurement, cohorts), market intelligence (TAM/SAM, headcount simulation), AI orchestration (Ask PILLAR RAG, generated narratives), scoring transparency, and governed writes. Any MCP-compatible AI client — Claude Desktop, Cursor, VS Code, ChatGPT Desktop, Zed, Windsurf — can query and act on your PILLAR data in natural language. See the MCP Server guide for setup.
Drafter is the in-app AI agent layer, mounted globally across every authenticated PILLAR page as a floating chat widget. Ask any GTM question — “why does Houston ISD have its current renewal risk score?”, “what’s our biggest pipeline risk this quarter?”, “simulate NRR going from 108% to 115%” — and Drafter picks the right subset of MCP tools, pulls evidence, and returns a specific answer. Every run writes to an audit table for the approval gate and flywheel learning. Drafter and the external MCP server share the same 129 MCP tool catalog, so behavior is consistent across surfaces.
Same capabilities, different surfaces. The MCP server is for external AI assistants (Claude Desktop, Cursor, ChatGPT, etc.) working alongside PILLAR. Drafter is the in-app experience — you never leave pillargtm.com, it knows which page you’re on, and write actions route through a visual approval gate before executing. Both consume the same tool catalog (src/lib/mcp/tool-catalog.ts) so an answer you get from Drafter matches what Claude Desktop would return for the same question.
Yes, but with governance. PILLAR distinguishes read tools (most of the 65) from governed writes — create_play, complete_play, acknowledge_signal, create_task, update_task, update_signal_status, set_renewal_disposition, opt_in_benchmarks. External MCP clients can invoke writes directly with your API key’s permissions. The in-app Drafter cannot — writes are surfaced as proposals in the drawer with approve/reject controls, and every decision is logged to agent_actions for audit. You can review the full governance model.
Yes. Every Drafter run prepends today’s date + day-of-week (America/New_York) to the system prompt so urgency phrasing anchors to your actual now, not the model’s training cutoff. Snapshot briefings are day-agnostic — no “Monday briefing” on a Wednesday.