Read this first. It’s the most important thing about BUILDER. The product BUILDER ships with — the engine, the safety gates, the dashboard, the kill switch — is the same for every customer. What’s different is what BUILDER does on day one for that specific customer. That difference is configured during implementation. PILLAR ships four preset libraries (EdTech, Public-Sector, AI-Automation, Family-Literacy) as conversation starters, not products. They’re scaffolds you and the customer’s revenue team sit down with on Week 1, then customize: their cycles, their thresholds, their handoff paths, their leading indicators. A customer who arrives atDocumentation Index
Fetch the complete documentation index at: https://hc.pillargtm.com/llms.txt
Use this file to discover all available pages before exploring further.
/builder and sees five rules already shaped around how they actually work has a fundamentally different experience than one who sees an empty list. The presets exist to make Day 1 land hard.
The three steps of implementation-phase configuration
Run the matching preset library
Choose the library (or combination of libraries) that matches the customer’s motion:Multiple libraries can stack. Each library inserts 5 starter rules into the customer’s
EdTech
Pure private-market K-12 SaaS with district-level sales motion.
AI-Automation
AI-platform or PLG-leaning vendor with product usage telemetry. Often stacked with EdTech for curriculum SaaS that has rich Mode/Mixpanel-style data.
Public-Sector
State / local / federal seller with RFP / coop-purchasing / FOIA exposure.
Family-Literacy
Hybrid district + family-direct EdTech with family-engagement signals. Often stacked with Public-Sector since family-literacy sellers usually contract with school districts.
builder_rules table, all in shadow mode with shadow_started_at = NOW().Customize each preset rule to match the customer's actual numbers
The EdTech “Renewal-risk → save play” rule defaults to ARR > $100k.This customization is the difference between a generic rule and a rule that fits. It’s also the conversation that builds buy-in — the customer’s revenue team sees you tuning the system to them, not them to it.
- For a customer whose median ACV is $20k, that threshold is wrong on day one.
- For a customer whose top accounts are $500k+, it’s also wrong.
/builder/[id]/edit) and tunes:Conditions
ARR thresholds, segment filters, day-window distances, completion-rate floors.
Trigger config
Cron times in the customer’s HQ timezone, SLA durations matching their actual rhythms.
Action targets
assignee references that resolve to the customer’s actual user IDs and roles.Rate limits
Appropriate for their account count and motion velocity.
Author 1–3 customer-specific rules from scratch
No preset library can anticipate a customer’s most differentiated leading indicator. A family-literacy customer’s “completion-rate drop” rule is one example — it’s tuned to their leading indicator (parent/family engagement with reading programs), not a generic K-12 indicator. A K-12 curriculum customer’s “summer dampening” rule is another — it relaxes SLA timers June–August because teacher engagement legitimately drops over the summer break and shouldn’t trigger save-play escalation during that window.These authored rules can be drafted in plain English via DRAFTER’s
propose_builder_rule tool, then refined in the editor:
“Author: when an account’s product usage drops more than 40% in 7 days AND the account has been onboarded less than 90 days, fire an onboarding_friction signal at WARNING severity.”
DRAFTER returns a structured draft with the right trigger type, condition operators, and action shape. The Implementation Engineer reviews + saves to shadow mode.The insight
BUILDER isn’t a product that customers configure themselves over time. BUILDER is a product whose shape on Day 1 is half the implementation deliverable. The other half is the trust-building that happens in shadow → propose → execute over the following 30 days. This is why every customer onboarding includes a dedicated BUILDER configuration session, and why the BUILDER section of every PILLAR Implementation Plan is customer-specific.What configuration looks like in an Implementation Plan
A typical pilot Implementation Plan dedicates a section to BUILDER that covers:Active preset libraries
Which preset libraries are activated — usually 1–3 stacked.
Per-preset customization
Every threshold tuned to the customer’s actual numbers.
3 customer-specific rules
Drafted with DRAFTER during the configuration session, refined together.
Promotion timeline
All rules in shadow Week 1–2, propose Week 3–4, first execute promotion Week 5+.
Approval queue assignments
Which rule’s proposed actions go to which team members.
Kill-switch designation
Which Admin holds the emergency-stop authority.
What you do NOT do during configuration
Don't promote rules out of shadow on Day 1
The 7-day shadow gate exists for a reason. Even if a rule looks perfect, watch it for a week.
Don't enable execute mode in Week 1
Even if the customer is impatient. The 14-day propose minimum + 80% approval rate threshold are not configurable.
Don't author 30 rules during the configuration session
Start with the preset libraries + 3 custom rules. Adding rules is easy; un-doing trust damage from a misfiring rule is hard.
Don't let the customer skip the kill-switch designation
Every org needs at least one Admin who knows where the kill switch is, what to look for, and how to release it. That’s a people issue, not a software one.