# Actions
Source: https://docs.trig.ai/concepts/actions
Execute interventions via email, Slack, and webhooks
Actions are the things Trig does in response to customer activity. They're the "do something" layer of the platform—executing interventions, sending notifications, updating systems, and communicating with customers.
## What are actions?
Every job, behaviour, and stage can trigger actions at key moments. Actions turn insight into intervention.
**Core principle:** Trig observes customer behaviour, identifies when intervention is needed, and actions execute that intervention.
## When actions trigger
Actions fire at specific moments:
### Entry actions
Fire when a customer enters a job, behaviour, or stage.
**Use for:**
* Sending initial outreach
* Notifying your team
* Recording entry in CRM
### Completion actions (follow-up)
Fire when a customer achieves the goal.
**Use for:**
* Congratulating customers
* Notifying team of success
* Recording completion in CRM
* Triggering next-stage jobs
### Exit actions (fallback)
Fire when a customer exits without completing.
**Use for:**
* Notifying team of intervention failure
* Recording failure in CRM
* Triggering escalation or alternative jobs
* Alerting CSMs for manual follow-up
## Action types
### Message customer
Send an email directly to the customer.
| Configuration | Description |
| ------------- | ------------------------------------- |
| **Sender** | Who the email appears from |
| **Subject** | Email subject line |
| **Body** | Email content with dynamic attributes |
| **Format** | Plain text recommended |
**Example:**
```
From: Anna at Autodesk
Subject: Quick tip to get started
Hi {first_name},
I noticed you joined {board_name} but haven't created your
first project yet. Here are three steps to get started—takes
about 5 minutes.
[steps]
Thanks,
Anna
```
### Send reminder message
Send a follow-up email after a delay if the customer hasn't completed.
| Configuration | Description |
| ------------- | -------------------------- |
| **Delay** | Wait X days before sending |
| **Content** | Same as message customer |
**Example sequence:**
1. Entry: Send initial email
2. Wait 5 days
3. If not completed: Send reminder
4. Wait 5 more days
5. If still not completed: Exit with fallback actions
### Notify team
Send a notification to your internal team via Slack.
| Configuration | Description |
| ------------- | -------------------------------------------- |
| **Channel** | Select Slack channel |
| **Message** | Notification content with dynamic attributes |
**Example:**
```
Channel: #customer-alerts
Message: @{case_owner_email} - {organization_name} has entered
the "At Risk" job. They haven't logged in for 30+ days.
```
**Dynamic @-mentions:** Include an email attribute with @ to ping that person directly in Slack.
### Update attribute
Set or update an attribute value on the customer record.
| Configuration | Description |
| ------------------ | --------------------- |
| **Attribute name** | Which field to update |
| **Value** | What value to set |
**Example:**
```
Attribute: completed_onboarding_job
Value: true
```
If you update an attribute that's also synced from CRM, the next sync may overwrite your update. Use Trig-specific fields.
## Dynamic attributes in messages
Actions can include dynamic content from customer attributes.
### How to use
In any message field, insert attribute placeholders:
```
Hi {first_name},
I noticed your team at {organization_name} signed up
{days_since_signup} days ago but hasn't {specific_action} yet.
Here's how to get started: [link]
Thanks,
{sender_name}
```
### Available attributes
Any attribute on the customer record:
* **Person attributes:** first\_name, email, role
* **Organisation attributes:** organization\_name, industry, arr
* **Trig-generated:** last\_entry\_to\_job, days\_in\_stage
* **CRM attributes:** case\_owner\_email, account\_manager
### Handling missing values
If an attribute has no value, the placeholder will be empty. Test messages with real customer data to ensure correct rendering.
## Email configuration
### Integration setup
Before sending emails, you need:
1. **Domain verification:** DNS records to authorise sending
2. **Sender configuration:** Who emails appear from
3. **Subdomain setup:** Often use a subdomain for deliverability
This is handled during onboarding.
### Sender identity
Emails should appear from a real person:
| Good | Bad |
| ------------------------------------------------------------------------- | ------------------------------------------------------- |
| "Anna at Autodesk" | "[no-reply@autodesk.com](mailto:no-reply@autodesk.com)" |
| [anna@notifications.autodesk.com](mailto:anna@notifications.autodesk.com) | "Autodesk Marketing" |
Personal senders get higher engagement.
### Plain text vs HTML
**Strong recommendation: Use plain text.**
| Plain Text | HTML/Branded |
| ----------------------------- | ------------------------------- |
| Looks like from a real person | Looks like marketing automation |
| Higher open rates | Lower open rates |
| Higher response rates | Lower response rates |
| Avoids spam filters | More likely filtered |
## Slack integration
### Setup
1. Authorise Trig to access your Slack workspace
2. Wait for channel enumeration
3. Select channels for notifications
### Channel selection
Target channels like:
* \#customer-success
* \#sales-alerts
* \#trig-notifications
### Message formatting
Slack messages support:
* Dynamic attributes (same as email)
* @-mentions using email addresses
* Basic formatting
## Using attributes to chain jobs
Actions that update attributes enable job chaining:
```
Job 1: Try to get customer to do X
├── On completion: Set "completed_job_1" = true
└── On exit: Set "failed_job_1" = true
Job 2: Target completers
└── Audience: "completed_job_1" = true
Job 1B: Alternative for failures
└── Audience: "failed_job_1" = true
```
## Job action flow example
```
Job: Onboarding Nudge
├── Entry Actions
│ ├── Message Customer: Welcome email with steps
│ └── Update Attribute: entered_onboarding_nudge = true
│
├── Intervention (if not completed)
│ └── Send Reminder: Wait 5 days, send follow-up
│
├── Completion Actions (Follow-Up)
│ ├── Message Customer: Congratulations, here's what's next
│ ├── Notify Team: Customer completed onboarding
│ └── Update Attribute: completed_onboarding = true
│
└── Exit Actions (Fallback)
├── Notify Team: Customer failed, needs manual follow-up
└── Update Attribute: failed_onboarding = true
```
## Action availability by context
| Action | Entry | Completion | Exit |
| ---------------- | ----- | ---------- | ---- |
| Message Customer | ✓ | ✓ | ✓ |
| Send Reminder | ✓ | — | — |
| Notify Team | ✓\* | ✓ | ✓ |
| Update Attribute | ✓ | ✓ | ✓ |
\*May have constraints depending on configuration
## Best practices
### Email content
**Be specific and actionable:**
```
Good: "Click here to complete your profile. It takes 2 minutes."
Bad: "We noticed you haven't finished setting up your account."
```
**Include clear steps:**
```
Here are three steps to send your first invoice:
1. Click "Create Invoice" in the left menu
2. Add your client's email address
3. Click Send
That's it—you'll get a notification when they pay.
```
**Keep it short:**
* 3 to 5 sentences for simple actions
* Bullet points for multi-step instructions
* No long paragraphs
### Notification strategy
**Don't over-notify:**
* Reserve notifications for high-value or high-risk situations
* Use channels, not DMs, for most notifications
* Not every entry needs a Slack notification
**Route appropriately:**
* High-value customers → Dedicated channel + @-mention
* Routine updates → Team channel without @-mention
* Escalations → Specific person @-mentioned
### Attribute management
**Name clearly:**
* `completed_onboarding_job` not `flag_1`
* `last_intervention_date` not `date`
**Don't overwrite CRM fields:**
* Create dedicated Trig fields in your CRM
* Coordinate with CRM admin on write-back strategy
### Testing
**Before going live:**
* Test with small audience
* Verify dynamic attributes render correctly
* Check Slack notifications reach correct channel
* Confirm CRM updates work
**Monitor after launch:**
* Check delivery rates
* Watch for bounces or spam issues
* Verify customers progressing as expected
## Troubleshooting
### Emails not sending
Check:
* Email integration configured?
* Sender verified?
* DNS records in place?
* Job active (not paused)?
### Slack notifications not appearing
Check:
* Slack integration connected?
* Channel enumeration complete?
* Correct channel selected?
* Bot has permission to post?
### Attributes not updating
Check:
* Correct attribute name?
* Attribute exists in system?
* Action actually triggered?
* CRM sync overwriting value?
## Summary
Actions are how Trig turns insight into intervention:
1. **Three trigger points** — Entry, completion, and exit each serve different purposes
2. **Four action types** — Message customer, send reminder, notify team, update attribute
3. **Plain text wins** — Simple, personal emails outperform branded marketing
4. **Chain with attributes** — Use attribute updates to create progressive job sequences
5. **Right action, right moment** — Entry for initial outreach, completion for celebration, exit for escalation
# Attributes
Source: https://docs.trig.ai/concepts/attributes
The data points that describe your customers
Attributes are data points that describe your customers. They're the building blocks of everything in Trig—defining audiences, setting completion criteria, personalising messages, and tracking progress.
## What are attributes?
Think of attributes as facts you know about each customer:
* Who they are (name, email, role)
* What they've done (signup date, invoices created, login count)
* Where they are in their journey (stage, job membership)
* What Trig has observed (days in stage, objectives completed)
Every filter, audience, and criteria in Trig is built from attributes.
## Attribute types
### Ingested attributes
Pulled from external systems into Trig.
**Sources:**
* **CRM:** HubSpot, Salesforce
* **Data warehouse:** Snowflake, BigQuery, Redshift
* **Product analytics:** Mixpanel, Amplitude, Segment, Pendo
**Examples:**
* `company_name` (from HubSpot)
* `arr` (from Salesforce)
* `signup_date` (from product database)
* `plan_type` (from billing system)
### Trig activity attributes (auto-generated)
Created automatically as customers interact with Trig objects.
For every job, behaviour, stage, and objective:
```
currently_member_of_[object_name] — Are they currently in?
last_entry_to_[object_name] — When did they enter?
last_exit_from_[object_name] — When did they exit (failed)?
last_completion_of_[object_name] — When did they complete?
```
**Examples:**
```
currently_member_of_onboarding_stage = true
last_entry_to_poc_1_job = 2024-10-15
last_completion_of_create_first_invoice = 2024-10-18
```
These attributes persist forever—you can always look back at which jobs and stages a customer has been through.
### Rolled-up attributes
Aggregated from child entities (People) to parent entities (Organisations).
| Aggregation | Example |
| ----------- | --------------------------------- |
| **Sum** | Total logins across all users |
| **Count** | Number of users matching criteria |
| **Average** | Mean value across users |
| **Min/Max** | Extremes across users |
**Examples:**
* `total_time_entries_created` (sum)
* `active_user_count` (count)
* `average_session_duration` (mean)
### Calculated attributes
Derived from other attributes through computation.
**Examples:**
* `days_since_signup` (today minus signup\_date)
* `days_until_renewal` (renewal\_date minus today)
* `health_score` (composite of multiple factors)
### Action-created attributes
Set by job actions when customers complete or exit.
**Example:**
```
Job completion action: Set completed_onboarding_job = true
```
## Person vs organisation attributes
### Person attributes
Describe individual users:
* Identity: email, user\_id, name
* Role: job\_title, permissions, admin\_status
* Behaviour: last\_login, feature\_usage, session\_count
* Trig activity: job membership, behaviour completion
### Organisation attributes
Describe accounts/companies:
* Identity: company\_name, domain, account\_id
* Commercial: arr, contract\_value, plan\_type
* Relationship: customer\_since, renewal\_date, csm\_owner
* Aggregated: total\_users, active\_user\_count
* Trig activity: stage, job outcomes
### Choosing the right level
| Scenario | Level | Why |
| ------------------------------ | ------------ | -------------------- |
| "Has this user logged in?" | Person | Individual action |
| "Is this account healthy?" | Organisation | Account assessment |
| "Send email to inactive user" | Person | Individual targeting |
| "Flag accounts for CSM review" | Organisation | Account triage |
## Using attributes in filters
### Building filters
1. **Select attribute:** Choose from available attributes
2. **Select operator:** equals, not equals, greater than, contains, has value
3. **Set value:** The comparison value
**Example:**
```
signup_date is after 30 days ago
AND plan_type equals "Enterprise"
AND currently_member_of_onboarding_stage equals true
```
### Filter groups
\| Within a group | AND — All conditions must be true |
\| Between groups | OR — Any group can be true |
### Common filter patterns
**New customers:**
```
signup_date is after 14 days ago
```
**High-value accounts:**
```
arr is greater than 50000
```
**Stuck in onboarding:**
```
currently_member_of_onboarding_stage equals true
AND days_in_stage is greater than 30
```
**Completed job but not next step:**
```
last_completion_of_job_1 has any value
AND last_entry_to_job_2 has no value
```
## Attributes vs events
Understanding this difference is critical for building effective jobs.
### Attributes
* **Nature:** Static values on a record
* **Evaluation:** Historical (checked against existing values)
* **Persistence:** Remain on record until changed
### Events
* **Nature:** Point-in-time occurrences
* **Evaluation:** Forward-only (only new events trigger)
* **Persistence:** Stream of discrete actions
### Critical distinction
**Attributes are evaluated historically:** When you create a job with audience `signup_date after 30 days ago`, Trig checks existing values and immediately includes matching customers.
**Events are evaluated forward-only:** When you create completion criteria `invoice_created at least 1 time`, Trig only counts NEW events from when the job goes live—not historical events.
### Implication for job design
If you want to exclude customers who have already done something:
* **Use an attribute** (e.g., `first_invoice_date has no value`)
* **Don't rely on event counts** for historical behaviour
## Trig activity attributes deep dive
### The four core attributes
For every Trig object, you get:
| Attribute | Meaning | Use Case |
| ------------------------- | ------------------------ | --------------------------- |
| `currently_member_of_[X]` | Currently in this object | Exclude from other jobs |
| `last_entry_to_[X]` | When they entered | Time-based targeting |
| `last_exit_from_[X]` | When they failed | Target failed customers |
| `last_completion_of_[X]` | When they succeeded | Target successful customers |
### Using for job chaining
**Job 1: Initial Nudge**
* On completion: Customer has `last_completion_of_initial_nudge`
**Job 2: Follow-Up for Completers**
* Audience: `last_completion_of_initial_nudge` has any value
**Job 3: Rescue for Non-Completers**
* Audience: `last_exit_from_initial_nudge` has any value
### Timing-based targeting
```
last_entry_to_onboarding_job is after 5 days ago
AND last_entry_to_onboarding_job is before 3 days ago
AND last_completion_of_onboarding_job has no value
```
This targets customers who entered 3 to 5 days ago but haven't completed—perfect for reminders.
### Persistence is powerful
These attributes never disappear. Years later, you can still query:
* "Show me everyone who completed Job X in Q3 2024"
* "How many customers who failed Behaviour Y eventually churned?"
## Viewing attributes
### Settings > Attributes
Navigate to **Settings > Audience > Attributes** to see all available:
* People Attributes
* Organisation Attributes
* Stage Result Attributes
* Objective Result Attributes
### On individual records
Click any person or organisation to see their specific values, grouped by source:
* CRM Attributes
* Product Attributes
* Trig Activity Attributes
## Attribute data types
| Type | Operators | Example |
| ----------- | ------------------------------- | ---------------------------------- |
| **String** | equals, contains, starts with | `company_name contains "Tech"` |
| **Number** | equals, greater than, less than | `arr is greater than 50000` |
| **Boolean** | equals, not equals | `is_paying equals true` |
| **Date** | before, after, between | `signup_date is after 30 days ago` |
| **Array** | contains, does not contain | `tags contains "Enterprise"` |
## Common attribute patterns
### Commercial attributes
```
arr (Annual Recurring Revenue)
mrr (Monthly Recurring Revenue)
contract_value
plan_type
subscription_status
renewal_date
```
### Engagement attributes
```
last_login
login_count
session_duration
feature_usage_count
dau (Daily Active Users)
```
### Stage attributes
```
signup_date
activation_date
first_value_moment
onboarding_complete
days_as_customer
```
### Trig-generated attributes
```
currently_member_of_[stage/job/behaviour]
last_entry_to_[stage/job/behaviour]
last_completion_of_[stage/job/behaviour]
days_in_[stage]
objectives_completed_count
```
## Best practices
### Naming conventions
| Good | Bad |
| ---------------------------- | -------- |
| `first_invoice_created_date` | `fic_dt` |
| `completed_onboarding_job` | `flag_1` |
### Keep source of truth clear
* Don't duplicate CRM fields manually
* Use Trig-generated attributes for Trig activity
* Create dedicated fields for write-back
### Use Trig attributes liberally
The auto-generated attributes are extremely valuable:
* Use for progressive job targeting
* Build exclusion logic
* Analyse intervention outcomes
### Test your filters
Before launching jobs:
* Build the filter in Audience view
* Check the resulting count
* Spot-check individual records
## Troubleshooting
### "Attribute has no value"
* Is data flowing from the source system?
* Is the attribute mapped in the integration?
* Has the customer record been synced recently?
### "Filter returns unexpected results"
* Are you using person vs org attributes correctly?
* Is the operator correct (equals vs contains)?
* Are date comparisons using the right direction?
### "Trig activity attributes not appearing"
* Has the job/stage/behaviour been set live?
* Has anyone entered the object yet?
* Attributes only appear after first use
## Summary
Attributes are the foundation of everything in Trig:
1. **Three sources** — Ingested (external systems), Trig-generated (platform activity), action-created (job outcomes)
2. **Two levels** — Person (individual users) and Organisation (accounts)
3. **Attributes = historical, Events = forward** — Critical for job design
4. **Trig activity attributes are powerful** — Entry/exit/completion tracking enables progressive jobs
5. **Roll-ups aggregate up** — Person data flows to organisation level
6. **Persist forever** — Historical record enables long-term analysis
Master attributes and you master Trig.
# Behaviours
Source: https://docs.trig.ai/concepts/behaviours
Capture milestone moments in customer activity
Behaviours are defined patterns of customer activity that you want to track and potentially act upon. They capture the moment when a customer exhibits a specific combination of attributes or events that matters to your business.
## What are behaviours?
Think of behaviours as tripwires. You define the conditions, and when a customer crosses that threshold, Trig records it, can fire actions, and creates permanent metadata about when it happened.
**Key characteristic:** Behaviours are **one and done**. Once a customer enters a behaviour and either completes it or exits, they cannot re-enter that same behaviour again.
This makes behaviours ideal for tracking milestone moments—things that happen once and carry significance.
## Behaviours vs cohorts
Understanding this distinction is critical:
| Behaviours | Cohorts |
| --------------------------------------------------- | ---------------------------------------------- |
| One and done—once you leave, you can never re-enter | Dynamic—you can enter and leave multiple times |
| Track milestone moments that happen once | Track current state based on criteria |
| Create permanent historical record | Membership changes as attributes change |
| "First time they did X" | "Currently active" |
**Example comparison:**
A **"Super User" behaviour** captures the moment someone first becomes a super user. Once achieved, it's recorded permanently—even if usage later declines.
A **"Super User" cohort** tracks who currently meets super user criteria. If usage declines, they leave. If it rises, they rejoin.
Both have value. Behaviours give you historical milestones. Cohorts give you current state.
## Why behaviours matter
### Capturing milestone moments
Some customer actions are significant precisely because they happen once:
* First time creating a project
* Reaching a usage threshold (100+ actions)
* Completing a critical setup step
* Achieving "power user" criteria
### Triggering actions at the right time
When a customer exhibits a behaviour, you can immediately:
* Notify your team via Slack or webhook
* Update an attribute in your system
* Send a follow-up communication
* Route them into a job
### Building customer context
Every behaviour creates metadata:
```
last_entered_[behaviour] — When they entered
last_completed_[behaviour] — When they completed
last_exited_[behaviour] — When they exited without completing
currently_member_of_[behaviour] — Whether they're currently in it
```
This metadata is available for targeting, filtering, and analysis throughout the platform.
### Qualifying audiences for jobs
Behaviours are often used as qualification criteria:
```
Target everyone who has completed "Setup Complete" behaviour
but has NOT completed "First Project Created" behaviour
```
## How behaviours work
### Entry criteria (audience)
Entry criteria define who qualifies to enter:
```
Behaviour: First Strike Moment
Audience:
- License type = commercial
- First session date within last 7 days
```
When someone matches these criteria and hasn't previously entered, they enter the behaviour.
### Completion criteria
Completion criteria define success:
```
Completion criteria:
- Projects created >= 1 OR
- Boards joined >= 1 OR
- Project link clicked >= 1
```
When someone in the behaviour meets these criteria, they complete. Completion is the positive outcome.
### Exit without completion
If someone is in a behaviour and no longer matches entry criteria (or a time limit passes) without completing, they exit. Exit is the negative outcome.
### The one-and-done rule
Once a customer has entered a behaviour—regardless of completion or exit—they cannot enter again.
This serves important purposes:
* Preserves integrity of "first time" tracking
* Prevents double-counting
* Creates clean historical records
If you need to track something that can happen repeatedly, use a cohort instead, or create multiple behaviours with different criteria.
## Configuring behaviours
### Anatomy of a behaviour
| Field | Description | Example |
| ----------------------- | --------------------------------------- | ------------------------------------------------- |
| **Name** | Descriptive name | "Setup Moment Reached" |
| **Audience** | Who qualifies to enter | License = commercial, first session within 7 days |
| **Completion Criteria** | What indicates success | Created project >= 1 |
| **Entry Actions** | What happens on entry | Notify team, update attribute |
| **Completion Actions** | What happens on completion | Send webhook, update CRM |
| **Exit Actions** | What happens on exit without completion | Notify team of drop-off |
### Building entry criteria
Entry criteria use filter logic:
**Attribute-based:**
```
attribute = value
attribute >= X
attribute has any value
```
**Trig metadata:**
```
currently_member_of_[stage/behaviour/job]
last_completed_[stage/behaviour/job] has any value
```
**Important:** Attributes are evaluated historically—existing values are checked. Events are evaluated forward—only new events trigger.
### Entry, completion, and exit actions
**Notify team:**
* Send Slack message to a channel
* Include customer context
**Fire webhook:**
* Call an external endpoint
* Pass customer data
**Update attribute:**
* Set an internal attribute
* Flag status changes
## Common behaviour patterns
### Milestone behaviours
Track significant first-time achievements:
```
Behaviour: First Project Created
Audience: All customers
Completion: projects_created >= 1
Behaviour: Power User Threshold Reached
Audience: All customers
Completion:
- sessions_per_week >= 5 AND
- features_used >= 7 AND
- team_members >= 3
```
### Funnel stage behaviours
Track progression through a conversion funnel:
```
Behaviour: Setup Moment
Audience: License = trial
Completion: setup_completed = true
Behaviour: Aha Moment
Audience: completed Setup Moment
Completion: first_value_action = true
Behaviour: Habit Moment
Audience: completed Aha Moment
Completion: return_visits >= 3
```
Each behaviour's audience can depend on completing the previous one.
### Alert behaviours
Track conditions that should trigger notification:
```
Behaviour: Ultra Superstar User
Audience: All customers
Completion:
- projects_created >= 10 AND
- boards_created >= 10 AND
- users_invited >= 100
Entry Action: Notify sales team in Slack
```
### Negative behaviours
Track concerning patterns:
```
Behaviour: Dropped Off During Onboarding
Audience:
- In onboarding stage
- Days since first session >= 14
Completion:
- Last login > 7 days ago
- Onboarding objectives completed < 2
Entry Action: Alert CSM
```
## Behaviours as objectives
Within stages, objectives are actually behaviours under the hood:
```
Stage: Onboarding
├── Objective: Created First Invoice (behaviour)
├── Objective: Connected Gateway (behaviour)
├── Objective: Invited Team Member (behaviour)
```
The mechanics are identical—entry criteria, completion criteria, actions. Within a stage context, they're called "objectives" and contribute to stage progression tracking.
## Automatic metadata
When you create a behaviour, Trig generates attributes automatically:
| Attribute | Type |
| --------------------------------- | --------- |
| `currently_member_of_[behaviour]` | Boolean |
| `last_entered_[behaviour]` | Timestamp |
| `last_exited_[behaviour]` | Timestamp |
| `last_completed_[behaviour]` | Timestamp |
You don't need to create these manually.
### Using behaviour metadata
```
Job Audience:
- last_completed_Setup_Moment has any value
- last_completed_Aha_Moment has no value
```
This targets everyone who completed setup but hasn't reached their aha moment.
## Best practices
### Name behaviours clearly
| Good | Bad |
| ----------------------- | ------------- |
| "First Invoice Created" | "Behaviour 1" |
| "Setup Moment Reached" | "Test" |
| "Power User Threshold" | "PU" |
### Keep behaviours focused
Each behaviour should track one meaningful milestone.
**Too complex:**
```
Completion:
- invoices >= 3 AND
- payments >= 1 AND
- team_members >= 2 AND
- integrations >= 1
```
**Better as separate behaviours:**
* "First 3 Invoices Created"
* "First Payment Received"
* "Team Collaboration Started"
* "Integration Connected"
### Use behaviours for "first time" tracking
The one-and-done nature makes behaviours perfect for first-time events.
### Plan sequences carefully
Because behaviours can't be re-entered, plan thoughtfully:
1. Define each stage as a separate behaviour
2. Use completion of previous as entry criteria for next
3. Consider what happens to people who skip stages
### Don't duplicate Trig metadata
You don't need to create "entered\_X = true" attributes manually—Trig creates them automatically.
## Common questions
You can, but changing criteria affects historical interpretation. Better to create a new behaviour with updated criteria.
The one-and-done design preserves milestone tracking integrity. Use cohorts for repeated entry.
Use threshold behaviours: "First time", "5+ times", "10+ times" as separate behaviours. Or use cohorts for current state.
Objectives are behaviours within stages. Same mechanics, but objectives carry additional meaning for stage progression.
Yes. Entry, completion, and exit actions fire as soon as the condition is met.
Events are forward-only. Attributes are historical.
## Summary
Behaviours capture milestone moments in the customer journey:
1. **One and done** — Customers can only enter each behaviour once
2. **Trigger actions** — Notify teams, fire webhooks, update attributes
3. **Build context** — Every behaviour creates permanent metadata
4. **Qualify audiences** — Use behaviour history for downstream targeting
5. **Sequence thoughtfully** — Plan behaviour dependencies carefully
Used well, behaviours create a rich tapestry of customer context that powers intelligent, timely interventions.
# Jobs
Source: https://docs.trig.ai/concepts/campaigns
Orchestrate interventions to drive customer success
Jobs are the intervention layer of Trig. They orchestrate outreach to customers who meet specific criteria, with the goal of driving them toward a desired behaviour.
## What are jobs?
Unlike stages (which observe) and behaviours (which track milestones), jobs actively intervene—sending messages, notifying teams, and measuring whether the intervention worked.
**Key principle:** Jobs are goal-oriented and time-bounded. You define who to target, what you want them to do, how you'll encourage them, and how long you'll wait.
Think of jobs as targeted nudges. You've identified customers who should do something but haven't. The job reaches out, encourages the action, and measures results.
## Why jobs matter
### Closing the gap between insight and action
Stages and behaviours tell you what's happening. Jobs let you do something about it.
The insight that "47 customers haven't completed onboarding objective 3" becomes actionable when you can immediately target those 47 with a relevant message.
### Timely, contextual intervention
The closer an intervention arrives to the moment of need, the more effective it is:
| Timing | Effectiveness |
| --------------- | ---------------------------------------- |
| Within minutes | Exceptional—customer is still in context |
| Within hours | Very good—customer remembers the session |
| Within 24 hours | Good—still relatively fresh |
| 48+ hours | Declining—customer has moved on |
### Measurable impact
Every job tracks:
* How many entered
* How many completed (achieved the goal)
* How many exited (didn't achieve the goal)
* How long it took
* What actions were taken
This creates clear attribution for intervention effectiveness.
## How jobs work
### The job lifecycle
```
Audience Match → Entry → Intervention → Outcome
↓
┌─────┴─────┐
↓ ↓
Completion Exit
(goal achieved) (goal not achieved)
```
1. **Audience Match:** Customer meets targeting criteria
2. **Entry:** Customer enters, entry actions fire
3. **Intervention:** Messages sent, follow-ups occur
4. **Outcome:** Goal achieved (completion) or time expires (exit)
### Completion vs exit
**Completion:** The customer achieved the goal. This is the positive outcome.
**Exit:** The customer did not achieve the goal within the time allowed. This is the negative outcome (but valuable data).
Both create permanent metadata:
```
last_completed_[job] — Timestamp if completed
last_exited_[job] — Timestamp if exited without completing
last_entered_[job] — When they entered
```
### Time-bounded by design
Jobs should have an auto-exit duration. Without one, customers who never achieve the goal remain indefinitely—breaking your ability to analyse and iterate.
**Duration guidelines:**
* Simple actions (click a link): 3 to 7 days
* Moderate actions (complete setup step): 7 to 14 days
* Complex actions (invite team, integrate system): 14 to 30 days
## Configuring jobs
### Anatomy of a job
| Component | Description | Example |
| ---------------------- | ----------------------------- | ------------------------------------ |
| **Goal** | What you want customers to do | `invoices_created >= 1` |
| **Audience** | Who should receive this | New users, signed up 1 to 7 days ago |
| **Duration** | How long before auto-exit | 14 days |
| **Entry Actions** | What happens when they enter | Send initial email |
| **Intervention** | Follow-up messages/actions | Follow-up email after 3 days |
| **Completion Actions** | What happens on success | Notify team, update CRM |
| **Exit Actions** | What happens on failure | Flag for follow-up job |
### Defining the goal
The goal is the completion criteria—what must be true for success.
**Attribute-based:**
```
invoices_created >= 1
team_members >= 2
integration_connected = true
```
**Event-based:**
```
first_project_created occurred
payment_submitted occurred
```
**Behaviour-based:**
```
last_completed_[behaviour] has any value
```
Keep goals focused on a single, clear action. Multiple actions = separate jobs.
### Defining the audience
**Basic criteria:**
```
Audience:
- sign_up_date > 1 day ago
- sign_up_date < 7 days ago
- invoices_created = 0
```
**Using cohorts:**
```
Audience: Members of cohort "New Self-Serve Users"
```
**Using history:**
```
Audience:
- last_completed_Onboarding_Stage has any value
- last_completed_First_Invoice_Job has no value
```
**Important considerations:**
* **Relative vs absolute dates:** Relative dates mean audience constantly refreshes
* **Exclusions:** Use `last_entered_[job] has any value` to exclude customers who've already been through
## Job actions
See [Actions](/concepts/actions) for detailed action configuration.
### Entry actions
Fire when a customer enters:
* **Send email:** Plain text message to the customer
* **Notify team:** Slack message to a channel
* **Update attribute:** Set value on customer record
* **Fire webhook:** Call external endpoint
### Follow-up actions
After entry, schedule follow-up:
```
Wait 3 days → Send follow-up email
Wait 7 days → Send second follow-up
```
Most jobs use 1 to 2 follow-ups. More often indicates the job is too broad.
### Completion actions
When goal is achieved:
* Celebratory message
* Notify team
* Update CRM
* Route to next job
### Exit actions
When customer exits without completing:
* Notification to team
* Update attribute to mark failure
* Route to alternate job
## Email best practices
### Plain text over branded
**Trig strongly recommends plain text emails.** They look personal, get 10x higher engagement, and feel human even when automated.
**Plain text advantages:**
* Looks like it came from a real person
* Higher open rates
* Higher response rates
* Avoids spam filters
### Contextual and specific
**Good:**
```
Hi Sarah,
I noticed you've logged into FreshBooks but haven't sent your
first invoice yet. Here are three steps to get started—takes
about 5 minutes:
1. Click Invoices in the left menu
2. Click "Create New Invoice"
3. Fill in your client details and hit Send
If you run into any issues, just reply to this email.
Thanks,
Lee
```
**Bad:**
```
Welcome to FreshBooks! We're so excited to have you on board.
FreshBooks is the #1 invoicing solution for small businesses...
```
The good example is contextual, specific, actionable, and personal.
### Short and actionable
* Lead with the action you want them to take
* Provide 1 to 3 clear steps
* Include relevant links
* Offer help if needed
* Sign off personally
## Chaining jobs
One of Trig's powerful capabilities is chaining jobs based on outcomes.
### Success path
```
Job 2 Audience:
- last_completed_Job_1 has any value
- [next action criteria]
```
### Failure path
```
Job 1B Audience:
- last_exited_Job_1 has any value
- last_completed_Job_1 has no value
```
### Progressive context
```
Customer: Acme Corp
Job History:
├── Completed: Welcome Job (Day 2)
├── Completed: First Invoice Job (Day 4)
├── Exited: Gateway Connection Job (Day 12)
└── Currently in: Gateway Connection Retry Job
```
This history enables highly targeted messaging.
## Targeting: organisations vs people
### Organisation-level jobs
Target the account:
* Intervention goes to contacts associated with the organisation
* Useful for account-based actions
* Multiple people may receive messages
### Individual-level jobs
Target specific people:
* Intervention goes to that individual
* Useful for user-specific actions
* More granular targeting
Choose based on what action you're driving. "Invite team members" targets individuals. "Renew contract" targets organisations.
## Measuring effectiveness
### Key metrics
| Metric | Formula |
| ----------------------- | ------------------------------------------ |
| **Completion rate** | Completed / (Completed + Exited) |
| **Time to completion** | How long did successful customers take? |
| **Exit rate** | What percentage failed to complete? |
| **Baseline comparison** | Are recipients completing at higher rates? |
### Iteration
Use job data to improve:
* Low completion rate → Adjust messaging, timing, or goal
* Long time to completion → Intervention may be too early
* High exit at specific point → Focus messaging there
* Certain segments complete more → Target them specifically
## Common job patterns
### Onboarding nudge
```
Goal: first_project_created >= 1
Audience:
- sign_up_date > 1 day ago
- sign_up_date < 7 days ago
- first_project_created = 0
Duration: 10 days
Entry: Plain text email with steps
Follow-up: Day 3, Day 7
Exit: Route to "Onboarding Stalled" job
```
### Feature adoption
```
Goal: feature_X_used >= 1
Audience:
- plan = Premium
- feature_X_used = 0
- days_since_signup >= 30
Duration: 14 days
Entry: Email highlighting feature value
Completion: Silent success
Exit: Flag for CSM follow-up
```
### Churn prevention
```
Goal: engagement_restored = true
Audience:
- renewal_date within 90 days
- last_login > 30 days ago
Duration: 30 days
Entry: Personal outreach from CSM
Exit: Escalate to sales
```
## Common questions
Keep jobs short and focused. 7 to 14 days for most use cases. If no response in 14 days, try a different approach in a new job.
Yes, but be careful about message volume. Use exclusion criteria to prevent overlap.
No new customers enter. Existing customers can still complete or exit normally.
Use `last_entered_[job] has any value` in exclusion criteria.
Either works. Trig sends directly for speed and simplicity. For complex requirements, trigger external systems via webhooks.
## Summary
Jobs are Trig's intervention engine:
1. **Goal-oriented** — Every job has clear completion criteria
2. **Time-bounded** — Set auto-exit to keep jobs focused
3. **Plain text, personal** — Messages should feel human
4. **Timely** — Intervene as close to the trigger as possible
5. **Measurable** — Track completion rate and iterate
6. **Chainable** — Use outcomes to route customers through progressive journeys
Well-designed jobs create a virtuous cycle: insight informs targeting, jobs drive action, outcomes create more insight.
# Cohorts
Source: https://docs.trig.ai/concepts/cohorts
Reusable audience segments for targeting
Cohorts are saved audience segments that persist across your Trig instance. They represent groups of organisations or people who share common characteristics, defined by filters on attributes, behaviours, stage membership, or job history.
## What are cohorts?
Think of cohorts as named bookmarks for audiences you care about repeatedly:
* "Commercial license holders in teams of 5+"
* "Self-serve accounts"
* "Strategic customers"
* "At-risk renewals"
Rather than recreating the same filters every time, you define a cohort once and reference it wherever needed.
**Key distinction from behaviours:** Cohorts have dynamic membership—customers can enter and leave multiple times as their attributes change.
## Why cohorts matter
### Reusability
Without cohorts, every job, behaviour, or stage requires manual filter configuration. With cohorts, you define the audience once and reference it anywhere.
### Consistency
When filters are defined ad-hoc in multiple places, inconsistency creeps in. One job might define "enterprise" as ARR > £100K, another as ARR > £150K.
Cohorts enforce consistency. The definition lives in one place.
### Dynamic membership
Cohorts are dynamic. As organisations meet criteria, they automatically become members. When they no longer match, they automatically leave.
Your cohorts always reflect current reality.
## How cohorts work
### Filter-based definition
A cohort is defined by one or more filter groups:
**Single filter group:**
```
Cohort: Team Users
Filter: team_size >= 2
```
**Multiple conditions (AND logic):**
```
Cohort: Active Enterprise Customers
Filters:
- ARR >= 100000
- last_login within 30 days
- contract_status = active
```
**Multiple filter groups (OR logic):**
```
Cohort: Expansion Candidates
Filter Group 1:
- seat_usage >= 90%
Filter Group 2:
- premium_feature_clicks >= 5
```
### Organisation vs people cohorts
Cohorts can be created for either entity type:
**Organisation cohorts:**
* Enterprise accounts (ARR-based)
* Self-serve vs sales-led
* Product tier segments
* Geographic regions
**People cohorts:**
* Admin users vs regular users
* Power users (high activity)
* Inactive users
* Users with specific roles
### Filter logic
\| Within a filter group | AND — All conditions must be true |
\| Between filter groups | OR — Any group can be true |
This allows complex logic:
```
(Enterprise tier AND Contract renews in 90 days)
OR
(Growth tier AND Contract renews in 30 days)
```
## Creating cohorts
### Where cohorts live
Navigate to **Audience > Cohorts** to create and manage.
Once created, cohorts become available:
* As audience filters in jobs
* As entry criteria for stages
* As targeting for behaviours
* As filters when viewing data
* As conditions in completion criteria
### Configuration
Click **Create Cohort** and choose organisation or people
Add conditions using available attributes
Use a descriptive name that documents the criteria
Check that the right customers are included
### Available filter attributes
**Ingested attributes:**
* Company size, ARR, contract value
* Industry, region, segment
* Product tier, subscription status
**Trig-generated attributes:**
* Last entered/exited/completed stage
* Last entered/exited/completed behaviour
* Last entered/exited/completed job
* Current membership in stages, behaviours, jobs
**Calculated attributes:**
* Team size (count of people)
* Activity metrics (aggregated from individuals)
## Using cohorts
### In job targeting
```
Job: Enterprise Renewal Outreach
Audience: Members of cohort "Enterprise Renewal Window"
```
### In stage entry
```
Stage: Enterprise Onboarding
Entry Criteria: Member of cohort "New Enterprise Customers"
```
### As exclusions
```
Job: Self-Serve Activation
Audience: All customers EXCEPT members of cohort "Sales-Led Accounts"
```
### In completion criteria
```
Job Goal: Customer joins cohort "Power Users"
```
## Common cohort patterns
### ICP segmentation
```
Cohort: ICP 1 - Solo Users
Filter: team_size = 1
Cohort: ICP 2 - Small Teams
Filter: team_size >= 2 AND team_size <= 20
Cohort: ICP 3 - Sales-Led Accounts
Filter: sales_led = true OR ARR >= 50000
```
### Stage-based cohorts
```
Cohort: Stuck in Onboarding
Filters:
- currently_member_of_onboarding_stage = true
- days_in_stage >= 30
- objectives_completed < 3
Cohort: Successfully Onboarded
Filter: last_completed_onboarding_stage has any value
```
### Risk-based cohorts
```
Cohort: Churn Risk - Low Engagement
Filters:
- last_login > 14 days ago
- contract_renewal within 90 days
Cohort: Churn Risk - Declining Usage
Filters:
- usage_this_month < 50% of last_month
- contract_renewal within 60 days
```
### Job outcome cohorts
```
Cohort: Completed First Invoice Job
Filter: last_completed_job_first_invoice has any value
Cohort: Failed Onboarding Jobs
Filters:
- last_exit_from_onboarding_job_1 has any value
- last_completed_onboarding_job_1 has no value
```
## Cohorts and Trig metadata
One of the most powerful aspects is using Trig-generated metadata as filter criteria.
### Stage membership attributes
For every stage:
```
currently_member_of_[stage]
last_entered_[stage]
last_exited_[stage]
last_completed_[stage]
```
### Behaviour membership attributes
For every behaviour:
```
currently_member_of_[behaviour]
last_entered_[behaviour]
last_exited_[behaviour]
last_completed_[behaviour]
```
### Job membership attributes
For every job:
```
currently_member_of_[job]
last_entered_[job]
last_exited_[job]
last_completed_[job]
```
This metadata enables powerful cohort definitions that connect different parts of the customer journey.
## Best practices
### Name cohorts clearly
| Good | Bad |
| ------------------------------------ | --------------- |
| "Enterprise Customers (ARR > £100K)" | "Cohort 1" |
| "At-Risk Renewals (90 days)" | "Test audience" |
| "Stuck in Onboarding (30+ days)" | "Big customers" |
Include key criteria in the name when practical.
### Start with business-critical segments
Don't create cohorts for everything. Focus on:
* Your ICPs (customer types you treat differently)
* Risk segments (who needs attention)
* Outcome segments (who succeeded, who didn't)
### Use for recurring audiences
If you find yourself building the same filter repeatedly, that's a signal to create a cohort. Rule of thumb: if you'll use this audience more than twice, make it a cohort.
### Review periodically
Business definitions change. Review cohorts periodically to ensure definitions still match reality.
### Consider exclusion cohorts
Sometimes it's cleaner to define who should be excluded:
* "Never Email" cohort
* "Sales-Owned" cohort
* "Churned" cohort
## AI-assisted cohort definition
Trig includes natural language capabilities for defining cohorts:
```
"Show me all customers who upgraded in the last week
and are behind average on payment gateway setup"
```
The system interprets this and constructs appropriate filters. Useful for exploration before formalising as permanent cohorts.
## Common questions
Dynamically when queried. As attributes change, membership automatically adjusts.
Yes. Viewing a cohort shows current members with their attributes.
Not directly. Use the underlying attributes or combine filter groups.
Jobs lose that targeting criteria. Check dependencies before deleting.
No. A cohort is either organisation or people. Create separate cohorts for each type.
## Summary
Cohorts are persistent, reusable audience segments:
1. **Define once, use everywhere** — Eliminate redundant filter configuration
2. **Dynamic membership** — Customers automatically join and leave based on criteria
3. **Leverage Trig metadata** — Stage, behaviour, and job history become filterable
4. **Build for business segments** — Focus on audiences that drive different treatment
5. **Name clearly** — Good names make cohorts self-documenting
Well-designed cohorts become the backbone of your customer segmentation.
# Stages
Source: https://docs.trig.ai/concepts/lifecycle-stages
Define the phases of your customer journey
Stages represent defined periods of time during which your customers progress through sets of desirable behaviours. They are the foundational framework that enables Trig to understand the path customers take through your product.
## What are stages?
Think of stages as chapters in your customer's journey. Each chapter has:
* A beginning (entry criteria)
* Things you expect to happen (objectives)
* An end point (exit criteria)
By tracking progression through these chapters, Trig builds a picture of what "normal" looks like—and identifies who is ahead of normal, who is behind, and what patterns exist among each group.
## Why stages matter
Stages are the foundation that enables all other Trig capabilities:
| Without Stages | With Stages |
| --------------------------------------------- | ------------------------------------------------ |
| Each analysis requires separate configuration | One configuration enables multiple value drivers |
| No unified view of customer journey | Complete journey visibility across all customers |
| Interventions are disconnected | Interventions are contextual and timely |
| Measurement is fragmented | Impact measurement works across all stages |
| Manual identification of at-risk customers | Automatic pattern detection and early warning |
**The compounding effect:** Once stages are configured, every new customer automatically progresses, data accumulates for pattern discovery, and the system continuously improves.
## Standard stages
Most B2B SaaS companies use four stages:
### Onboarding
Initial setup and first value milestones. Typically days 0-30.
**Key questions:**
* Has the customer completed initial setup?
* Have they experienced first value?
* Is the team getting involved?
### Adoption
Growing usage, team expansion, feature depth. Typically months 1-3.
**Key questions:**
* Is usage growing?
* Are more team members engaging?
* Are they using deeper features?
### Expansion
Signals of readiness to upgrade or expand. Variable timing.
**Key questions:**
* Are they hitting usage limits?
* Are they exploring premium features?
* Is the team requesting more seats?
### Renewal
Pre-renewal health monitoring and risk identification. Typically 60-90 days before renewal.
**Key questions:**
* Is the account healthy?
* Are there risk signals?
* What's the renewal likelihood?
## How stages work
### Entry and exit criteria
Every stage needs clear boundaries:
**Entry criteria** define when an organisation enters:
* First seen date within X days
* Completion of previous stage
* Specific attribute value (`contract_signed = true`)
**Exit criteria** define when an organisation leaves:
* All objectives completed
* Time-based (after 30 days regardless of completion)
* Specific milestone achieved
### Exit strategy options
| Criteria-Based Exit | Time-Based Exit |
| ------------------------------------------------ | ----------------------------------- |
| Customers can get "stuck" if they never complete | Everyone moves forward |
| Clear signal of completion | May exit with incomplete objectives |
| Good for high-touch journeys | Good for high-volume PLG models |
**Recommendation:** Use time-based exit as a safety net, even with criteria-based completion. This prevents organisations from sitting in stages forever.
### Objectives within stages
Objectives are the specific milestones that indicate healthy progression. See [Objectives](/concepts/objectives) for details.
```
Stage: Onboarding
├── Objective 1: Created First Project
├── Objective 2: Invited Team Member
├── Objective 3: Connected Integration
├── Objective 4: Generated First Report
└── Objective 5: Completed Full Week of Usage
```
## Understanding "normal"
The primary purpose of stages is to establish what normal progression looks like, then identify deviations.
### How normal is calculated
As organisations progress through a stage, Trig calculates:
| Metric | Description |
| ------------------------------------------- | ---------------------------------------- |
| **Average time to complete each objective** | How long does the typical customer take? |
| **Average time to complete the stage** | How long in this stage overall? |
| **Completion rates** | What percentage complete each objective? |
| **Completion sequence** | In what order do customers complete? |
### Above and below average
Once normal is established, every organisation is measured against it:
**Above average (faster completers):**
* Completed objectives in less time than typical
* Often correlates with strong retention
* Expansion opportunities
**Below average (slower completers):**
* Taking longer than typical
* May indicate friction or disengagement
* Intervention opportunities
### Visual representation
```
Objective 1: First Invoice Created
├── ✓ Completed (Day 3)
├── △ Average: Day 7
└── Status: AHEAD (4 days faster than average)
Objective 2: Payment Gateway Connected
├── ✗ Not completed
├── △ Average: Day 14
└── Status: BEHIND (currently Day 21, 7 days overdue)
```
## Configuring stages
### Planning questions
Before creating stages, answer these for each stage:
**Scope:**
* What period of the journey does this cover?
* How long does it typically last?
* What comes before and after?
**Entry:**
* What triggers entry?
* Is it time-based, event-based, or completion of previous stage?
**Objectives:**
* What 3 to 7 milestones define healthy progression?
* What indicates each objective is complete?
* What's the "aha moment"?
**Exit:**
* When does this stage end?
* Completion-based, time-based, or hybrid?
### Configuration steps
Navigate to **Dashboard > Stages** and click **Create Stage**
Specify what qualifies an organisation to enter
Create 4 to 7 objectives with completion criteria
Configure when organisations leave the stage
Add auto-exit timing as a safety net
### Best practices
**Start with 4 to 5 objectives per stage.** Too few loses granularity; too many creates noise.
**Define objectives you can actually track.** Only create objectives where you have data.
**Align duration with business reality.** If onboarding genuinely takes 60 days, don't force it into 14.
**Consider parallel stages.** Enterprise and self-serve customers may need different stage configurations.
## What stages enable
Once properly configured, stages become the foundation for:
### Pattern discovery
* Which objective completion patterns predict retention?
* What attributes are common among fast completers?
* Where are the drop-off points?
### Early warning
* Who is stuck in onboarding?
* Which organisations are below average on critical objectives?
* What revenue is at risk?
### Automated interventions
* Trigger jobs when objectives are overdue
* Send contextual messages based on stage and objective status
* Notify internal teams when high-value accounts are at risk
### Impact measurement
* Did the intervention improve completion?
* Are job recipients completing faster?
* Which messaging is most effective?
## Multiple concurrent stages
Organisations can be in multiple stages at once, though this requires careful design. Common use cases:
* Different stages for different products
* Parallel tracks for different user types within the same organisation
## Common questions
Without auto-exit, they remain indefinitely. Use time-based exit to ensure forward movement so you can analyse patterns of non-completion.
With 50+ organisations through a stage, averages become meaningful. With 200+, patterns become statistically significant.
Yes. Adding new objectives is straightforward. Modifying existing ones may affect historical comparisons.
The platform is optimised for B2B where organisations are the primary unit. For B2C, the "organisation" becomes the individual user.
## Summary
Stages are the foundational data structure in Trig that enables everything else:
1. **Represent periods of time** — Each stage is a chapter in the customer journey
2. **Contain objectives** — Milestones that define healthy progression
3. **Build "normal"** — Establish baselines for comparison
4. **Enable everything** — Pattern discovery, early warning, interventions, and measurement all depend on stages
**Configure stages first. Everything else builds on top.**
# Objectives
Source: https://docs.trig.ai/concepts/objectives
Track milestones within each stage
Objectives are specific milestones or behaviours that you want to track within a stage. They represent the things you expect customers to do as they progress—the actions that indicate healthy usage and forward momentum.
## What are objectives?
Objectives are the checkpoints along a journey. Each checkpoint answers:
* "Has this customer done this thing yet?"
* "How long did it take them compared to others?"
**Key distinction:** Objectives are observational. They track whether something happened without necessarily triggering an intervention. You're building a picture of what customers are doing, how quickly, and who is ahead or behind.
## Objectives vs markers
Within stages, Trig distinguishes between two types:
| Objectives | Markers |
| ----------------------------------------- | ---------------------------------------------- |
| Things you *want* customers to do | Signals of healthy usage |
| Milestones you've identified as important | Ongoing behaviours that correlate with success |
| Define the destination | Indicate quality of the journey |
**Objective examples:**
* Created first project
* Invited a team member
* Connected payment gateway
**Marker examples:**
* Logged in more than 3 times this week
* Session duration greater than 10 minutes
* Returned within 24 hours
## Why objectives matter
### Building a picture of normal
Every objective contributes to understanding what "normal" looks like:
| Metric | Description |
| ---------------------------- | ---------------------------------------------- |
| **Average time to complete** | How long does the typical customer take? |
| **Completion rate** | What percentage complete this objective? |
| **Completion sequence** | In what order do customers typically complete? |
This baseline builds automatically as data accumulates.
### Identifying who needs attention
Once normal is established, every organisation can be measured:
* **Faster than average** — Completed more quickly than typical
* **Slower than average** — Taking longer, potentially stuck
* **Not completed** — Should have completed by now but hasn't
This comparison is the foundation for [Signals](/concepts/signals).
### Enabling pattern discovery
Objectives create measurement points for analysis:
* "Customers who complete Objective A within 7 days have 80% higher retention"
* "Customers who skip Objective C rarely complete Objective D"
* "The median time to complete all onboarding objectives is 12 days"
## How objectives work
### Relationship to stages
Objectives always live within a stage. They inherit their audience from the stage—if an organisation is in the stage, it's being tracked against the stage's objectives.
```
Stage: Onboarding
├── Objective 1: Created First Project
├── Objective 2: Invited Team Member
├── Objective 3: Connected Integration
├── Objective 4: Generated First Report
└── Objective 5: Completed Full Week of Usage
```
### Non-linear completion
Objectives do not need to be completed in order. Unless your business logic requires a specific sequence, customers can complete in any order.
This matters because:
* Different customers have different priorities
* Forcing linear completion creates artificial friction
* The insight is often *which* objectives get completed first
If you need to enforce sequence (Objective B requires Objective A), build that into the completion criteria.
### Completion tracking
When an objective is completed, Trig records:
| Data Point | Description |
| ------------------------- | ------------------------------- |
| **Completion timestamp** | When the objective was achieved |
| **Time from stage entry** | Days since entering the stage |
| **Comparison to average** | Faster or slower than typical |
This data becomes metadata on the organisation for filtering, targeting, and analysis.
## Configuring objectives
### Anatomy of an objective
| Field | Description | Example |
| ----------------------- | --------------------------------------- | ----------------------- |
| **Name** | Descriptive name for the milestone | "First Invoice Created" |
| **Audience** | Who this applies to (usually inherited) | All orgs in stage |
| **Completion Criteria** | What indicates done | `invoices_created >= 1` |
### Completion criteria options
**Attribute-based:**
```
attribute = specific_value
attribute >= X
attribute has any value
```
**Event-based:**
```
event_count >= X
event occurred
```
**Combination:**
```
condition_1 AND condition_2
condition_1 OR condition_2
```
### Keep objectives simple
Each objective should track one meaningful milestone. Complex objectives with many AND conditions are harder to interpret and optimise.
**Too complex:**
```
invoices_created >= 3 AND
payment_gateway_connected = true AND
team_members >= 2 AND
first_payment_received = true
```
**Better as separate objectives:**
* First 3 Invoices Created
* Payment Gateway Connected
* Team Collaboration Started
* First Payment Received
### Naming conventions
Good objective names are:
* **Descriptive** — Clear what the milestone is
* **Action-oriented** — Describes what the customer did
* **Threshold-inclusive** — Include numbers if relevant
| Good | Bad |
| ----------------------- | ---------- |
| "Created First Invoice" | "Invoice" |
| "Using Projects (3+)" | "Projects" |
| "Team Member Invited" | "Has team" |
### Threshold objectives
Track not just whether something happened, but how much:
```
Objective: Using Manual Journal Entries (First Time)
Completion: manual_journal_entries >= 1
Objective: Using Manual Journal Entries (5+)
Completion: manual_journal_entries >= 5
Objective: Using Manual Journal Entries (20+)
Completion: manual_journal_entries >= 20
```
This reveals:
* How many customers use the feature at all
* How many become moderate users
* How many become power users
## Objectives and signals
### How signals use objectives
The [Signals](/concepts/signals) feature analyses objective performance and identifies organisations that need attention:
1. Trig calculates average time to complete each objective
2. For each organisation, Trig compares time-in-stage to the average
3. Organisations significantly behind are flagged as slow completers
4. These appear in the Signals panel for review and action
**Example:**
* Average time to complete "First Invoice Created": 7 days
* Organisation X has been in stage for 14 days, hasn't completed it
* Organisation X appears as a slow completer
### From signal to action
1. **Signal surfaces organisations** — "47 organisations are overdue on 'First Invoice'"
2. **You review and decide** — Worth intervening? What should we say?
3. **Create job** — Target these organisations
4. **Measure impact** — Did the intervention improve completion?
## Viewing objective performance
### Stage-level view
Within a stage, see aggregate performance:
* Total organisations in stage
* Completion counts per objective
* Average time to complete
* Week-over-week trends
### Organisation-level view
For an individual organisation:
```
Organisation: Acme Corp (entered Day 0, currently Day 21)
Objective 1: First Invoice Created
├── ✓ Completed (Day 3)
├── △ Average: Day 7
└── Status: AHEAD (4 days faster)
Objective 2: Payment Gateway Connected
├── ✗ Not completed
├── △ Average: Day 14
└── Status: BEHIND (7 days overdue)
```
## Objectives vs stage completion
**Stage completion criteria** determine when an organisation exits the stage.
**Objectives** track progress within the stage.
### Options
| Approach | Description | Trade-off |
| ------------------------------- | ---------------------------------------- | --------------------------------------------- |
| **Objectives match completion** | Stage completes when all objectives done | Risk: orgs can get stuck forever |
| **Time-based completion** | Stage completes after X days | Everyone moves forward, completion rates vary |
| **Hybrid** | Time-based OR key objectives complete | Balance movement and measurement |
Most implementations use time-based or hybrid.
## Best practices
### Start with 4 to 7 objectives per stage
Too few = lack granularity. Too many = noise overwhelms signal.
### Define objectives you can track
Only create objectives where you have data. Confirm:
* The event or attribute exists
* It's flowing into Trig correctly
* It updates when the customer acts
### Make objectives meaningful
Objectives should represent meaningful milestones, but don't need to be important enough to email about:
**Good:** "Created 6 or more pages" — Meaningful engagement indicator, worth tracking
The intervention decision comes later, informed by patterns across your customer base.
### Use objectives to find bottlenecks
If Objective A has 90% completion and Objective B has 10%, you've found a bottleneck. Design objectives to reveal where customers get stuck.
### Review and refine
Once objectives are live and accumulating data:
* Are any objectives never completed? (Maybe too hard)
* Are any always completed instantly? (Maybe too easy)
* Is there an objective that predicts success?
* Is there an objective that predicts churn?
## Common questions
Yes. Existing organisations will simply have no completion data for new objectives.
Yes, but changing criteria may affect historical interpretation. If you change "invoices >= 1" to "invoices >= 3", previously completed orgs may now show incomplete.
The organisation shows as incomplete. With time-based stage exit, they still move forward—just with incomplete objectives recorded.
With 50+ completions, averages become meaningful. With 200+, statistically significant.
By default, non-linear. If you need enforced sequence, build dependency into completion criteria.
## Summary
Objectives are the measurement checkpoints within stages:
1. **Observational** — Track what happened, not what to do about it
2. **Keep them simple** — One clear milestone per objective
3. **Non-linear by default** — Customers can complete in any order
4. **Build toward patterns** — Value compounds as data accumulates
5. **Feed into Signals** — Slow completers become intervention targets
Configure objectives thoughtfully, let data accumulate, and use the patterns to drive intelligent interventions.
# People & Organisations
Source: https://docs.trig.ai/concepts/people-and-organisations
The foundational data objects that represent your customers
People and Organisations are the foundational data objects in Trig. Everything else—stages, behaviours, cohorts, jobs—operates on these two entity types.
## Overview
Individual end users who use your product. They log in, take actions, and derive value from what you've built.
Account-level entities—the companies, teams, or commercial units that contain People. In B2B, this is typically the customer who pays you.
The relationship is hierarchical: **People belong to Organisations**. This mirrors how B2B SaaS works—you sell to companies, but individuals within those companies use your product.
## Why this structure matters
Trig is built for B2B SaaS, where the fundamental commercial relationship is with an organisation, not an individual:
| Concept | Organisation Level | Person Level |
| ------------- | ------------------------------------------------ | --------------------------------------------------------------------- |
| **Churn** | When an org leaves, that's lost revenue | Individual churn is largely outside your control (people change jobs) |
| **Value** | Adoption across the organisation defines success | One power user doesn't make an account successful |
| **Decisions** | Renewals and expansions happen with the account | Individuals influence but rarely decide alone |
| **Lifecycle** | Onboarding, adoption, renewal are org journeys | People progress within the org context |
## People
### What people represent
People are the individual humans who use your product:
* **Identity:** Email address, user ID, name
* **Role/permissions:** Admin, user, viewer
* **Activity:** Events from product usage
* **Attributes:** Properties from CRM and product data
### People attributes
Attributes on People come from multiple sources:
**From CRM (HubSpot, Salesforce):**
* Contact record fields
* Lead status, stage
* Owner information
**From product data:**
* User role/permissions
* Sign-up date, last login
* Feature flags, plan information
**Generated by Trig:**
* Job membership and completion
* Behaviour entry and completion
* Calculated metrics
### People as job targets
When you create a job targeting People, the intervention goes to that specific person. Use individual-level jobs when:
* The action requires a specific person to do something
* You're targeting based on individual behaviour
* The communication should feel personal to that user's situation
```
Job: Complete Profile Setup
Target: People
Audience: Users who signed up > 3 days ago, profile_complete = false
Message: "Hi Sarah, complete your profile to unlock collaboration features..."
```
## Organisations
### What organisations represent
Organisations are the account-level entities—typically the companies or teams that are your customers:
* **Commercial relationship:** Who pays you, contract value, renewal date
* **Unit of churn:** When an org leaves, that's lost revenue
* **Container for users:** People belong to organisations
* **Target for lifecycle tracking:** Onboarding, adoption, expansion happen at org level
### Organisation attributes
**From CRM:**
* Account/Company record fields
* ARR, contract value, plan tier
* Industry, company size, segment
* Account owner, CSM assignment
**From product data:**
* Team/workspace information
* Aggregate usage metrics
* Feature adoption flags
**Rolled up from People:**
* Total users, active users
* Aggregate event counts
* Sum/average of individual metrics
**Generated by Trig:**
* Stage membership
* Job history
* Health scores, risk flags
### Roll-ups: aggregating people data
Trig can roll up individual-level data to the organisation level:
| Roll-Up Type | Example |
| ------------ | ---------------------------------- |
| **Sum** | Total events across all users |
| **Count** | Number of users who did X |
| **Average** | Mean value across users |
| **Max/Min** | Highest or lowest individual value |
```
Organisation: Acme Corp
├── users_count: 47
├── active_users_last_30d: 32
├── total_invoices_created: 1,247
├── avg_sessions_per_user: 4.2
└── power_users_count: 5
```
### Organisations as job targets
When you create a job targeting Organisations, the intervention can go to:
* The account owner (from CRM)
* All contacts at the organisation
* A specific role at the organisation
```
Job: Integration Setup
Target: Organisation
Audience: Orgs in Onboarding stage > 14 days, integrations_connected = 0
Message to Account Owner: "Hi, your team at Acme Corp is ready for the next step..."
```
### Stages and organisations
Stages operate at the Organisation level. Your customer journey is an account journey:
```
Organisation: Acme Corp
├── Current Stage: Adoption
├── Stage Entry: November 15, 2025
├── Objectives:
│ ├── ✓ First project created (Day 2)
│ ├── ✓ Team members invited (Day 5)
│ ├── △ Integration connected (pending)
│ └── ✗ Report generated (not started)
```
Even though individuals complete objectives (Sarah created the first project), tracking happens at the org level (Acme Corp completed "First project created").
## How people connect to organisations
Every Person in Trig should be associated with an Organisation:
```
Organisation: Acme Corp (ID: acme-123)
├── Person: sarah@acme.com (Admin)
├── Person: john@acme.com (User)
├── Person: lisa@acme.com (User)
└── Person: mike@acme.com (Viewer)
```
The identifier that links them varies:
* **CRM-based:** HubSpot Company ID, Salesforce Account ID
* **Product-based:** Team ID, Workspace ID, Tenant ID
## Data sources
### CRM integration
The primary source for Organisation and People data:
| CRM | Organisations | People |
| -------------- | ------------- | -------- |
| **HubSpot** | Companies | Contacts |
| **Salesforce** | Accounts | Contacts |
CRM integration provides commercial data (ARR, contract dates), relationship data (account owner), and firmographic data (industry, size).
### Product data integration
Product data typically comes from:
* **Data warehouses:** Snowflake, BigQuery, Redshift
* **CDPs and analytics:** Segment, Mixpanel, Amplitude, Pendo
* **Direct API:** Custom integrations, webhooks
Product data provides usage events, user properties, feature adoption signals, and engagement metrics.
### Joining data sources
Trig needs to join CRM data with product data using a common identifier:
* Email address matching
* External ID synced between systems
* User ID stored in CRM
Work with your implementation team to establish the join strategy.
## Choosing the right target level
| Scenario | Target | Why |
| ------------------------------ | ------------ | -------------------------------- |
| "Has this user logged in?" | Person | Individual action |
| "Is this account healthy?" | Organisation | Account-level assessment |
| "Send email to inactive user" | Person | Individual targeting |
| "Flag accounts for CSM review" | Organisation | Account-level triage |
| "Invite team members" | Person | Specific individual needs to act |
| "Renew contract" | Organisation | Commercial decision |
## Best practices
### Data quality
* **Clean identifiers:** Ensure consistent IDs across systems
* **Complete associations:** Every Person should link to an Organisation
* **Regular sync:** Keep CRM and product data flowing
### Organisation structure
* **Mirror commercial relationships:** Your org structure should reflect how you sell and manage accounts
* **Consistent granularity:** Normalise to comparable units
* **Think about lifecycle:** Ensure orgs represent the unit whose journey you're tracking
### Job targeting
* **Match target to action:** If an individual needs to act, target People. If it's an account decision, target Organisations.
* **Consider the recipient:** Org jobs go to account owner by default
* **Use role filters:** Target specific roles when appropriate
## Summary
People and Organisations form the foundation of Trig:
1. **Organisations are accounts** — The commercial unit, the target of lifecycle tracking, the entity that churns or renews
2. **People are users** — The individuals who use your product, belong to organisations, and are often the target of interventions
3. **Data flows from CRM + product** — Trig joins commercial data with usage data
4. **Attributes accumulate** — Ingested, rolled-up, and Trig-generated attributes build rich context
5. **Target appropriately** — Choose People or Organisations based on who needs to act
# Signals
Source: https://docs.trig.ai/concepts/signals
Proactive alerts when customers need attention
Signals are Trig's proactive alerting system. They surface customers who need attention right now—identifying who is off track before problems compound.
## What are signals?
Rather than waiting for customers to churn or disengage, Signals detect early warning patterns and prompt timely intervention.
**Core concept:** Signals are point-in-time indicators that a specific action is needed across your customer base.
Think of Signals as a heat map showing where attention is needed most. They answer: "Of all my customers, who should I focus on today, and why?"
## Why signals matter
### The problem signals solve
Without Signals, finding customers who need help requires manual investigation:
* Export data to spreadsheets
* Calculate averages and compare
* Identify outliers
* Build target lists
* Hope you caught everyone
This is slow, error-prone, and doesn't scale.
### How signals change this
Signals automate the detection:
* Continuously evaluate all customers against criteria
* Surface those who are underperforming
* Quantify the revenue impact
* Enable immediate action via jobs
Instead of "go find problems," Signals say "here are the problems—what do you want to do about them?"
### The insight to action loop
```
Stage → Objectives defined
↓
Trig calculates averages
↓
Identifies customers below average
↓
Surfaces as Signal
↓
User creates Job from Signal
↓
Measures intervention impact
```
## How signals work
### The foundation: objectives and averages
Signals build on stages and objectives. When you configure objectives, Trig tracks:
* How many customers complete each objective
* How long it takes on average
* Which customers are still pending
This creates the baseline for "normal" behaviour.
### Detecting atypical customers
Signals identify customers who deviate from normal:
**Slow completers:** Customers who haven't completed an objective and have taken significantly longer than average (e.g., 2x the average completion time).
```
Objective: Connect Payment Gateway
Average completion time: 6 days
Signal threshold: 2x average (12 days)
Signal: "15 customers have been pending 'Connect Payment Gateway'
for more than 12 days (2x average). Revenue at risk: £47,000"
```
### The flag system
Trig continuously evaluates:
1. For every member of an objective, calculate average time to completion
2. For anyone who hasn't completed and exceeds threshold, set a flag
3. Aggregate flags into Signals for display and action
### From flags to signals
```
Individual flags:
├── Customer A: slow on Objective 1 (flagged)
├── Customer B: slow on Objective 1 (flagged)
├── Customer C: slow on Objective 1 (flagged)
└── Customer D: slow on Objective 2 (flagged)
Signal 1: "3 customers slow on Objective 1"
Signal 2: "1 customer slow on Objective 2"
```
Each Signal represents a group with a common issue addressable with a single intervention.
## Signal types
### Objective slow completers
Identifies customers taking longer than expected to complete objectives.
**How it works:**
1. Calculate average completion time for an objective
2. Identify pending customers who exceeded threshold (e.g., 2x average)
3. Surface as Signal with count and revenue at risk
**Example Signal:**
```
Signal: Slow Completers - "Create First Invoice"
Stage: Onboarding
Customers affected: 23
Revenue at risk: £127,000
Average completion: 4 days
These customers: 8+ days pending
```
**Why this matters:** Slow completers are at higher risk of:
* Failing to realise value
* Disengaging before activation
* Churning before renewal
### Future signal types (planned)
* **Low completion rate:** Objectives with completion percentage below threshold
* **Declining engagement:** Customers whose activity has dropped significantly
* **Expansion indicators:** Customers showing upsell-ready behaviours
* **Churn predictors:** Patterns historically associated with churn
## Viewing signals
### The signals dashboard
**Summary metrics:**
* Total customers at risk
* Total revenue at risk
* Number of active Signals
**Signal feed:**
* List of current Signals
* Count of affected customers
* Revenue impact
* Related objective/stage
### Navigation: quantity to clarity to activity
1. **Quantity:** How many Signals? Where's the biggest problem?
2. **Clarity:** Click into a Signal to see exactly which customers and why
3. **Activity:** Create a job directly from the Signal
### Stage-level view
Within a stage:
* Objectives and completion status
* Signals associated with each objective
* Quick stats: how many at risk, revenue impact
### Objective-level view
Drilling into an objective:
* All members in this objective
* Toggle to view only flagged customers
* Create job targeting Signal audience
## Acting on signals
### Creating jobs from signals
From any Signal, you can:
See exactly which customers are flagged
Launch with audience pre-populated from Signal
Configure messages for the specific issue
### Job strategy for signals
**Message relevance:** These customers are stuck on a specific objective. Address that blocker.
**Timing:** They're already slow. Act quickly once the Signal surfaces.
**Follow-up:** If the first intervention doesn't work, the Signal continues showing them.
### Iterative intervention
Once you've created a job from a Signal:
* Customers in the job are being addressed
* New customers falling behind appear in future Signal refreshes
* Add new customers to existing job or create new ones
## Configuring for signals
### Prerequisites
To generate Signals:
1. **Stages configured** with entry/exit criteria
2. **Objectives within stages** with completion criteria
3. **Customers in stages** actively progressing
4. **Sufficient data** for meaningful averages
### Objective design for effective signals
Design objectives that:
* **Represent meaningful milestones** (not trivial clicks)
* **Have clear completion criteria**
* **Are achievable in reasonable time**
* **Cover the critical path to value**
### Threshold considerations
| Threshold | Sensitivity | Trade-off |
| ---------------- | ----------- | ----------------------------- |
| **1.5x average** | High | Earlier alerts, more noise |
| **2x average** | Moderate | Balanced detection |
| **3x average** | Low | Fewer alerts, later detection |
## Signal workflow example
### Scenario: onboarding slow completers
**Setup:**
* Stage: Onboarding (Days 1 to 30)
* Objective: "Complete Profile Setup"
* Average completion: 3 days
* Threshold: 2x (6 days)
**Signal appears:**
```
Slow Completers - Complete Profile Setup
12 customers | £34,000 revenue at risk
```
**Investigation:**
* 8 are self-serve plan
* 4 are enterprise
* Mix of industries
**Action:**
Create job targeting these 12:
* Goal: profile\_complete = true
* Entry: "Here's why your profile matters and how to do it in 2 minutes..."
* Auto-exit: 7 days
**Outcome:**
* 8 complete (success)
* 4 exit without completing (need different approach)
* Signal updates with new slow completers
## Signals vs other objects
| Object | Purpose |
| -------------- | ---------------------------------------------------------------- |
| **Behaviours** | Track when customers achieve milestones (historical) |
| **Signals** | Alert when customers are failing to achieve milestones (ongoing) |
| **Cohorts** | Static/dynamic audience segments |
| **Jobs** | Intervention mechanisms |
Signals detect problems. Jobs address them.
## Best practices
### Start with core objectives
Don't Signal everything. Focus on:
* Objectives that predict success/failure
* Early stage milestones
* High-value customer segments
### Act quickly on signals
Signals surface customers already behind. Delay compounds the problem:
1. Review same day
2. Create job if warranted
3. Don't wait for perfect message
### Review signal patterns
If the same Signal keeps appearing:
* Is the objective realistic?
* Is there a product friction point?
* Do customers need more support?
Recurring Signals may indicate systemic issues.
### Don't over-intervene
* Customers shouldn't receive too many automated messages
* Some slowness may be acceptable (enterprise moves slower)
* Use exclusions to prevent job overlap
### Measure job impact
Track whether Signal-driven jobs improve outcomes:
* Do recipients complete faster than non-recipients?
* Does intervention reduce Signal population over time?
* What message content works best?
## Common questions
Continuously as customer data updates. New slow completers appear as they cross the threshold.
Thresholds are configured by Trig. Future versions may expose configuration in the UI.
You need sufficient completions for meaningful averages. Generally 10+ completions for stability.
v0.1 focuses on risk detection. Positive signals (expansion opportunities) are planned.
Summed from ARR/contract value of affected customers (from CRM data).
They're removed from the Signal. Job tracks this as completion.
## Summary
Signals transform Trig from observation to action:
1. **Built on objectives** — Require stages and objectives as foundation
2. **Automated detection** — Continuously evaluate all customers against thresholds
3. **Quantified impact** — Revenue at risk makes prioritisation clear
4. **Direct to action** — Create jobs directly from Signals
5. **Iterative** — New customers surfaced as they fall behind
Signals show you which customers need help before it's too late.
# FAQs
Source: https://docs.trig.ai/faqs
Frequently asked questions about Trig
Find answers to common questions about how Trig works, from core concepts to practical implementation.
## Getting started
Trig is a customer lifecycle management platform for B2B SaaS companies. It helps you track customers through their journey (onboarding, adoption, expansion, renewal), identify who needs attention using Signals, and orchestrate targeted interventions through jobs—all based on data from your CRM and product usage.
Trig integrates with:
* **CRM systems:** HubSpot, Salesforce
* **Data warehouses:** Snowflake, BigQuery, Redshift
* **Product analytics:** Mixpanel, Amplitude, Segment, Pendo
* **Communication tools:** Slack (for notifications), email (for customer outreach)
Yes. Stages are the foundation that enables everything else in Trig—pattern discovery, Signals, jobs, and measurement all depend on stages being configured first. Start with stages, then build on top.
## Stages
Without auto-exit, they remain indefinitely. Use time-based exit to ensure forward movement so you can analyse patterns of non-completion. Most implementations use time-based or hybrid exit criteria.
With 50+ organisations through a stage, averages become meaningful. With 200+, patterns become statistically significant. The more data you accumulate, the more reliable your benchmarks.
Yes. Adding new objectives is straightforward—existing organisations will simply have no completion data for new objectives. Modifying existing objective criteria may affect historical comparisons.
The platform is optimised for B2B where organisations are the primary unit. For B2C, the "organisation" becomes the individual user—the mechanics work, but the terminology and defaults are B2B-oriented.
Yes, though this requires careful design. Common use cases include different stages for different products, or parallel tracks for different user types within the same organisation.
## Objectives
By default, objectives are non-linear—customers can complete them in any order. If you need to enforce sequence (Objective B requires Objective A), build that dependency into the completion criteria.
The organisation shows as incomplete for that objective. With time-based stage exit, they still move forward—just with incomplete objectives recorded. This data is valuable for understanding where customers struggle.
Start with 4 to 7 objectives per stage. Too few loses granularity; too many creates noise. Focus on milestones that are meaningful and trackable.
Yes, but changing criteria may affect historical interpretation. If you change "invoices >= 1" to "invoices >= 3", previously completed orgs may now show incomplete.
## Behaviours
The one-and-done design preserves milestone tracking integrity. Behaviours capture "first time" moments—like the first time a customer became a power user or completed setup. Use cohorts instead for tracking recurring states.
Use threshold behaviours: "First time", "5+ times", "10+ times" as separate behaviours. Or use cohorts for tracking current state that can change over time.
Objectives are behaviours within stages. Same mechanics (entry criteria, completion criteria, actions), but objectives carry additional meaning for stage progression tracking and contribute to building "normal" benchmarks.
Yes. Entry, completion, and exit actions fire as soon as the condition is met.
Events are evaluated forward-only (only new events trigger). Attributes are evaluated historically (checked against existing values). This is a critical distinction for designing behaviours correctly.
You can, but changing criteria affects historical interpretation. It's often better to create a new behaviour with updated criteria rather than modify an existing one.
## Cohorts
Dynamically when queried. As customer attributes change, membership automatically adjusts. Your cohorts always reflect current reality.
Yes. Viewing a cohort shows current members with their attributes.
Not directly. Use the underlying attributes or combine filter groups to achieve similar results.
Jobs lose that targeting criteria. Check dependencies before deleting any cohort.
No. A cohort is either organisation-level or people-level. Create separate cohorts for each entity type.
## Jobs
Keep jobs short and focused. 3 to 7 days for simple actions, 7 to 14 days for moderate actions, 14 to 30 days for complex actions. If no response in 14 days, try a different approach in a new job.
Yes, but be careful about message volume. Use exclusion criteria to prevent overlap and avoid overwhelming customers with too many automated messages.
No new customers enter. Existing customers can still complete or exit normally.
Use `last_entered_[job] has any value` in your exclusion criteria to prevent customers who've already been through the job from re-entering.
Either works. Trig sends directly for speed and simplicity. For complex requirements, trigger external systems via webhooks.
Plain text emails look like they came from a real person, get 10x higher engagement, feel human even when automated, and avoid spam filters. Branded HTML templates scream "marketing automation" and get lower response rates.
## Signals
Continuously as customer data updates. New slow completers appear as they cross the threshold.
Thresholds are configured by your Trig implementation team. Future versions may expose configuration in the UI.
You need sufficient completions for meaningful averages. Generally 10+ completions for stability, 50+ for reliable patterns. With less data, averages are less reliable.
Currently Signals focus on risk detection (slow completers). Positive signals like expansion opportunities are planned for future releases.
Summed from ARR/contract value of affected customers (from CRM data).
They're removed from the Signal. If they completed via job, the job tracks this as completion.
Current version shows active Signals. Historical tracking is planned for future releases.
## Attributes and data
**Attributes** are static values on a record, evaluated historically (checked against existing values), and persist until changed. **Events** are point-in-time occurrences, evaluated forward-only (only new events trigger), and form a stream of discrete actions. This distinction is critical for job design.
For every job, behaviour, stage, and objective, Trig automatically generates attributes:
* `currently_member_of_[object]` — Are they currently in?
* `last_entry_to_[object]` — When did they enter?
* `last_exit_from_[object]` — When did they exit (failed)?
* `last_completion_of_[object]` — When did they complete?
These persist forever and enable powerful job chaining and historical analysis.
Yes. Trig supports roll-up aggregations including Sum, Count, Average, Min, and Max. For example, you can roll up total logins across all users, count of active users, or average session duration to the organisation level.
## People and organisations
Trig is built for B2B SaaS where the fundamental commercial relationship is with an organisation. When an org leaves, that's lost revenue. Renewals and expansions happen at the account level. Individuals influence but rarely decide alone. The lifecycle journey is fundamentally an account journey.
Target **People** when an individual needs to take action (complete profile, use a feature, invite teammates). Target **Organisations** when it's an account-level decision (renew contract, upgrade plan, connect integration that affects the whole team).
Through a common identifier that links them—typically a CRM Company ID, Account ID, or a product-based Team/Workspace/Tenant ID. Every Person should be associated with an Organisation.
## Email and actions
Before sending emails, you need domain verification (DNS records), sender configuration (who emails appear from), and subdomain setup for deliverability. This is handled during onboarding.
Yes. Insert attribute placeholders like `{first_name}`, `{organization_name}`, or `{days_since_signup}` in any message field. Any attribute on the customer record can be used.
The placeholder will be empty. Test messages with real customer data to ensure correct rendering before launching jobs.
Yes. Include an email attribute with @ to ping that person directly in Slack, like `@{case_owner_email}`.
## Best practices
1. Connect your data integrations (CRM, product data)
2. Configure stages with 4 to 7 objectives each
3. Let data accumulate for 2 to 4 weeks to build baselines
4. Review Signals to identify customers needing attention
5. Create targeted jobs based on Signal insights
6. Measure and iterate based on results
Most jobs use 1 to 2 follow-ups. More than that often means your job is too broad or the goal is too ambitious. If someone hasn't responded after 2 follow-ups, try a different approach in a new job.
Depends on your sales cycle:
* **30 days** for SMB, self-serve, low-touch (fast cycles, quick decisions)
* **60 days** for mid-market (time for 1-2 intervention attempts)
* **90+ days** for enterprise (complex buying processes, multiple stakeholders)
Look at retained vs churned customers: What did retained customers do early on that churned customers didn't? Find the behaviour with the biggest retention gap between doers and non-doers. This is your critical "aha moment" objective.
## Troubleshooting
Check that: entry criteria are correct, data is flowing for the criteria attributes, and organisations exist that should match. Use the Audience view to test your filters.
Verify the attribute/event name is correct, check that data is updating when customers act, and test with a known customer who should have completed.
Check that: the job is live (not paused), customers match the audience criteria, email integration is configured, and the sender is verified.
Signals require: stages configured and live, objectives with completion criteria, customers actively in stages, and sufficient completions for averages (10+).
Attributes only appear after first use. Ensure the job/stage/behaviour has been set live and at least one customer has entered.
# Building Jobs
Source: https://docs.trig.ai/guides/building-campaigns
Create effective interventions that drive customer action
This guide walks you through building jobs in Trig—from defining your goal to launching and measuring results.
## Job fundamentals
Every job needs three things:
What do you want customers to do?
Who should receive this intervention?
What messages will you send?
## Step 1: Define your goal
### What makes a good goal?
Goals should be:
* **Single action** — One clear thing you want them to do
* **Measurable** — Based on an attribute or event you can track
* **Achievable** — Something the customer can realistically complete
### Goal examples
| Job Type | Goal |
| ---------------- | ---------------------------- |
| Onboarding nudge | `projects_created >= 1` |
| Feature adoption | `feature_X_used >= 1` |
| Expansion | `upgrade_completed = true` |
| Churn prevention | `engagement_restored = true` |
**Avoid compound goals.** If you need multiple actions, create separate jobs.
## Step 2: Define your audience
### Targeting options
**Using attributes directly:**
```
sign_up_date > 1 day ago
AND sign_up_date < 7 days ago
AND invoices_created = 0
```
**Using cohorts:**
```
Member of cohort "New Self-Serve Users"
```
**Using Trig metadata:**
```
last_completed_Onboarding_Stage has any value
AND last_completed_First_Invoice_Job has no value
```
### Exclusions
Always consider who should NOT receive this job:
```
Audience:
- sign_up_date > 3 days ago
- invoices_created = 0
Exclusions:
- last_entered_[this_job] has any value (already been through)
- currently_member_of_[other_job] = true (prevent overlap)
```
### Organisation vs people
| Target | When to Use |
| ---------------- | ------------------------------------------------ |
| **Organisation** | Account-level decisions, commercial actions |
| **People** | Individual behaviour, specific user needs to act |
## Step 3: Set duration
### Auto-exit timing
Every job should have an auto-exit duration:
| Action Complexity | Duration |
| -------------------------------- | ------------- |
| Simple (click, view) | 3 to 7 days |
| Moderate (setup step) | 7 to 14 days |
| Complex (invite team, integrate) | 14 to 30 days |
**Err shorter.** If someone hasn't responded in 14 days, another email in the same job probably won't help—try a different approach.
## Step 4: Configure entry actions
### Send initial email
The entry email is your first touch. Make it count.
**Configuration:**
* **Sender:** A real person (e.g., "Lee at FreshBooks")
* **Subject:** Specific and actionable
* **Body:** Plain text, contextual, with clear steps
**Example:**
```
Subject: Quick tip to send your first invoice
Hi {first_name},
I noticed your team at {organization_name} signed up recently
but hasn't sent an invoice yet.
Here's how to send your first one—takes about 5 minutes:
1. Click "Create Invoice" in the left menu
2. Add your client's email
3. Click Send
If you run into any issues, just reply to this email.
Thanks,
Lee
```
### Best practices for entry emails
Reference what they have and haven't done. Show you know their situation.
Give 1 to 3 clear steps. Include links where helpful.
3 to 5 sentences for simple actions. No long paragraphs.
Plain text, from a real person, with a personal sign-off.
## Step 5: Configure follow-up actions
### Adding reminders
If customers haven't completed after the initial email, send a follow-up:
```
Wait 3 days → Send follow-up email
Wait 7 days → Send second follow-up (optional)
```
### Follow-up email strategy
**First follow-up (Day 3 to 5):**
* Reference that you've reached out before
* Try a different angle
* Shorter than the original
```
Subject: Re: Quick tip to send your first invoice
Hi {first_name},
Following up on my earlier email—I wanted to make sure you
saw the steps to send your first invoice.
If you're running into any issues, just reply and I'll help.
Thanks,
Lee
```
**Second follow-up (Day 7 to 10):**
* Acknowledge they might be busy
* Offer help or a call
* This is often your last automated touch
**Most jobs use 1 to 2 follow-ups.** More than that often means your job is too broad or goal is too ambitious.
## Step 6: Configure completion actions
### What happens on success
When a customer achieves the goal:
**Options:**
* Send congratulations message
* Notify your team (Slack)
* Update CRM field
* Route to next job
**Example:**
```
Completion Actions:
├── Message Customer: "Great job sending your first invoice!"
├── Notify Team: "#wins - {organization_name} completed onboarding"
└── Update Attribute: completed_onboarding_job = true
```
### Silent completion
Not every job needs a completion message. For feature adoption jobs, silent completion is often appropriate.
## Step 7: Configure exit actions
### What happens on failure
When a customer exits without completing:
**Options:**
* Notify team for manual follow-up
* Update attribute for tracking
* Route to alternative job
**Example:**
```
Exit Actions:
├── Notify Team: "@{csm_email} - {organization_name} failed onboarding, needs follow-up"
└── Update Attribute: failed_onboarding_job = true
```
### Chaining to alternate jobs
Use exit actions to create branching journeys:
```
Job: Onboarding Nudge v1
├── Completed → Route to "Feature Adoption" job
└── Exited → Route to "Onboarding Nudge v2" (different approach)
```
## Step 8: Review and launch
### Pre-launch checklist
Goal is clear and measurable
Audience returns expected customers
Duration is appropriate for the action
Entry email is specific, actionable, and human
Follow-ups are spaced appropriately
Completion and exit actions configured
Exclusions prevent re-entry and overlap
### Launch the job
Double-check all settings
Verify the number of customers who will enter
Click **Go Live**
Watch the first few days for issues
## Job chaining patterns
### Success path
After completing Job 1, move to Job 2:
```
Job 2 Audience:
- last_completed_Job_1 has any value
- [next action criteria]
```
### Failure path
After failing Job 1, try Job 1B:
```
Job 1B Audience:
- last_exited_Job_1 has any value
- last_completed_Job_1 has no value
```
### Progressive journey
```
Welcome → Onboarding → Feature Adoption → Expansion
↓ ↓ ↓
Retry A Retry B CSM Outreach
```
## Measuring job effectiveness
### Key metrics
| Metric | Formula | Target |
| ---------------------- | -------------------------------- | ------------------- |
| **Completion rate** | Completed / (Completed + Exited) | 20 to 40% |
| **Time to completion** | Avg days to complete | As fast as possible |
| **Entry to exit rate** | Exited / Total entered | Lower is better |
### What to optimise
| If... | Then... |
| ------------------------------ | --------------------------------- |
| Low completion rate | Adjust messaging, timing, or goal |
| Long time to completion | Intervention may be too early |
| High exit at specific point | Focus messaging there |
| Certain segments complete more | Target them specifically |
## Common job patterns
### Onboarding nudge
```
Goal: first_project_created >= 1
Audience: signup 1 to 7 days ago, no project created
Duration: 10 days
Entry: Plain text email with steps
Follow-up: Day 3, Day 7
Completion: Notify team
Exit: Route to "Onboarding Stalled" job
```
### Feature adoption
```
Goal: feature_X_used >= 1
Audience: Premium plan, never used feature X, 30+ days old
Duration: 14 days
Entry: Email highlighting feature value
Follow-up: Day 5 with different angle
Completion: Silent
Exit: Flag for CSM
```
### Churn prevention
```
Goal: engagement_restored = true
Audience: renewal in 90 days, no login in 30 days
Duration: 30 days
Entry: Personal outreach from CSM
Follow-up: Week 2, Week 3
Completion: Notify sales
Exit: Escalate to sales
```
## Troubleshooting
### "Job isn't sending emails"
* Is the job live (not paused)?
* Are there customers matching the audience?
* Is email integration configured?
* Is the sender verified?
### "Wrong customers entering"
* Review audience criteria
* Check for typos in attribute names
* Verify date logic (before/after)
### "Low completion rate"
* Is the goal achievable?
* Is messaging specific enough?
* Is timing right (too early? too late?)
* Are you targeting the right audience?
## Summary
Building effective jobs:
1. **Clear goal** — Single, measurable action
2. **Right audience** — Specific targeting with exclusions
3. **Appropriate duration** — Time-bounded, err shorter
4. **Human messaging** — Plain text, specific, actionable
5. **Strategic follow-ups** — 1 to 2 max, vary the angle
6. **Complete the loop** — Actions on both completion and exit
7. **Chain thoughtfully** — Build progressive journeys
Well-designed jobs turn insight into action and create measurable impact on customer success.
# Configuring Stages
Source: https://docs.trig.ai/guides/configuring-lifecycle-stages
Step-by-step guide to setting up your customer journey
This guide walks you through configuring stages for your business—from planning your customer journey to launching live stages with objectives.
## Before you start
### Prerequisites
Ensure you have:
* **Data integrations connected** — CRM and product data flowing into Trig
* **Organisations in Trig** — Customer accounts visible in the Audience view
* **Internal alignment** — Agreement on what your customer journey looks like
### Planning questions
Before creating stages, answer these for each stage of your journey:
| Question | Example Answer |
| ---------------------------------- | ---------------------------------------------------- |
| What period does this stage cover? | Days 1 to 30 after signup |
| What happens in this stage? | Initial setup, first value |
| How do customers enter? | First seen date within 30 days |
| How do customers exit? | After 30 days OR all objectives complete |
| What 4 to 7 milestones matter? | Created project, invited team, connected integration |
## Step 1: Map your customer journey
### Identify your stages
Most B2B SaaS companies use four stages:
```
Onboarding → Adoption → Expansion → Renewal
```
For each stage, define:
What period of the journey? How long does it typically last?
What triggers entry? Time-based, event-based, or completion of previous stage?
What 4 to 7 milestones define healthy progression?
When does this stage end? Completion-based, time-based, or hybrid?
### Example: Onboarding stage
| Attribute | Value |
| ------------------ | ----------------------------------------------------------------------------------------- |
| **Name** | Onboarding |
| **Duration** | Days 0 to 30 |
| **Entry criteria** | `first_seen_date` within last 30 days |
| **Exit criteria** | Time-based: Auto-exit after 30 days |
| **Objectives** | Created first project, Invited team member, Connected integration, Generated first report |
## Step 2: Create your first stage
Go to **Dashboard > Stages** in the main navigation
Click **Create Stage** and enter:
* **Name:** Onboarding
* **Description:** Initial setup and first value milestones
Define when organisations enter:
```
first_seen_date is within last 30 days
```
For your first stage, use time-based exit:
```
Auto-exit after 30 days
```
Review and save. Don't launch yet—add objectives first.
**Start with time-based exit.** You can refine to completion-based exit once you understand typical customer patterns.
## Step 3: Add objectives
### Identify 4 to 7 key milestones
For each stage, identify the actions that indicate healthy progression:
**Onboarding stage example:**
* Created first project
* Invited a team member
* Connected an integration
* Generated first report
* Completed a full week of usage
### Create each objective
Click into the stage you just created
Click **Add Objective** and configure:
* **Name:** Created First Project
* **Completion criteria:** `projects_created >= 1`
Add 3 to 5 additional objectives with clear completion criteria
### Completion criteria examples
| Objective | Criteria |
| ---------------------- | ----------------------------- |
| Created First Project | `projects_created >= 1` |
| Invited Team Member | `team_members >= 2` |
| Connected Integration | `integrations_connected >= 1` |
| Generated First Report | `reports_generated >= 1` |
| Completed Full Week | `days_with_activity >= 7` |
### Objective best practices
**Keep objectives simple.** Each objective should track one clear milestone. Complex objectives with multiple AND conditions are harder to interpret.
**Good objective:**
```
Name: Created First Project
Criteria: projects_created >= 1
```
**Too complex:**
```
Name: Fully Onboarded
Criteria: projects_created >= 1 AND team_members >= 2 AND integrations >= 1
```
Better as three separate objectives.
## Step 4: Configure additional stages
### Create Adoption stage
| Attribute | Value |
| -------------- | ----------------------------------------------- |
| **Name** | Adoption |
| **Entry** | `last_completed_onboarding_stage` has any value |
| **Exit** | Auto-exit after 90 days |
| **Objectives** | Feature depth, Team growth, Regular usage |
### Create Expansion stage
| Attribute | Value |
| -------------- | -------------------------------------------------------------- |
| **Name** | Expansion |
| **Entry** | `last_completed_adoption_stage` has any value |
| **Exit** | Ongoing (no auto-exit) |
| **Objectives** | Premium feature exploration, Seat utilisation, Upgrade signals |
### Create Renewal stage
| Attribute | Value |
| -------------- | ------------------------------------------------------------- |
| **Name** | Renewal |
| **Entry** | `renewal_date` within 90 days |
| **Exit** | Renewal complete or churned |
| **Objectives** | Engagement maintained, Health score stable, Renewal confirmed |
## Step 5: Validate before launch
### Check data availability
For each objective, confirm:
* The event or attribute exists in your data
* It's flowing into Trig correctly
* It updates when customers take the action
### Review audience size
In the stage configuration:
* Check how many organisations would enter
* Verify this matches your expectations
* Spot-check individual organisations
### Test with sample organisations
Look at 3 to 5 specific organisations:
* Would they enter this stage correctly?
* Would objectives mark complete when expected?
* Are there edge cases you haven't considered?
## Step 6: Launch your stages
Double-check entry criteria, exit criteria, and all objectives
Click **Go Live** to activate the stage
Watch the first few days to ensure:
* Organisations are entering correctly
* Objectives are completing as expected
* No unexpected edge cases
## After launch
### Monitor key metrics
In the first few weeks, watch:
| Metric | What to Look For |
| ------------------------ | ------------------------------------------- |
| **Entry rate** | Are organisations entering as expected? |
| **Objective completion** | Are objectives completing when they should? |
| **Average times** | Are averages building as data accumulates? |
| **Edge cases** | Any organisations stuck unexpectedly? |
### Refine based on data
After 2 to 4 weeks, review:
* **Objectives with 0% completion:** Maybe too hard or wrong criteria
* **Objectives with 100% instant completion:** Maybe too easy or automatic
* **Objectives that predict success:** Prioritise in interventions
* **Objectives that predict churn:** Add early warning jobs
### Iterate
Stages improve over time:
* Add new objectives as you learn what matters
* Adjust thresholds that are too easy or hard
* Remove objectives that provide no signal
* Refine exit criteria based on observed patterns
## Common configuration patterns
### PLG / self-serve
```
Stage: Onboarding
Entry: first_seen_date within 14 days
Exit: Auto-exit after 14 days
Duration: Short, focused
Objectives:
- Completed signup flow
- Explored core feature
- Returned second day
- Invited first team member
```
### Sales-led / enterprise
```
Stage: Onboarding
Entry: contract_signed = true
Exit: All objectives complete OR 60 days
Duration: Longer, more objectives
Objectives:
- Kickoff call completed
- Admin users configured
- SSO connected
- First use case deployed
- Training completed
- Business owner engaged
```
### Hybrid
```
Stage: Onboarding
Entry: first_seen_date within 30 days
Exit: Auto-exit after 30 days
Objectives vary by segment:
- Self-serve: 4 objectives, simpler criteria
- Sales-led: 6 objectives, include manual steps
```
## Troubleshooting
### "No organisations entering stage"
* Check entry criteria—are they correct?
* Verify data is flowing for the criteria attributes
* Confirm organisations exist that should match
### "Objectives not completing"
* Verify the attribute/event name is correct
* Check that data is updating when customers act
* Test with a known customer who should have completed
### "Too many organisations stuck"
* Review exit criteria—is there a path forward?
* Consider time-based exit as safety net
* Check if objectives are too difficult
## Summary
Configuring stages:
1. **Plan first** — Map your journey, identify stages and objectives
2. **Start simple** — One stage with 4 to 5 objectives, time-based exit
3. **Verify data** — Ensure attributes exist and flow correctly
4. **Launch and monitor** — Watch initial data, catch issues early
5. **Iterate** — Refine based on observed patterns
Once configured, stages become the foundation for pattern discovery, Signals, and job interventions.
# Using Signals
Source: https://docs.trig.ai/guides/using-signals
Proactively surface and act on customers who need attention
This guide shows you how to use Signals to identify at-risk customers and create targeted interventions.
## Understanding signals
Signals automatically surface customers who are falling behind. Rather than manually hunting for problems, Signals tell you exactly who needs attention and why.
### What signals show you
```
Signal: Slow Completers - "Create First Invoice"
Stage: Onboarding
Customers affected: 23
Revenue at risk: £127,000
Average completion: 4 days
These customers: 8+ days pending
```
Each Signal tells you:
* **Which objective** customers are stuck on
* **How many** are affected
* **Revenue at risk** (from CRM data)
* **How far behind** they are compared to average
## Prerequisites
To generate Signals, you need:
Stages configured and live
Objectives defined with completion criteria
Customers actively in stages
Sufficient completions for meaningful averages (10+)
## Navigating signals
### The signals dashboard
Navigate to **Signals** in the main navigation to see:
**Summary metrics:**
* Total customers at risk
* Total revenue at risk
* Number of active Signals
**Signal feed:**
* List of current Signals
* Sorted by revenue impact
* Click any Signal to see details
### Drilling into a signal
Click on a Signal to see:
1. **Which customers** are affected (list with key attributes)
2. **How long** each has been pending
3. **Revenue** associated with each
4. **Quick action** to create a job
## Acting on signals
### Reviewing the signal
Before creating a job, review:
| Question | What to Look For |
| ------------------------------ | --------------------------------------- |
| Is this worth acting on? | Revenue at risk, customer importance |
| Why are they stuck? | Common attributes, patterns |
| What intervention makes sense? | Email, CSM outreach, different approach |
### Creating a job from a signal
From the Signals dashboard, click into the Signal you want to act on
Check the list to understand who's included
This pre-populates the audience with the Signal's customers
Set goal, duration, and messaging specific to this issue
Go live to start the intervention
### Job strategy for signals
**Address the specific blocker:**
These customers are stuck on a specific objective. Your message should directly address that issue.
```
Subject: Quick tip to connect your payment gateway
Hi {first_name},
I noticed you've been using FreshBooks to send invoices—great progress!
The next step is connecting your payment gateway so clients can pay
online. Here's how:
1. Go to Settings > Payments
2. Click "Connect Gateway"
3. Follow the prompts for Stripe or PayPal
Takes about 5 minutes and means faster payments.
Reply if you need help!
Thanks,
Lee
```
**Keep it timely:**
They're already behind. Act quickly once you see the Signal.
**Set appropriate duration:**
They've been slow, so give them reasonable time—but don't let it drag on.
## Signal workflow example
### Scenario: Onboarding slow completers
**Signal appears:**
```
Slow Completers - Complete Profile Setup
12 customers | £34,000 revenue at risk
Average: 3 days | These customers: 8+ days
```
**Step 1: Review**
* Click into the Signal
* See the 12 customers listed
* Notice 8 are self-serve, 4 are enterprise
* Mix of industries and sizes
**Step 2: Decide**
Worth intervening? Yes—profile completion is a key onboarding step, and £34K revenue is significant.
**Step 3: Create Job**
```
Job: Profile Completion Nudge
Goal: profile_complete = true
Audience: [Pre-populated from Signal]
Duration: 7 days
Entry Action: Email
Subject: Complete your profile in 2 minutes
Hi {first_name},
I noticed you're getting started with [Product] but haven't
completed your profile yet.
Here's why it matters:
- [Benefit 1]
- [Benefit 2]
Here's how (takes 2 minutes):
1. Click your avatar → Settings
2. Fill in the profile fields
3. Click Save
Reply if you have questions!
```
**Step 4: Launch and Monitor**
* Go live
* Monitor completion rate
* Review results after 7 days
**Step 5: Iterate**
* 8 complete → Success
* 4 exit → Need different approach? Manual CSM outreach?
* New Signal appears next week with fresh slow completers
## Patterns and best practices
### Act quickly on signals
Signals show customers already behind. Delay compounds the problem.
| Timing | Recommendation |
| --------------- | ----------------------- |
| Same day | Review new Signals |
| Within 24 hours | Create job if warranted |
| Within 48 hours | Job should be live |
### Don't over-intervene
* Customers shouldn't receive too many automated messages
* Some slowness may be acceptable (enterprise often moves slower)
* Use exclusions to prevent job overlap
### Review recurring signals
If the same Signal keeps appearing:
| Question | Implication |
| --------------------------- | --------------------------------------- |
| Is the objective realistic? | Maybe the expected timing is wrong |
| Is there product friction? | Maybe customers struggle with this step |
| Do they need more support? | Maybe more guidance is needed |
Recurring Signals may indicate systemic issues, not just individual customer problems.
### Measure job impact
After running Signal-driven jobs:
* Did recipients complete faster than non-recipients?
* Did the intervention reduce the Signal population?
* What message content worked best?
This closes the loop and validates your approach.
## Prioritising signals
When you have multiple Signals, prioritise by:
### Revenue at risk
Higher revenue = higher priority, generally.
### Stage importance
Early stage Signals (onboarding) often deserve priority—these customers haven't yet realised value.
### Intervention feasibility
Some Signals are easier to act on than others. A clear onboarding step is easier to nudge than a complex integration.
### Segment
If you have segments that matter more (enterprise, high-value), prioritise Signals affecting those.
## Advanced: Signal-driven workflows
### Automated job triggers
Instead of manually creating jobs from Signals, you can set up jobs that automatically target slow completers:
```
Job: Onboarding Objective 3 Nudge
Audience:
- currently_member_of_onboarding_stage = true
- days_in_stage >= 14
- objective_3_completed = false
```
This creates a standing job that catches customers as they become slow completers.
### Combining signals with cohorts
Create cohorts based on Signal-like criteria:
```
Cohort: Stuck in Onboarding
- currently_member_of_onboarding_stage = true
- days_in_stage >= 2x average
- objectives_completed < 50%
```
Then use this cohort for multiple purposes:
* Job targeting
* CSM alerts
* Executive reporting
## Common questions
Continuously as customer data updates. New slow completers appear as they cross the threshold.
Signals require sufficient completions for meaningful averages. Generally 10+ completions for stability. With less data, averages are less reliable.
Thresholds are configured by your Trig implementation team. Future versions may expose configuration in the UI.
They're removed from the Signal. If they completed via job, the job tracks this as completion.
Current version shows active Signals. Historical tracking is planned for future releases.
## Troubleshooting
### "No Signals appearing"
* Are stages configured and live?
* Are there objectives with completion criteria?
* Are customers in the stages?
* Are there enough completions for averages?
### "Signal customers not entering job"
* Does the job audience match the Signal criteria?
* Are there exclusions blocking entry?
* Is the job live?
### "Intervention not working"
* Is messaging specific to the blocker?
* Is timing right?
* Do customers understand what to do?
* Is the goal achievable?
## Summary
Using Signals effectively:
1. **Review regularly** — Check Signals daily or every few days
2. **Act quickly** — Don't let slow completers get slower
3. **Be specific** — Address the exact blocker in your messaging
4. **Measure impact** — Track whether interventions improve completion
5. **Look for patterns** — Recurring Signals may indicate systemic issues
6. **Iterate** — Use what you learn to improve future interventions
Signals transform reactive customer success into proactive intervention. Use them to catch problems before they compound.
# Welcome to Trig
Source: https://docs.trig.ai/index
The customer lifecycle platform that turns insight into action
Trig helps B2B SaaS companies understand their customer journey, identify who needs attention, and intervene at exactly the right moment. One platform configuration enables pattern discovery, early warning, automated interventions, and impact measurement.
## How Trig Works
Trig connects your CRM and product data to build a complete picture of every customer's journey. By tracking progression through stages, Trig establishes what "normal" looks like and spots customers who are ahead or behind.
Track customer progression through stages with objectives that define healthy behaviour
Signals automatically surface customers who need attention before problems compound
Jobs deliver timely, contextual outreach to move customers toward success
Track completion rates and intervention impact to continuously improve
## Get Started
Get launched in Trig with our step-by-step setup guide
## Core Concepts
Trig is built around a set of interconnected objects that work together to power your customer success operations.
The foundational entities that represent your customers
Define the phases of your customer journey
Track milestones within each stage
Capture milestone moments in customer activity
Reusable audience segments for targeting
Orchestrate interventions to drive customer success
Execute interventions via email, Slack, and webhooks
Proactive alerts when customers need attention
The data points that describe your customers
## The Trig Platform
![Trig Platform Objects 1]()
## Why Trig?
### Close the gap between insight and action
Most customer success tools tell you what's happening. Trig helps you do something about it. The insight that "47 customers haven't completed onboarding" becomes actionable when you can immediately target them with a relevant message.
### Timely, contextual intervention
The closer an intervention arrives to the moment of need, the more effective it is. Trig jobs trigger based on real-time criteria, collapsing the gap between "customer needs help" and "customer receives help."
### One configuration, multiple value drivers
Without stages, every analysis requires separate data work. With Trig's unified configuration, pattern discovery, early warning, automated interventions, and impact measurement all become possible on a shared foundation.
# HubSpot
Source: https://docs.trig.ai/integrations/crm/hubspot
Connect Trig to HubSpot to sync contacts, companies, deals, and custom properties
## What it does
Trig connects to HubSpot to pull in your contacts and companies as people and organisations in Trig and keep them in sync as records change in HubSpot. Once connected, anything you've stored as a HubSpot property (owner, lifecycle stage, custom fields) is available for cohorts, signals, and campaign personalisation. Trig can also write field updates back to HubSpot, but only when an explicit Trig Job is configured to do so. Actions within a Job are the things that perform the update.
## Before you start
You'll need:
* **A HubSpot Super Admin** to install the Trig app the first time. After install, day-to-day re-authorisation can be done by any user with read access to the relevant objects, but we recommend authorising via a dedicated integration user (see Permissions & scopes).
* Access to the HubSpot portal you want to connect. If you manage multiple portals, you'll pick the right one from the picker shown during the OAuth flow.
* A list of the **custom properties** you want Trig to import. You can change this later, but it's helpful to know in advance.
You don't need to create a private app or generate API keys. Trig uses HubSpot's OAuth flow.
## Connect HubSpot
1. In Trig, go to **Settings → Integrations → CRM**.
2. Click **Add a CRM integration** and choose **HubSpot**.
3. Click **Connect**. You'll be redirected to HubSpot to authorise Trig.
4. Select the HubSpot account to connect, review the requested scopes, and click **Connect app**.
5. You'll be redirected back to Trig. Your integration is now connected.
By default, the first **full import** runs on the next scheduled cycle (within 24 hours). If you'd like to bring data in immediately, ask your Trig contact to trigger an initial sync.
## What data flows
### Imported from HubSpot
**Contacts** become **People** in Trig. By default Trig imports:
* `firstname`, `lastname`, `email`, `country`, `jobtitle`
* `hs_email_optout` (used to respect opt-outs in Trig sends)
* `hubspot_owner_id`, `hubspot_team_id` (mapped to Trig owners/teams)
* `associatedcompanyid` (links the person to their org in Trig)
* Any **custom properties** included in your import configuration
**Companies** become **Organisations** in Trig. Default fields:
* `name`, `domain`, `industry`, `numberofemployees`, `hubspot_owner_id`
* Any custom properties included in your import configuration
`domain` is the matching key Trig uses to link organisations across data sources, so it's always pulled by default.
**Deals**, **Quotes**, and **Custom Objects** are accessible too, typically used to build signals (for example, "deal moved to closed-won"). **Leads** is a HubSpot Sales Hub feature available on Pro and Enterprise tiers; if your portal has it enabled, Trig can pull it in too.
### Written back to HubSpot
Trig does **not** automatically update HubSpot when campaigns run or lifecycle stages change in Trig. Writeback only happens when you configure a Trig **Job** that updates a HubSpot field. Actions within a Job are the things that perform the update (for example, an Action that stamps `last_outreach_at` after an email is sent). If you want Trig to keep a HubSpot field in sync with something in Trig, set it up as a Job with the appropriate Action.
Trig does not create or delete records in HubSpot. Only specified fields on existing records can be updated by configured Jobs.
## Sync schedule
| Sync type | Frequency | What it pulls |
| -------------- | ------------------------------- | ------------------------------------ |
| Full | Every 24 hours | All contacts and companies |
| Recent changes | Periodically throughout the day | Records modified since the last sync |
| Manual | On request | Triggered by your Trig contact |
The recent-changes sync uses HubSpot's standard last-modified property for each object (`lastmodifieddate` for contacts, `hs_lastmodifieddate` for companies and deals) to fetch only modified records, which keeps API usage well within HubSpot's limits.
## Customising what's imported
The set of HubSpot properties Trig imports (including custom properties, filters, and any field-level transforms) is configured for you when the integration is set up. To add a new property, narrow the import to a subset of contacts (for example, only `lifecyclestage = "customer"`), or change how a field is mapped, **contact your Trig representative**. We'll adjust the configuration on your behalf and confirm the timing with you.
## Permissions & scopes
Trig requests these HubSpot OAuth scopes.
**Read scopes (always requested):**
* `crm.objects.contacts.read`
* `crm.objects.companies.read`
* `crm.objects.deals.read`
* `crm.objects.quotes.read`
* `crm.objects.owners.read`
* `crm.objects.custom.read`
* `settings.users.read`
**Write scopes (requested at install so writeback Jobs don't need a re-authorisation later):**
* `crm.objects.contacts.write`
* `crm.objects.companies.write`
* `crm.objects.custom.write`
Write scopes are only used when a Job with a HubSpot-update Action runs. Trig does not create or delete records in HubSpot; only specified fields on existing records can be updated by configured Jobs.
If your portal has the Sales Hub Leads object enabled, `crm.objects.leads.read` is also requested.
Trig **cannot** read engagement records (emails, calls, notes), workflows, or marketing email content. If you need any of these, get in touch.
## Limits & gotchas
* **Rate limits**: HubSpot's standard limit for OAuth apps is 100 requests per 10 seconds (150 per 10 seconds on Pro and Enterprise tiers), with a daily cap (250,000 calls/day on most tiers, 500,000 on Enterprise). Trig's syncs stay well under both. For very large contact volumes (over 500k), the initial full import may take longer to complete.
* **Owner resolution** (mapping HubSpot owner IDs to user details) happens on the daily full sync.
* **Custom objects** are supported but need to be configured per-account. Reach out to your Trig representative if you want a custom object available in Trig.
* **Sandboxes**: HubSpot test accounts work the same way; you'll authorise against the sandbox portal during OAuth.
## Troubleshooting
**The integration shows "connected" but no data is appearing.**
By default the first full import runs on the next scheduled cycle (within 24 hours). If you need data sooner, ask your Trig contact to trigger an initial sync.
**A property I added in HubSpot isn't showing up in Trig.**
New custom properties aren't picked up automatically. Contact your Trig representative and we'll add the property to your import.
**Trig isn't writing updates back to HubSpot.**
Writeback only happens via Trig Jobs. Check whether a Job with a HubSpot-update Action has been configured for that field, or get in touch and we'll help set one up.
**My OAuth token keeps expiring.**
Trig refreshes tokens automatically. If you're seeing repeated auth errors, the most common cause is the original authorising user being deactivated. Reconnect the integration via your designated integration user. If you didn't set one up at install, this is a good moment to create one so the connection isn't tied to a real person's account.
# CRM integrations
Source: https://docs.trig.ai/integrations/crm/overview
Connect Trig to your CRM to bring contacts, companies, and deals in as people, organisations, and signals
Connecting Trig to your CRM brings your contacts, companies, and deals into Trig as people, organisations, and signals. Once connected, anything you've stored in your CRM (owner, lifecycle stage, custom fields, deal state) is available to use in Trig cohorts, signals, and campaign personalisation.
Trig supports **Salesforce** and **HubSpot** as native CRM integrations, both connected via OAuth. There are no API keys to manage, and you don't need to build a Connected App or private app yourself; Trig provides one. We do recommend authorising the integration via a dedicated integration user rather than a real person's account, so the connection doesn't break when someone leaves. See the per-CRM docs for the specifics.
CRM integrations are **read-first**. Trig keeps your CRM as the source of truth. If you want Trig to update fields back in your CRM (for example, stamping a "last contacted" date), you'll configure that as a Trig **Job**, with Actions inside the Job performing the update. Writeback is opt-in by design.
If your CRM data lives in a data warehouse rather than Salesforce or HubSpot, see the **Data Lake** integrations instead.
# Salesforce
Source: https://docs.trig.ai/integrations/crm/salesforce
Connect Trig to Salesforce to sync contacts, accounts, opportunities, and custom fields
## What it does
Trig connects to Salesforce to pull in your contacts and accounts as people and organisations in Trig and keep them in sync as records change in Salesforce. Once connected, anything you've stored on a Salesforce record (owner, custom fields, related opportunities) is available for cohorts, signals, and campaign personalisation. Trig can also write field updates back to Salesforce, but only when an explicit Trig Job is configured to do so. Actions within a Job are the things that perform the update.
## Before you start
You'll need:
* **A Salesforce user who can authorise the Trig Connected App**, with read access to Contact, Account, Opportunity, and Lead objects (plus any custom objects you want imported). We strongly recommend using a dedicated integration user rather than a real person's account, so the connection doesn't break when someone leaves or changes role (see Permissions & scopes).
* **The right Salesforce environment.** Production logs in via `login.salesforce.com` (or your My Domain URL, for example `mycompany.my.salesforce.com`). Sandboxes log in via `test.salesforce.com` (or `mycompany--sandbox.sandbox.my.salesforce.com`). Each requires its own connection.
* A list of any **custom fields or objects** you want Trig to import. You can adjust this later.
You don't need to build a Connected App yourself. Trig provides one and authorisation is via Salesforce's OAuth flow.
## Connect Salesforce
1. In Trig, go to **Settings → Integrations → CRM**.
2. Click **Add a CRM integration** and choose **Salesforce**.
3. Click **Connect**. You'll be redirected to Salesforce to authorise Trig.
4. Sign in to the Salesforce org you want to connect, review the requested scopes (`api` and `refresh_token`), and click **Allow**.
5. You'll be redirected back to Trig. Your integration is now connected.
By default, the first **full import** runs on the next scheduled cycle (within 24 hours). If you'd like to bring data in immediately, ask your Trig contact to trigger an initial sync.
## What data flows
### Imported from Salesforce
**Contacts** become **People** in Trig. By default Trig imports:
* `Id`, `FirstName`, `LastName`, `Email`, `Phone`, `MailingCountry`, `Title`
* `HasOptedOutOfEmail` (used to respect opt-outs in Trig sends)
* `OwnerId` (mapped to Trig owners)
* `AccountId` (links the person to their org in Trig)
* Any **custom fields** included in your import configuration
**Accounts** become **Organisations** in Trig. Default fields:
* `Id`, `Name`, `Website`, `Industry`, `OwnerId`
* Any custom fields included in your import configuration
`Website` is the matching key Trig uses to link organisations across data sources, so it's always pulled by default.
**Opportunities** and **Leads** are also imported and typically used to build signals (for example, "opportunity moved to Closed Won", or "new inbound lead in target segment"). Related objects on a Contact (such as Cases) can be configured to flow through too.
### Written back to Salesforce
Trig does **not** automatically update Salesforce when campaigns run or other state changes in Trig. Writeback only happens when you configure a Trig **Job** with an Action that updates a Salesforce field. For example, an Action that stamps a custom date field after an email is sent. If you want Trig to keep a Salesforce field in sync with something in Trig, set it up as a Job.
Trig does not create or delete records in Salesforce. Only specified fields on existing records can be updated by configured Jobs.
## Sync schedule
| Sync type | Frequency | What it pulls |
| -------------- | ------------------------------- | ------------------------------------ |
| Full | Every 24 hours | All contacts and accounts |
| Recent changes | Periodically throughout the day | Records modified since the last sync |
| Manual | On request | Triggered by your Trig contact |
The recent-changes sync uses Salesforce's `LastModifiedDate` to fetch only modified records, keeping API usage well within Salesforce's limits.
## Customising what's imported
The set of Salesforce fields Trig imports (including custom fields, related objects, filters, and any field-level transforms) is configured for you when the integration is set up. To add a new field, expand to a custom object, or change a mapping, **contact your Trig representative**. We'll adjust the configuration on your behalf and confirm the timing with you.
## Permissions & scopes
Trig requests these Salesforce OAuth scopes:
* `api`: read and write access to standard and custom objects, scoped by the connecting user's profile and permission set.
* `refresh_token` (sometimes shown in Salesforce as `offline_access`, which is an alias of the same scope): keeps the connection alive without re-authorising.
The connecting user's **profile and permission set** determines exactly which objects and fields Trig can see. We recommend creating a dedicated integration user with read access to Contact, Account, Opportunity, Lead, and any custom objects you want imported. This avoids the integration breaking when a real person changes role or leaves. Salesforce now offers free Integration User licences for most editions; check with your Salesforce admin on availability.
Write scopes are granted at install via the `api` scope so writeback Jobs don't need a re-authorisation later. They're only used when a Job with a Salesforce-update Action runs. Trig does not create or delete records in Salesforce; only specified fields on existing records can be updated by configured Jobs.
## Limits & gotchas
* **Sandbox vs production** are separate connections. If you move from sandbox to production, you'll connect a new integration rather than swapping the underlying org. **My Domain** is now mandatory in Salesforce, so the connecting user will most likely sign in via your My Domain URL rather than the generic login URL.
* **Field-level security** in Salesforce is respected. If the connecting user can't see a field, neither can Trig, even if it's listed in your import config.
* **Custom objects** are supported via SOQL configuration. Reach out if you want a custom object available in Trig.
* **Large filter expressions** (very long lists of IDs in `WHERE` clauses) are split automatically. No action needed on your side, though it can make initial imports take longer.
* **API limits**: Trig's syncs are designed to stay well within Salesforce's daily API request limits, but if you have other heavy integrations consuming the same quota, monitor it during the initial full import.
## Troubleshooting
**The integration shows "connected" but no data is appearing.**
The first full import runs on the next scheduled cycle (within 24 hours). If you need data sooner, ask your Trig contact to trigger an initial sync.
**A field I added in Salesforce isn't showing up in Trig.**
New custom fields aren't picked up automatically. Contact your Trig representative and we'll add the field to your import.
**Trig isn't writing updates back to Salesforce.**
Writeback only happens via Trig Jobs. Check whether a Job with a Salesforce-update Action has been configured for that field, or get in touch and we'll help set one up.
**I'm seeing "INVALID\_SESSION\_ID" or repeated auth errors.**
Trig refreshes tokens automatically. The most common cause is the original authorising user being deactivated, or their permissions changing. If you used a real person's account, switch to a dedicated integration user when you reconnect. If you already use an integration user, reconnect with one that has the appropriate permissions.
# BigQuery
Source: https://docs.trig.ai/integrations/data-lake/bigquery
Connect Trig to BigQuery for event ingestion and attribute sync from your warehouse
## What it does
Trig connects to your BigQuery project to pull data into Trig. Both **event data** (user actions, transactions, feature usage) and **person/organisation attributes** (customer data you maintain in your warehouse) are supported. One BigQuery connection can power either or both. Choose BigQuery if it's your warehouse for product analytics (for example, Firebase Analytics or GA4 exports) or customer data, and you want Trig to operate on it directly.
## Before you start
You'll need:
* **A Google Cloud project** containing the dataset(s) Trig should read from.
* **A service account** in that GCP project with read access to the relevant BigQuery datasets (see Permissions & scopes below).
* **The service account's JSON key file** to upload to Trig.
If your GCP organisation policy enforces `iam.disableServiceAccountKeyCreation` and blocks downloadable keys, contact your Trig representative before starting setup. We'll work with you on an alternative connection path.
## Connect BigQuery
1. In Trig, go to **Settings → Integrations** and choose **BigQuery**.
2. Upload the **service account JSON key**. Trig extracts the project ID automatically.
3. Click **Test connection**. Trig will validate access by listing accessible datasets.
4. Once the connection is verified, your Trig representative will work with you to configure which tables to import (see below).
## What data flows
A single BigQuery connection can power two pipelines.
### Events ingestion
Trig pulls events from a table or view you specify. The table must have:
* An **event name** column
* An **event timestamp** column
* An **event ID** column (used for deduplication)
* A **user identifier** column. We recommend an external user ID over email, since email is PII and many event pipelines deliberately pseudonymise it. Email is also accepted.
Optional: extra property columns, a timezone hint, and a `WHERE` clause to restrict the rows imported.
### Attribute sync
Trig pulls person and organisation attributes from a table or view you specify. The table must have:
* An **ID** column
* A **name** column
Optional: include or exclude lists for other columns.
Both pipelines pull data from BigQuery into Trig. Trig does not write data back to BigQuery, and does not create or delete records.
## Sync schedule
| Pipeline | Frequency | What it pulls |
| ---------- | ---------------- | -------------------------------------------- |
| Events | Every 15 minutes | New events since the last sync |
| Attributes | Every 24 hours | Recently changed records |
| Manual | On request | Full refresh, triggered by your Trig contact |
The events sync is incremental. Trig tracks the latest event timestamp seen and fetches only newer rows on subsequent runs. Events that arrive in the warehouse with a timestamp earlier than the current watermark may be missed; if late-arriving events are common in your pipeline, ask your Trig representative about using an ingestion-time column rather than the event timestamp as the watermark.
## Customising what's imported
Table choice, column mapping, filters, and transforms are configured for you when the integration is set up. To change tables, add columns, or adjust filters, contact your Trig representative.
For long-lived integrations we recommend pointing Trig at a **stable view layer** rather than the underlying source tables. Your data team owns the contract behind the view, which keeps schema changes in your warehouse from breaking Trig's import.
## Permissions & scopes
The simplest setup is to grant the service account two predefined roles:
* **BigQuery Data Viewer** on the relevant datasets
* **BigQuery Job User** at the project level
If your GCP admin prefers granular permissions, the underlying ones Trig needs are `bigquery.datasets.get`, `bigquery.tables.get`, `bigquery.tables.getData`, and `bigquery.jobs.create` (the last one at project level).
The service account does **not** need write or admin permissions.
## Limits & gotchas
* **BigQuery has two pricing models.** On the **on-demand** model you're billed per query based on bytes scanned, and partitioning the source tables on the event timestamp column dramatically reduces sync costs. On **BigQuery Editions** (capacity pricing) you pay for slot capacity, so partitioning still helps performance but doesn't reduce dollar cost the same way.
* **Initial backfills** of very large tables can be expensive in scan costs on the on-demand model. Coordinate with your Trig representative if you want to bound the historical window.
* **Schema changes** (renaming or dropping columns Trig reads) will break the import. Pointing Trig at a stable view layer (see above) avoids this.
* **Dataset locations**: BigQuery datasets are pinned to a single location (for example, `US`, `EU`, `asia-northeast1`). Queries must run in the same location as the dataset. If your datasets span multiple locations, each one is configured separately in Trig.
## Troubleshooting
**The connection test fails.**
Check that the service account JSON is valid, and that the service account has both `bigquery.jobs.create` (project-level) and dataset-level read access. These are two separate grants.
**Events stopped arriving.**
Verify the source table still exists, hasn't been renamed, and that the schema hasn't changed. If the table is partitioned, confirm the partitioning column hasn't been altered.
**Scan costs are higher than expected.**
Make sure the source table is partitioned on the event timestamp column. Without partitioning, every sync rescans the full table on the on-demand pricing model. You can see Trig's query patterns by filtering `INFORMATION_SCHEMA.JOBS` on the service account.
# Databricks
Source: https://docs.trig.ai/integrations/data-lake/databricks
Connect Trig to Databricks SQL warehouses for event ingestion and attribute sync
## What it does
Trig connects to your Databricks workspace to pull data into Trig. Both **event data** and **person/organisation attributes** are supported, using the SQL warehouses (formerly SQL endpoints) feature. One Databricks connection can power either or both pipelines. Choose Databricks if it's where your product and customer data lives in Unity Catalog and you want Trig to operate on it directly.
## Before you start
You'll need:
* **A Databricks workspace** with a SQL warehouse running.
* **A workspace URL.** The format depends on your cloud:
* AWS: `dbc-xxxxxxxx-xxxx.cloud.databricks.com`
* Azure: `adb-xxxxxxxxxxxxxxxx.xx.azuredatabricks.net`
* GCP: `.gcp.databricks.com`
* **A SQL warehouse HTTP path** (found in the warehouse's connection details).
* **A service principal token** with read access to the relevant catalogs and schemas (recommended). A personal access token is also supported but ties the integration to a real user account, so we discourage it for long-lived integrations (see Permissions & scopes below).
## Connect Databricks
1. In Trig, go to **Settings → Integrations** and choose **Databricks**.
2. Enter:
* **Workspace URL**
* **HTTP path** (from your SQL warehouse)
* **Access token**
* Optional: **default catalog**
3. Click **Test connection**. Trig will validate access by listing available catalogs.
4. Once the connection is verified, your Trig representative will work with you to configure which tables to import (see below).
## What data flows
A single Databricks connection can power two pipelines.
### Events ingestion
Trig pulls events from a table or view you specify. The table must have:
* An **event name** column
* An **event timestamp** column
* An **event ID** column (used for deduplication)
* A **user identifier** column. We recommend an external user ID over email, since email is PII and many event pipelines deliberately pseudonymise it. Email is also accepted.
Optional: extra property columns, a timezone hint, and a `WHERE` clause.
### Attribute sync
Trig pulls person and organisation attributes from a table or view you specify, with an **ID** column and a **name** column required, plus optional include/exclude lists.
Both pipelines pull data from Databricks into Trig. Trig does not write data back to Databricks, and does not create or delete records.
## Sync schedule
| Pipeline | Frequency | What it pulls |
| ---------- | ---------------- | -------------------------------------------- |
| Events | Every 15 minutes | New events since the last sync |
| Attributes | Every 24 hours | Recently changed records |
| Manual | On request | Full refresh, triggered by your Trig contact |
Syncs are incremental and use the event timestamp column to fetch only new rows. Events that arrive in the warehouse with a timestamp earlier than the current watermark may be missed; if late-arriving events are common in your pipeline, ask your Trig representative about using an ingestion-time column rather than the event timestamp as the watermark.
## Customising what's imported
Table choice, column mapping, filters, and transforms are configured for you when the integration is set up. Contact your Trig representative to change configuration.
For long-lived integrations we recommend pointing Trig at a **stable view layer** rather than the underlying source tables. Your data team owns the contract behind the view, which keeps schema changes from breaking Trig's import.
## Permissions & scopes
The Databricks principal Trig uses needs:
* `USE CATALOG` on the catalog containing the relevant tables
* `USE SCHEMA` on the schema(s) containing the relevant tables
* `SELECT` on the specific tables or views Trig reads
* `CAN USE` on the SQL warehouse
It does **not** need write, manage, or admin permissions on the workspace.
We recommend a **service principal** with a dedicated token rather than a personal access token tied to a user account. PATs expire based on workspace policy, and they break when the user changes role or leaves; a service principal keeps the integration independent of any individual.
## Limits & gotchas
* **The SQL warehouse must be running** for syncs to succeed. By default, SQL warehouses auto-start when they receive a query, so scheduled syncs will wake the warehouse if it's been auto-stopped. If your warehouse is configured to start manually only, scheduled syncs will fail when the warehouse is stopped.
* **Compute is billed by warehouse uptime.** A small warehouse with a short auto-stop is usually the right choice for Trig's workload.
* **Personal access tokens expire** based on workspace policy. If your tokens have a short lifetime, use a service principal instead.
* **Schema changes** (renaming or dropping columns Trig reads) will break the import. Pointing Trig at a stable view layer (see above) avoids this.
## Troubleshooting
**The connection test fails.**
Check the HTTP path matches the SQL warehouse you intend to use, and that the access token has not expired. The token must also belong to a principal with `CAN USE` permission on that warehouse.
**Events stopped arriving.**
Check the SQL warehouse is running (or set to auto-start on query). Also check whether the source table's schema has changed.
**"Permission denied" errors after working previously.**
Token rotation or principal permission changes are the usual cause. For service principals, confirm the token is still valid in the workspace's identity settings. If you used a personal access token tied to a real user, switch to a service principal when you reconnect.
# Data Lake integrations
Source: https://docs.trig.ai/integrations/data-lake/overview
Connect Trig directly to your data warehouse for events ingestion and attribute sync
If your data warehouse is your source of truth for product analytics, customer data, or both, Trig can connect directly to it rather than duplicating your pipeline. A single warehouse connection can power two pipelines simultaneously: **events ingestion** (user actions, transactions, feature usage) and **attribute sync** (person and organisation fields).
Trig supports:
* **Snowflake**: key pair (JWT) is the recommended authentication method. Programmatic Access Tokens (PAT) are also supported.
* **BigQuery**: service account authentication via a JSON key. If your GCP organisation policy blocks the creation of downloadable service account keys, contact your Trig representative.
* **Databricks**: workspace URL plus SQL warehouse, authenticated via a service principal token (recommended). Personal access tokens are also supported but tend to be tied to a real user, so we discourage them for long-lived integrations.
All three are **pull-only**. Trig queries your warehouse on a schedule, with incremental syncs based on event timestamps. Trig does not write data back to the warehouse.
You'll set up the connection yourself in Trig settings. The table mapping (which tables, which columns, what filters) is configured for you by your Trig representative when the integration is enabled.
# Snowflake
Source: https://docs.trig.ai/integrations/data-lake/snowflake
Connect Trig to Snowflake for event ingestion and attribute sync from your warehouse
## What it does
Trig connects to your Snowflake account to pull data into Trig. Both **event data** (user actions, transactions, feature usage) and **person/organisation attributes** (custom fields you maintain in your warehouse) are supported. One Snowflake connection can power either or both. Choose Snowflake if your warehouse is your source of truth for product analytics or customer data, and you want Trig to operate on the same data without duplicating it elsewhere.
## Before you start
You'll need:
* **A Snowflake account** with a warehouse. Account identifiers come in two formats: the modern org-account format (e.g. `myorg-myaccount`) and the legacy account locator format (e.g. `xy12345.us-east-1`). Either works; if you're not sure which to use, ask your Snowflake admin.
* **A service user** that Trig will use to query your data. We recommend a dedicated user with minimal permissions (see Permissions & scopes below).
* **Authentication credentials** in one of the supported forms. In order of preference:
* **Key pair (JWT)** is recommended. Trig generates the public key; you create a Snowflake service user with that key.
* **Programmatic Access Token (PAT)** issued by Snowflake, suitable if your org standardises on PATs.
* **Username and password** is supported but strongly discouraged. Snowflake is in the process of phasing out single-factor password authentication and most compliance regimes will flag it in review.
## Connect Snowflake
1. In Trig, go to **Settings → Integrations** and choose **Snowflake**.
2. Enter your **account identifier** and **warehouse name**.
3. Choose an **authentication method**:
* **Key pair**: Trig will display a public key. Run the SQL Trig provides in your Snowflake account to create the service user with that key. Snowflake supports two simultaneous public keys per user (`RSA_PUBLIC_KEY` and `RSA_PUBLIC_KEY_2`), so you can rotate keys without downtime.
* **PAT**: paste in the token issued by Snowflake.
4. Click **Test connection**. Trig will validate access by running a `SELECT 1` against the configured warehouse.
5. Once the connection is verified, your Trig representative will work with you to configure which tables to import (see below).
## What data flows
A single Snowflake connection can power two pipelines.
### Events ingestion
Trig pulls events from a table or view you specify. The table must have:
* An **event name** column
* An **event timestamp** column
* An **event ID** column (used for deduplication)
* A **user identifier** column. We recommend an external user ID over email, since email is PII and many event pipelines deliberately pseudonymise it. Email is also accepted.
Optional: extra property columns, a timezone hint, and a `WHERE` clause to restrict the rows imported.
### Attribute sync
Trig pulls person and organisation attributes from a table or view you specify. The table must have:
* An **ID** column (e.g. account ID, contact ID)
* A **name** column
Optional: include or exclude lists for which other columns to import.
Both pipelines pull data from Snowflake into Trig. Trig does not write data back to Snowflake, and does not create or delete records.
## Sync schedule
| Pipeline | Frequency | What it pulls |
| ---------- | ---------------- | -------------------------------------------- |
| Events | Every 15 minutes | New events since the last sync |
| Attributes | Every 24 hours | Recently changed records |
| Manual | On request | Full refresh, triggered by your Trig contact |
The events sync is incremental. Trig tracks the latest event timestamp seen and fetches newer rows on subsequent runs. Events that arrive in the warehouse with a timestamp earlier than the current watermark (for example, late-arriving mobile events) may be missed. If this is a risk for your data, ask your Trig representative about using an ingestion-time column rather than the event timestamp as the watermark.
## Customising what's imported
Table choice, column mapping, filters, and any transforms are configured for you by your Trig representative when the integration is set up. To change which table Trig reads from, add columns, or adjust filters, get in touch.
For long-lived integrations we recommend pointing Trig at a **stable view layer** rather than the underlying source tables. Your data team owns the contract behind the view, which keeps schema changes in your warehouse from breaking Trig's import.
## Permissions & scopes
The Snowflake service user needs:
* `USAGE` on the warehouse Trig connects to
* `USAGE` on the database and schema containing the relevant tables
* `SELECT` on the specific tables or views Trig reads
For views that read from tables in other schemas, the service user also needs `USAGE` on those underlying schemas.
It does **not** need write permissions, account-level admin, or access to other databases.
We recommend creating a dedicated role (e.g. `TRIG_ROLE`) with these grants and assigning it to a dedicated service user.
## Limits & gotchas
* **Trig pulls in batches** to keep query costs predictable. Initial backfills of very large event tables can take time; manual full refreshes have the same characteristic.
* **Snowflake bills by warehouse-second**, with a 60-second minimum each time the warehouse resumes from suspended state. A small dedicated warehouse with a short auto-suspend is the right setup for Trig's workload.
* **Schema changes** (renaming or dropping columns Trig reads) will break the import. Pointing Trig at a stable view layer (see above) avoids this.
* **Non-prod environments** (a separate Snowflake account or a dedicated non-prod database) are connected as separate Trig integrations. Trig doesn't move between Snowflake accounts on the same integration.
## Troubleshooting
**The connection test fails.**
The most common causes are an incorrect account identifier (try the alternate format, since both org-account and the legacy account locator are valid) and missing `USAGE` grants on the warehouse. Re-run the SQL Trig provided to verify the service user has the right grants.
**Events stopped arriving.**
Check whether the source table or view has changed schema, or whether the warehouse has been suspended without auto-resume configured. Both will cause silent failures in the sync.
**Costs are higher than expected.**
Move Trig's queries onto a small dedicated warehouse with auto-suspend enabled. You can see Trig's query patterns by filtering `QUERY_HISTORY` on the service user or role. Contact your Trig representative if you'd like us to reduce sync frequency.
# Amplitude
Source: https://docs.trig.ai/integrations/events/amplitude
Stream Amplitude events into Trig in real time via webhook
## What it does
Trig connects to Amplitude to receive a real-time stream of events as they happen in your product. Each event is matched to a Person in Trig (by email on the event's user properties) and becomes available for cohorts, signals, and campaign triggers. Choose Amplitude if it's your primary analytics tool and you want event-driven Trig automations to fire as soon as user behaviour occurs.
If your Amplitude setup identifies users by an internal `user_id` and deliberately keeps email off events for PII reasons, contact your Trig representative before setting up the integration. Email-based matching is the default; we can discuss alternatives.
## Before you start
You'll need:
* **Admin access** to the Amplitude project you want to connect.
* The ability to **configure a webhook destination** in Amplitude (a project-level setting).
## Connect Amplitude
1. In Trig, go to **Settings → Integrations → Events**.
2. Click **Add an events integration** and choose **Amplitude**.
3. Trig will display the **webhook URL** to use in Amplitude.
4. In Amplitude, go to **Data → Destinations → Add Destination → Webhook** and configure:
* **URL**: the webhook URL Trig provided.
* **Events to forward**: pick a focused set rather than all events. Forwarding everything from a high-volume Amplitude project produces noise in Trig and may incur Amplitude egress costs. Choose the events that drive cohorts, signals, or campaigns.
5. Save the destination in Amplitude. Within a few seconds, Trig should start receiving events.
If you want help with the Amplitude-side configuration, contact your Trig representative.
## What data flows
Amplitude forwards each event to Trig with the full payload, including:
* `event_type` (event name)
* `event_time`
* `$insert_id` (used for deduplication)
* `user_properties` (including `email`, used to match the event to a Person in Trig)
* All other event and user properties
Trig matches incoming events to People using **email** on the event's user properties. If no match exists and email is present, Trig creates a new Person. Events without an email on user properties are dropped.
Trig does not send data back to Amplitude.
## Sync schedule
Events are received in **real time** as Amplitude forwards them, typically within a few seconds of the original event firing.
## Customising what's imported
Filter at the source: configure the Amplitude destination to forward only the event types you care about. To map specific Amplitude properties to Trig attributes, or to apply transforms, contact your Trig representative.
## Permissions & scopes
Trig only receives webhook payloads from Amplitude. There are no API credentials and no read access to your Amplitude project; Amplitude pushes data, Trig doesn't pull.
Webhook payloads are received via a Trig-generated URL. Treat the URL as a secret. If your security policy requires additional webhook authentication (such as HMAC signing or IP allowlisting), contact your Trig representative.
## Limits & gotchas
* **Email is required** in `user_properties` for an event to be attached to a Person in Trig. Events without an email will be dropped. If your Amplitude setup deliberately keeps email off events, talk to your Trig representative about alternatives.
* **Deduplication** is based on Amplitude's `$insert_id` per event. If you replay events with new IDs, they'll be treated as new events.
* **Webhook delivery** depends on Amplitude's delivery guarantees. Occasional retries may produce slight duplicates if `$insert_id` differs across attempts.
## Troubleshooting
**Events aren't arriving in Trig.**
Check the Amplitude destination's delivery logs. Common causes: the webhook URL was copied incorrectly, or the destination was paused.
**Some events arrive but others don't.**
Verify the destination's event filters in Amplitude. Anything excluded there won't reach Trig. Also check whether the events have an email in `user_properties`. Events without an email are dropped.
**A user appears multiple times in Trig.**
Usually this means the same person has events with different emails (for example, work email versus personal). Trig matches strictly on email; if you want stronger identity stitching, contact your Trig representative.
# Mixpanel
Source: https://docs.trig.ai/integrations/events/mixpanel
Sync events and user profiles from Mixpanel into Trig via service account
## What it does
Trig connects to Mixpanel to pull your event history and user profiles into Trig on a periodic basis. Events become available for cohorts, signals, and campaign triggers; user profile attributes become person attributes in Trig. Choose Mixpanel if it's already your primary product analytics tool and you want Trig to use the same source of truth.
The Mixpanel sync runs on a slower cadence than the Segment or Amplitude integrations because Mixpanel's Export API is designed for periodic bulk exports rather than real-time streaming. If you need near-real-time event flow, consider Segment as a tee from Mixpanel, or use the Data Lake integration if your Mixpanel data is already replicated to a warehouse.
## Before you start
You'll need:
* **A Mixpanel project** for the events you want to sync.
* **Service account credentials**: a username and secret with read access to the project's events and engagement data. Created under **Project Settings → Service Accounts** (or **Organization Settings → Service Accounts** for org-scoped accounts) in Mixpanel. Assign the service account a role of **Member** or higher so it can query the Export and Engage APIs.
* **Your Mixpanel project ID** and **data residency region** (US, EU, or India). The region determines which Mixpanel API endpoint Trig uses.
## Connect Mixpanel
1. In Trig, go to **Settings → Integrations → Events**.
2. Click **Add an events integration** and choose **Mixpanel**.
3. Enter:
* **Region**: US, EU, or India
* **Project ID**
* **Service account username**
* **Service account secret**
4. Click **Save**.
Trig will validate the credentials immediately. Once saved, scheduled syncs will pull events and user profiles automatically.
## What data flows
Trig pulls two streams from Mixpanel:
* **Events** via Mixpanel's Export API. Each event's name, timestamp, and properties are imported.
* **User profiles** via Mixpanel's Engage API. Profile properties become person attributes in Trig.
Trig matches Mixpanel users to People in Trig by **email**. The user profile sync runs first so that email is available before events are attached.
Trig does not send data back to Mixpanel.
## Sync schedule
| Sync type | Frequency | What it pulls |
| ------------- | ------------- | --------------------------------------------------------------------- |
| Events | Every 4 hours | New events since the last sync |
| User profiles | Every 4 hours | Modified profiles |
| Manual | On request | One-off backfill from a specific date, triggered by your Trig contact |
## Customising what's imported
Trig imports all events and profile properties from the configured project by default. If you want to filter to specific event names, restrict to a subset of users, or apply transforms to property values, contact your Trig representative.
## Permissions & scopes
The service account Trig uses needs:
* Access to the **Export API** (for events)
* Access to the **Engage API** (for user profiles)
In Mixpanel terms, this is typically achieved by assigning the service account a project role of **Member** or higher. It does not need write access. We recommend creating a dedicated service account for Trig rather than reusing one.
## Limits & gotchas
* **Email is required** for an event to be attached to a Person in Trig. Events from anonymous users (no email on profile) won't be linked.
* **Mixpanel's Export API** has daily query quotas per project and is designed for bulk historical export rather than continuous polling. Trig stays within the quota by syncing in batches; very high-volume projects may see longer end-to-end latency than the table above implies.
* **Property name collisions** can occur if the same property name has different shapes across events. Mixpanel preserves the raw values; Trig stores them as-is.
* **Region changes**: US, EU, and India use different API hosts. If your project moves regions, the integration must be reconfigured.
## Troubleshooting
**Events aren't appearing in Trig.**
Check that the user profile sync has run successfully. If a Mixpanel user has no email on their profile, their events won't be matched to a Person in Trig.
**Some events are missing.**
Mixpanel's Export API returns events in time-ordered batches. If you suspect gaps, contact your Trig representative; we can re-run a window of imports.
**"Authentication failed" errors.**
Service account credentials can be revoked or rotated in Mixpanel. Generate a new service account secret and update it in the Trig integration settings.
# Event integrations
Source: https://docs.trig.ai/integrations/events/overview
Connect Trig to your event tracking source for real-time behavioural data
Trig responds to your users' behaviour in real time (feature usage, conversions, signups, churn signals) by ingesting events from wherever you already track them. Once events are flowing, they power cohorts ("users who did X in the last 7 days"), signals ("trial about to expire"), and campaign triggers.
Trig supports three native event sources:
* **Segment**: recommended if Segment is your tracking layer. Real-time, webhook-driven, with auto-configured destination.
* **Amplitude**: real-time, webhook-driven. Configure the destination on Amplitude's side using the URL Trig provides.
* **Mixpanel**: pulled periodically via service account credentials. The Mixpanel sync runs on a slower cadence than Segment or Amplitude due to the constraints of Mixpanel's Export API.
If your events live in a data warehouse (Snowflake, BigQuery, Databricks), see the **Data Lake** integrations. A single warehouse connection can ingest events as well as customer attributes.
All event sources need an **email** to create a new Person in Trig. Some sources (notably Segment) can match an event to an existing Person by user ID without seeing email on every event. See the per-source docs for details. Events that can't be matched to a Person are dropped.
# Segment
Source: https://docs.trig.ai/integrations/events/segment
Stream Segment events into Trig in real time with auto-configured destination
## What it does
Trig connects to Segment to receive a real-time stream of events from your product (page views, feature usage, conversions) along with `identify` and `group` calls. Each event is matched to a Person in Trig (by Segment `userId`, or by email when no `userId` match exists) and becomes available for cohorts, signals, and campaign triggers. Segment is the recommended event source if you already use it as your tracking layer.
## Before you start
You'll need:
* **Permission to create a destination and subscriptions** in your Segment workspace. This is typically a Workspace Owner, but a Workspace Admin or a custom role with destination-management rights is also enough.
* **A Segment access token** with permissions to create destinations and subscriptions in your workspace. Generated under **Workspace Settings → Access Management → Tokens** in Segment.
* **A shared secret**: any random string you generate. Trig uses this to verify webhook signatures from Segment.
## Connect Segment
1. In Trig, go to **Settings → Integrations → Events**.
2. Click **Add an events integration** and choose **Segment**.
3. Enter:
* **Destination name**: what the destination will be called in your Segment workspace.
* **Shared secret**: the random string you generated above.
* **Segment access token**: from your Segment workspace.
4. Click **Save**.
When you save, Trig will automatically create a destination in your Segment workspace and wire up subscriptions for `identify`, `group`, and `track` calls. Within a few minutes events should start flowing into Trig.
If your workspace also uses `page` or `screen` calls and you want those forwarded to Trig, contact your Trig representative. We'll add the appropriate subscriptions on your behalf.
If you'd rather configure the destination manually in Segment, contact your Trig representative. We can provide the webhook URL and shared secret for you to paste in.
## What data flows
Segment forwards three call types to Trig by default:
| Call type | What Trig does with it |
| ---------- | --------------------------------------------------------------------------------------------------------------- |
| `identify` | Creates or updates a Person in Trig. Email is required to create a new Person. Traits become person attributes. |
| `group` | Creates or updates an Organisation in Trig and associates the user with it. |
| `track` | Records the event against the matching Person, with all properties retained. |
Trig matches incoming calls to existing People using your Segment `userId`. If no `userId` match exists, Trig creates a new Person from the `identify` traits, which must include `email`.
`page` and `screen` calls aren't subscribed by default. If you use them, see the note in **Connect Segment** above.
Trig does not send data back to Segment.
## Sync schedule
Events are received in **real time** as Segment forwards them. There's no polling or batch; once the destination is wired up, latency is typically a few seconds.
## Customising what's imported
By default Trig accepts the `identify`, `group`, and `track` calls forwarded to it. If you want to filter events at the source (for example, to exclude staging traffic or specific event names), configure that in the Segment destination's filters in your workspace.
To map a Segment trait to a specific Trig attribute, or to apply transforms, contact your Trig representative.
## Permissions & scopes
The Segment access token Trig uses is scoped to your workspace and grants permission to:
* Create and manage the **destination** that forwards events to Trig
* Create and manage the **subscriptions** that route `identify`, `group`, and `track` calls to that destination
It does not grant access to any other Segment configuration.
## Limits & gotchas
* **`identify` calls without an email** can't be used to create a new Person in Trig. The event is still attached to a Person matched by `userId` where one exists.
* **`userId` consistency matters.** If the same user appears under different `userId` values in Segment, they'll show up as multiple People in Trig. Stitching anonymous-to-known users in Segment before forwarding is recommended.
* **Webhook signature verification** uses HMAC-SHA1 with your shared secret. If you rotate the secret in Segment, update it in Trig at the same time. There's a brief window during rotation where mismatched events can drop, so coordinate the change.
* **Replays** from Segment are supported but may create duplicate events if the original `messageId` differs.
## Troubleshooting
**Events aren't arriving in Trig.**
Check the Segment destination's delivery logs in your workspace. They'll show whether events are being attempted and any failure reasons. The most common cause is a mismatched shared secret.
**Some events arrive but others don't.**
Look at the Segment destination's filters. If you've restricted event types or names in Segment, those will be silently dropped before reaching Trig. Also check whether you're sending `page` or `screen` calls; those aren't forwarded by default (see Connect Segment above).
**A user appears multiple times in Trig.**
Usually this means the same person has been tracked under multiple `userId` values. Resolve in Segment by aliasing or merging IDs at source.
# Quickstart
Source: https://docs.trig.ai/quickstart
Get launched in Trig in four steps
This guide walks you through the essential setup to get Trig working for your business. By the end, you'll have stages tracking your customer journey, objectives measuring progress, and your first job ready to intervene.
## Before you start
Ensure you have:
CRM (HubSpot or Salesforce) and product data sources connected
People and Organisations flowing into Trig
Work with your Trig implementation team to set up integrations if not already configured.
***
## Step 1: Define your stages
Stages are the foundation of everything in Trig. They represent the phases of your customer journey.
### Standard stages
Most B2B SaaS companies use four stages:
| Stage | Purpose | Typical Duration |
| -------------- | -------------------------------------------- | ------------------------- |
| **Onboarding** | Initial setup and first value milestones | Days 0-30 |
| **Adoption** | Growing usage, team expansion, feature depth | Months 1-3 |
| **Expansion** | Signals of readiness to upgrade or expand | Variable |
| **Renewal** | Pre-renewal health monitoring | 60-90 days before renewal |
### Create your first stage
Go to **Dashboard > Stages** in the main navigation
Click **Create Stage** and enter:
* **Name:** Onboarding
* **Description:** Initial setup and first value milestones
Define when organisations enter this stage:
```
first_seen_date is within last 30 days
```
Choose time-based exit for now:
```
Auto-exit after 30 days
```
Start with time-based exit criteria. You can refine to completion-based exit once you understand typical customer patterns.
***
## Step 2: Add objectives to your stage
Objectives are the milestones that define healthy progression within a stage. They answer: "What do we want customers to do?"
### Identify 4 to 7 key milestones
For an Onboarding stage, consider:
* Created first project
* Invited a team member
* Connected an integration
* Generated first report
* Completed a full week of usage
### Create your first objective
Click into the stage you just created
Click **Add Objective** and configure:
* **Name:** Created First Project
* **Completion criteria:** `projects_created >= 1`
Repeat for 3-5 additional milestones important to your business
### What happens next
As customers flow through your stage, Trig will:
1. **Track completion** for each objective
2. **Calculate averages** across your customer base
3. **Identify slow completers** via Signals
4. **Build patterns** showing what successful customers do
***
## Step 3: Create a cohort for targeting
Cohorts are reusable audience segments. Create one to target customers who need intervention.
### Create a "Stuck in Onboarding" cohort
Go to **Audience > Cohorts**
Click **Create Cohort** and configure:
* **Name:** Stuck in Onboarding
* **Type:** Organisation
```
currently_member_of_onboarding_stage = true
AND days_in_stage >= 14
AND objectives_completed < 2
```
This cohort will dynamically update as customers match or unmatch the criteria
***
## Step 4: Launch your first job
Jobs are where intervention happens. They target an audience with a goal and drive action through messaging.
### Create an onboarding nudge job
Go to **Jobs** in the main navigation
Click **Create Job** and configure the basics:
* **Name:** Onboarding Nudge
* **Target type:** Organisation
What do you want customers to do?
```
projects_created >= 1
```
Use your cohort or define criteria directly:
```
Member of cohort "Stuck in Onboarding"
```
How long before customers exit if they don't complete?
```
14 days
```
Add a **Message Customer** action with plain text email:
```
Subject: Quick tip to get started with {product_name}
Hi {first_name},
I noticed your team at {organization_name} signed up recently
but hasn't created your first project yet.
Here's how to get started - it takes about 5 minutes:
1. Click "New Project" in the dashboard
2. Give your project a name
3. Add your first task
If you run into any issues, just reply to this email.
Thanks,
{sender_name}
```
Review your configuration and click **Go Live**
**Plain text emails work best.** They look personal and get 10x higher engagement than branded HTML templates.
***
## What you've built
Congratulations! You now have a working Trig configuration:
Onboarding stage tracking new customer progression
Key milestones measuring healthy customer behaviour
Reusable segment identifying customers who need help
Automated intervention nudging stuck customers
### The virtuous cycle
With this foundation in place:
1. **New customers enter** the Onboarding stage automatically
2. **Objectives track** their progress against key milestones
3. **Slow completers** are identified by Signals
4. **Jobs intervene** to get them back on track
5. **Completion data** improves your understanding of "normal"
***
## Next steps
Configure Adoption, Expansion, and Renewal stages
Chain jobs based on outcomes for progressive journeys
Proactively surface customers who need attention
Track milestone moments beyond stages
***
## Checklist
Before moving on, confirm:
Stage created with entry and exit criteria
4 to 7 objectives defined with clear completion criteria
At least one cohort for targeting
First job live with plain text email action
Data flowing - customers entering stages and objectives tracking
# Adoption Jobs
Source: https://docs.trig.ai/use-cases/adoption-campaigns
Building sticky habits before customers drift away
This guide walks you through configuring an adoption job in Trig, with detailed explanations of why each configuration choice matters and how to think through decisions for your specific business.
**Worked Example:** Throughout this guide, we'll follow TeamFlow, a collaborative project management tool. TeamFlow has noticed that customers who complete onboarding often plateau in the weeks that follow—some develop deep habits and become power users, others log in occasionally and eventually churn at renewal.
## Why adoption matters
### The adoption gap
Most companies invest heavily in:
* **Onboarding:** Getting customers to their first "aha moment"
* **Renewal:** Saving customers who are about to churn
But they neglect:
* **Adoption:** The 10 months between onboarding and renewal where habits form
This creates an adoption gap—a period where customers are left to their own devices, slowly disengaging while your attention is elsewhere.
### The adoption-retention connection
| Adoption Pattern | What It Looks Like | Retention Outcome |
| --------------------- | ---------------------------------------------------- | ------------------- |
| **Deep adoption** | Daily usage, multiple features, team-wide engagement | 95%+ retention |
| **Moderate adoption** | Weekly usage, core features only, single user focus | 70-80% retention |
| **Shallow adoption** | Monthly or less, minimal feature use, champion only | 40-50% retention |
| **Failed adoption** | Declining usage, abandoned features, no engagement | Under 20% retention |
The difference between deep and shallow adoption is often 11 months of accumulated habits—or lack thereof.
### The intervention window
Adoption is the stage where small interventions have outsized impact:
* **During onboarding**, customers expect guidance—it's built into the experience
* **At renewal**, customers have already formed opinions—you're fighting inertia
* **During adoption**, customers are still forming habits—a timely nudge can redirect their trajectory
***
## Step 1: Define your adoption stage
### How to think about stage boundaries
**Entry considerations:**
* Has the customer completed your defined onboarding milestones?
* Have they had enough time to form initial habits? (Usually 14-30 days minimum)
* Are they past the "honeymoon period" where everything looks positive?
**Duration considerations:**
* How long does it take for usage patterns to stabilise?
* When do you have enough data to distinguish adopters from drifters?
* How much time before renewal do you need to intervene if adoption is failing?
**Exit considerations:**
* What does successful adoption look like in measurable terms?
* At what point have they "graduated" to a stable, retained customer?
### Example configuration
```
Stage Duration: Day 31 to Day 180
Entry Criteria:
- Onboarding stage = Complete
- At least one onboarding objective achieved
- Customer status = Active
- Not in at-risk retention job
Exit Criteria (Success):
- All 5 adoption objectives achieved
- OR: Adoption health score = "Healthy" for 30+ consecutive days
Exit Criteria (Failure/Escalation):
- Adoption health score = "Critical" for 14+ consecutive days
→ Move to at-risk retention job
```
***
## Step 2: Define your adoption objectives
### Types of adoption objectives
| Objective Type | What It Measures | Examples |
| ------------------------ | --------------------------------- | ------------------------------------- |
| **Depth** | How much they use core features | Projects created, tasks completed |
| **Breadth** | How many features they've adopted | Features used, integrations connected |
| **Frequency** | How often they engage | Daily active users, weekly sessions |
| **Team spread** | How many people are engaged | Active users as % of seats |
| **Workflow integration** | How embedded you are | API usage, automation rules |
### Example: TeamFlow's adoption objectives
| # | Objective | How We Measure It | Target | Why This Matters |
| - | -------------------- | ------------------------------------------ | ------- | ------------------------------------- |
| 1 | Team Activation | `active_users / licensed_seats >= 50%` | Day 45 | Team-wide adoption = 3x retention |
| 2 | Project Velocity | `>=3 projects with >=10 tasks each` | Day 60 | Multi-project = embedded workflow |
| 3 | Collaboration Habit | `>=5 comments/mentions per week` (3 weeks) | Day 75 | Communication hub = switching costs |
| 4 | Feature Expansion | `>=3 advanced features used` | Day 90 | Advanced features = deeper value |
| 5 | Workflow Integration | `>=1 integration OR automation` | Day 120 | Technical integration = hard to leave |
***
## Step 3: Define health indicators and warning signs
### Healthy adoption indicators
| Indicator | What It Means | How We Measure |
| ------------------------- | -------------------------- | ------------------------------------------ |
| Consistent weekly usage | Product is part of routine | Active days ≥3 per week, sustained 4 weeks |
| Usage growing or stable | Engagement isn't declining | WAU trend flat or positive over 30 days |
| Team engagement spreading | Multiple people invested | New users activated in last 30 days |
| Feature exploration | Discovering more value | New feature used in last 30 days |
| Champion highly active | Key advocate engaged | Primary contact active in last 7 days |
### Adoption warning signs
| Warning Sign | What It Signals | How We Measure |
| ---------------------- | ----------------------- | ---------------------------------------- |
| Usage declining | Disengagement beginning | WAU down >25% vs prior 30 days |
| Single-user dependency | No team adoption | Only 1 active user for 30+ days |
| Feature regression | Abandoning capabilities | Previously used features unused 30+ days |
| Champion absence | Key advocate disengaged | Primary contact no login for 14+ days |
| Stalled objectives | Not progressing | No new objective achieved in 45+ days |
| Login gap | Extended absence | No team logins for 7+ days |
### Health score calculation
```
Health Score:
- Excellent: ≥4 positive indicators, 0 negative indicators
- Good: ≥3 positive indicators, ≤1 negative indicator
- Moderate: ≥2 positive indicators, ≤2 negative indicators
- Poor: Fewer than 2 positive indicators OR 3+ negative indicators
- Critical: ≥4 negative indicators OR login gap >14 days
```
***
## Step 4: Configure adoption interventions
### Intervention design
Different warning signs need different interventions:
**Trigger:** WAU declined >25% vs prior 30-day period
**Audience Filter:**
* Tenure >45 days (not still in onboarding turbulence)
* Not already in intervention job (30-day cooldown)
* Health score ≥ "Moderate" (not yet critical)
**Timing:** Within 48 hours of trigger detection
**Goal:** Understand why and re-engage before they drift further
**Trigger:** Only 1 active user for 30+ consecutive days
**Audience Filter:**
* Licensed seats > 1 (excludes legitimate single-user accounts)
* Tenure >60 days (had time to expand)
**Timing:** Next business day, 10 AM customer timezone
**Goal:** Help them expand to team members before champion changes jobs
**Trigger:** Primary contact no login for 14+ days
**Audience Filter:**
* At least one other user still active
* Primary contact identified in CRM
**Timing:** Within 24 hours of trigger
**Goal:** Reconnect with champion or identify new stakeholder
**Trigger:** No new adoption objective achieved in 45+ days
**Audience Filter:**
* At least 1 objective still incomplete
* Tenure >60 days
**Timing:** Next business day
**Goal:** Provide guidance, training, or support to unblock them
**Trigger:** Zero team logins for 7+ consecutive days
**Audience Filter:**
* Not a known holiday period
* Account not scheduled for churn
**Timing:** Immediate (within 25 minutes)
**Goal:** Urgent re-engagement before account goes cold
***
## Step 5: Write your intervention messages
### Message philosophy
Adoption messages are delicate. You're reaching out to someone who's disengaging—potentially frustrated, overwhelmed, or simply not finding value.
| Feels Needy | Feels Helpful |
| ----------------------------------------- | ----------------------------------------------------- |
| "We noticed you haven't logged in lately" | "I wanted to share a quick tip for \[their use case]" |
| "Don't forget about us!" | "Is there anything blocking you from \[objective]?" |
| "Your team isn't using all the features" | "Teams like yours often get value from \[feature]" |
### Example messages
```
Subject: Quick question about your [Product] setup
Hi {first_name},
I was looking at how your team uses [Product] and noticed
things have slowed down a bit recently. I wanted to check
in—is there something that's not working the way you expected?
Sometimes teams hit a wall with [specific feature based on
their usage], and there are usually quick fixes. If that's
happening, I'd be happy to jump on a 15-minute call to sort
it out.
Or if priorities have just shifted, no worries—I'm here when
you need me.
Sarah
Customer Success
```
```
Subject: Getting your team into [Product]
Hi {first_name},
I noticed you're the main person using [Product] on your team
right now. That's totally fine for some workflows, but most
teams find they get a lot more value when everyone's in the
same system—less status update meetings, less "where's that
document?" conversations.
If you'd like help getting your teammates set up, I can send
you a quick guide, or even join a 15-minute call to walk them
through it.
Want me to send that guide over?
Sarah
Customer Success
```
```
Subject: Checking in
Hi {first_name},
I haven't seen you in [Product] recently, though I see your
team is still active. Just wanted to make sure everything's
okay and see if there's anything you need from me.
If your role has changed or someone else is now managing
[Product], I'm happy to connect with them instead—just let
me know.
Hope you're doing well.
Sarah
Customer Success
```
```
Subject: Getting more from [Product]
Hi {first_name},
I've been looking at how your team uses [Product], and I
think there are a few features you might find valuable that
you haven't explored yet.
Would you be interested in a quick 20-minute walkthrough?
I can show you specifically what would help based on how
your team works—no generic demo, just the stuff that's
relevant to you.
Let me know if you'd like to set that up.
Sarah
Customer Success
```
***
## Step 6: Configure follow-up logic
### Follow-up design principles
* **Change the angle:** Don't just repeat the same message
* **Increase value:** Offer something new (guide, call, help)
* **Decrease friction:** Make the action even easier
* **Know when to stop:** After 2 to 3 attempts, more emails hurt more than help
### Example follow-up sequence (single-user rescue)
| Day | Action |
| ------ | --------------------------------------------------------- |
| Day 0 | Initial message sent |
| Day 10 | If still single-user → Send follow-up with training offer |
| Day 21 | If still single-user → Internal alert (high churn risk) |
***
## Step 7: Configure internal notifications
### Escalation triggers
| Trigger | Channel | Action |
| ----------------------------------------------- | ---------------- | -------------------- |
| Any adoption intervention sent | Dashboard log | Visibility |
| High-value customer (\$25K+) triggers | CSM Slack DM | Personal attention |
| Follow-up triggered (first message didn't work) | Slack channel | Team awareness |
| Health score drops to "Critical" | CS Manager alert | Potential escalation |
### Sample alert
```
⚠️ Adoption Alert
Customer: Acme Corp ($18,000/year)
Adoption Day: 75
Health Score: Poor → Declining
Warning Signs Detected:
• Usage down 38% vs last month
• Only 3 of 12 seats active
• No new features explored in 45 days
Intervention sent: "Single-User Rescue"
Consider: Training session offer, CSM outreach
📊 View in Trig → [link]
```
***
## Step 8: Define success metrics
### Metrics to track
| Metric | What It Measures |
| ------------------------------ | ------------------------------------ |
| **Objective completion rate** | % completing each adoption objective |
| **Health score distribution** | % in each health category |
| **Intervention response rate** | % who engage after intervention |
| **Recovery rate** | % who improve after intervention |
| **Correlation to renewal** | Do adoption metrics predict renewal? |
***
## Summary checklist
Adoption stage defined (entry after onboarding, \~6 month duration)
5 to 7 adoption objectives covering depth, breadth, frequency
Health indicators (positive signals) defined
Warning signs (negative signals) defined
Interventions configured for each warning sign
Follow-up sequences designed
Internal escalation paths configured
***
## Next steps
Capture revenue growth from your happiest customers
Proactive renewal management that prevents churn
# Expansion Jobs
Source: https://docs.trig.ai/use-cases/expansion-campaigns
Capturing revenue growth from your happiest customers
This guide walks you through configuring an expansion job in Trig, with detailed explanations of why each configuration choice matters and how to think through decisions for your specific business.
**Worked Example:** Throughout this guide, we'll follow TeamFlow, a collaborative project management tool with tiered pricing (Starter, Professional, Business, Enterprise). TeamFlow has identified that their most efficient revenue growth comes from existing customers expanding—but their small sales team can't monitor every customer for expansion signals.
## Why expansion matters
### The economics of expansion
| Metric | New Customer Acquisition | Customer Expansion |
| ----------------- | ------------------------ | ------------------------- |
| Sales cycle | 30-90 days typical | Days to weeks |
| Win rate | 15-25% typical | 40-60% typical |
| CAC payback | 12-18 months | Often immediate |
| Relationship | Building trust | Trust already established |
| Product knowledge | Starting from zero | Already using and loving |
Expansion revenue is often 3 to 5x more efficient than new customer acquisition. A customer hitting their seat limit is pre-sold—they've already decided your product works.
### The timing problem
The challenge isn't identifying that expansion opportunities exist—it's identifying them at the right moment:
* **Too early:** "Want to upgrade?" feels like a sales ambush
* **Too late:** They've already worked around the limitation or found an alternative
* **Just right:** "I noticed you're running low on seats..." feels helpful
Trig solves the timing problem by monitoring expansion signals in real-time and triggering outreach when conditions are optimal.
***
## Step 1: Define your expansion stage
### How to think about expansion stage boundaries
**Entry considerations:**
* Has the customer completed onboarding?
* Are they healthy (not at-risk)?
* Have they been a customer long enough to form an opinion?
**Exit considerations:**
* They expanded (success!)
* They declined and shouldn't be asked again for X months
* They churned (no longer relevant)
### Example configuration
```
Stage Duration: Day 60 to ongoing (continuous monitoring)
Entry Criteria:
- Onboarding stage = Complete
- Customer tenure ≥ 60 days
- Customer health = Good or Excellent
- Current contract value > $0 (excludes free trials)
Exit Criteria:
- Customer completes expansion purchase (success)
- Customer explicitly declines (90-day cooldown)
- Customer health drops to At-Risk (moved to renewal job)
```
***
## Step 2: Identify your expansion signals
### Types of expansion signals
| Signal Category | What It Indicates | Examples |
| ------------------- | ---------------------------- | --------------------------------------------------- |
| **Limit-based** | Customer hitting constraints | Approaching seat limit, storage full |
| **Usage-based** | Growing engagement | Active users increasing, feature adoption expanding |
| **Behaviour-based** | Exploring upgrade | Viewing pricing page, clicking upgrade buttons |
| **Milestone-based** | Business growth | Team size increased, new department added |
| **Time-based** | Natural expansion moments | Anniversary, renewal approaching (healthy customer) |
### Example: TeamFlow's expansion signals
| Signal | How We Detect It | Expansion Opportunity | Conversion Rate |
| --------------------- | ----------------------------------- | ------------------------- | --------------- |
| Admin invite blocked | `invite_blocked_seat_limit` event | Add seats (urgent) | 72% 🔴 |
| Seat utilisation >85% | `active_users/licensed_seats > 85%` | Add seats or upgrade tier | 58% 🔴 |
| Integration interest | `>3 integration page views/30 days` | Upgrade to Business | 34% 🟡 |
| Power users emerging | `3+ users with >20hrs/week usage` | Upgrade tier | 28% 🟡 |
| Company growing | CRM headcount up >20% | Proactive expansion | 19% 🟢 |
**Prioritise by conversion rate.** A customer who just tried to invite someone and hit a seat cap is 72% likely to expand. That's a hot lead—act immediately.
***
## Step 3: Define expansion ownership
### Ownership models
| Model | How It Works | Best For |
| -------------------- | -------------------------------------------- | ------------------------------ |
| **Self-serve first** | Automated email → in-app upgrade flow | SMB, low ACV, high volume |
| **Sales-assisted** | Signal triggers sales outreach | Mid-market, complex pricing |
| **CSM-led** | CSM owns relationship + expansion | Enterprise, strategic accounts |
| **Tiered hybrid** | Route based on signal type or customer value | Mixed customer base |
### Example: TeamFlow's tiered routing
| Signal Type | Owner | Motion |
| --------------------------- | ---------- | ------------------------------------- |
| Seat limit (Starter/Pro) | Self-serve | Automated email → in-app upgrade |
| Seat limit (Business+) | CSM | Personal outreach |
| Tier upgrade interest | Self-serve | Automated email → in-app upgrade |
| Integration interest | CSM | Discovery call, Business tier pitch |
| Power users (SMB) | Automated | Email nurture toward tier upgrade |
| Power users (Mid-market) | CSM | Business review, expansion discussion |
| Enterprise signals (\$25K+) | AE + CSM | Joint outreach, custom pricing |
***
## Step 4: Configure expansion triggers
### Trigger design principles
* **Specificity:** One trigger per expansion type (don't bundle seat expansion with tier upgrade)
* **Confidence threshold:** Multiple signal instances or combined signals for higher confidence
* **Cooldown logic:** Don't re-trigger if already in an expansion conversation
* **Timing sensitivity:** Some signals are time-sensitive (blocked invite), others aren't
### Example trigger configurations
**Condition:** `invite_blocked_seat_limit` event fired
**Timing:** Immediate (within 25 minutes)
**Cooldown:** None (always trigger—this is urgent)
**Owner:** Self-serve email + in-app prompt
**Condition:** `seat_utilisation > 85%` for 7+ consecutive days
**Timing:** Next business day, 10 AM customer timezone
**Cooldown:** 30 days since last seat expansion message
**Owner:** Self-serve email
**Condition:** `integration_page_views > 3` in last 30 days AND tier ∈ \[Starter, Professional]
**Timing:** 48 hours after threshold crossed (let them explore)
**Cooldown:** 60 days since last tier upgrade message
**Owner:** CSM (mid-market) / Self-serve (SMB)
**Condition:** `power_users >= 3` for 14+ consecutive days AND tier ∈ \[Starter, Professional]
**Timing:** Next business day
**Cooldown:** 60 days since last tier upgrade message
**Owner:** CSM outreach
**Condition:** tier = Business AND `seat_utilisation > 80%` AND `contract_value > $25,000`
**Timing:** Route to AE within 24 hours
**Cooldown:** 90 days
**Owner:** AE + CSM joint outreach
***
## Step 5: Write your expansion messages
### Message philosophy
Expansion messages should feel like service, not sales.
| Feels Like Sales | Feels Like Service |
| --------------------------------------- | -------------------------------------------- |
| "Your account is ready for an upgrade!" | "I noticed you're almost out of seats..." |
| "Unlock premium features today!" | "I saw your team trying to connect Slack..." |
| "Contact us to discuss pricing" | "Here's a quick link to add more seats" |
### Example messages
This is TeamFlow's highest-converting message because it arrives at the exact moment of need.
```
Subject: Quick fix for that invite issue
Hi {first_name},
I saw you tried to invite someone to [Product] but hit your
seat limit. Here's a quick link to add more seats so you can
get them in:
[Add Seats →]
Takes about 30 seconds. Let me know if you need anything else.
Sarah
Customer Success
```
This message reaches customers before they hit the wall.
```
Subject: Heads up on your [Product] seats
Hi {first_name},
Your team is using {X} of your {Y} [Product] seats—you're
getting close to your limit.
If you're planning to bring on more team members, you can
add seats anytime here: [Add Seats →]
Or if you'd like to discuss what tier makes sense as you
grow, just reply to this email.
Sarah
Customer Success
```
```
Subject: Saw you checking out integrations
Hi {first_name},
I noticed you've been exploring [Product]'s integration
options. Those are available on our Business tier—they let
you connect [Product] to Slack, Jira, and 20+ other tools
your team probably uses.
Would it be helpful to see a quick demo of how the Slack
integration works? I can show you in 15 minutes.
Sarah
Customer Success
```
```
Subject: Your team is getting serious value from [Product]
Hi {first_name},
I've been looking at how your team uses [Product], and I'm
impressed—you've got several people who are really power
users at this point.
When teams reach this level, they usually start wanting
things like advanced reporting, custom workflows, and
integrations. Those are part of our Professional tier.
Would it be worth 20 minutes to walk through what you'd get
with an upgrade? I can show you specifically what would help
based on how your team works.
Sarah
Customer Success
```
```
Subject: Thinking about your [Product] setup
Hi {first_name},
Your team has grown a lot on [Product] this year—you're
getting close to your seat limit again, and I know you've
mentioned wanting some capabilities we don't have in
Business tier.
I'd like to introduce you to {AE_name}, who works with our
larger customers on custom packages. They can put together
something that fits exactly what you need, including volume
pricing if you're planning to expand further.
Would you be open to a call with the three of us? I'll stay
involved to make sure you get what you need.
Sarah
Customer Success
```
***
## Step 6: Configure internal notifications
### Routing alerts
| Signal | Routing | SLA |
| ------------------------------ | ----------------------- | --------- |
| Urgent seat expansion | Self-serve (automated) | Immediate |
| High-value (\$25K+) any signal | CSM Slack DM + AE alert | 4 hours |
| Enterprise expansion signals | AE + CSM + Manager | 24 hours |
| Declined expansion | Log for analysis | N/A |
### Sample alert
```
🚀 Expansion Opportunity
Customer: Acme Corp ($28,000/year, Business tier)
Signal: Seat utilisation at 92% (23/25 seats)
Context:
• Added 5 users in last 30 days
• Using 8 of 12 advanced features
• No support tickets in 60 days
Recommended Action: CSM outreach for Enterprise conversation
📊 View in Trig → [link]
📞 Book Call → [link]
```
***
## Step 7: Define success metrics
### Metrics to track
| Metric | What It Measures |
| --------------------------------- | -------------------------------------- |
| **Signal-to-opportunity rate** | % of signals that become conversations |
| **Opportunity-to-close rate** | % of conversations that expand |
| **Time from signal to expansion** | How quickly do they expand? |
| **Expansion revenue** | Total revenue from expansion jobs |
| **Signal accuracy** | Do signals actually predict expansion? |
### Benchmarking
| Signal Type | Expected Conversion |
| -------------------------- | ------------------- |
| Invite blocked (urgent) | 60-80% |
| Seat utilisation >85% | 40-60% |
| Feature interest | 25-40% |
| Usage-driven upgrade | 20-35% |
| Proactive (company growth) | 15-25% |
***
## Summary checklist
Expansion stage defined (entry after onboarding + healthy)
Expansion signals identified with conversion data
Ownership model defined (self-serve, CSM, hybrid)
Triggers configured with appropriate thresholds and cooldowns
Service-oriented messages written for each signal
Internal routing configured for high-value opportunities
Success metrics defined
***
## Next steps
Proactive renewal management that prevents churn
Detailed guide on job configuration
# Onboarding Jobs
Source: https://docs.trig.ai/use-cases/onboarding-campaigns
Getting customers to their 'aha moment' before they give up
This guide walks you through configuring an onboarding job in Trig, with detailed explanations of why each configuration choice matters and how to think through decisions for your specific business.
**Worked Example:** Throughout this guide, we'll follow TeamFlow, a collaborative project management tool. TeamFlow has discovered that the first 30 days determine everything—customers who reach their "aha moment" become long-term retained customers, while those who never quite get started churn at renewal.
## Why onboarding matters
### The onboarding truth
Here's what the data consistently shows across B2B SaaS:
| Onboarding Outcome | Long-term Retention |
| ----------------------------------- | ------------------- |
| Reached "aha moment" in first week | 85-95% |
| Reached "aha moment" in first month | 70-80% |
| Never reached "aha moment" | 15-30% |
The pattern is stark: customers who experience value quickly almost always stay. Customers who don't almost always leave.
### The silent failure problem
The challenge with onboarding failure is that it's invisible:
* Customers don't complain—they just stop logging in
* They don't ask for help—they assume the product isn't for them
* They don't cancel immediately—they drift until renewal and then churn
By the time you notice a customer didn't onboard successfully, it's usually too late.
### The intervention window
| Stage | Intervention Window | Customer Mindset |
| -------------- | ------------------- | ------------------------------- |
| **Onboarding** | Days | "I'm trying to figure this out" |
| Adoption | Weeks | "I'm forming habits" |
| Renewal | Months | "I've made up my mind" |
A customer stuck on Day 3 is still open to help. A customer who's been stuck for 3 months has already checked out mentally.
***
## Step 1: Define your onboarding stage
### What you're configuring
The onboarding stage parameters define when customers enter onboarding, how long they have to complete it, and what success looks like.
### How to think about onboarding boundaries
**Entry considerations:**
* When does the customer first have access to your product?
* Do they need prerequisites before real onboarding begins?
* Is there a "Day 0" setup phase that should be tracked separately?
**Duration considerations:**
* How long does it typically take successful customers to onboard?
* How long are you willing to actively nurture before considering them stalled?
* When do diminishing returns kick in?
**Exit considerations:**
* What specific milestone(s) indicate successful onboarding?
* When should you stop trying and either escalate or accept failure?
### Example configuration
TeamFlow analysed their customer data and found clear patterns:
* **Successful customers** typically completed onboarding in 7-14 days
* **Customers who took >30 days** had 3x higher churn
* **After Day 30**, additional onboarding effort showed minimal retention impact
TeamFlow defined success as: "Customer has at least one active project with 2+ team members collaborating"
```
Stage Duration: Day 1 to Day 30 (from first login)
Entry Criteria:
- First login completed
- Account status = Active
- Not a demo or test account
Exit Criteria (Success):
- Objective #4 achieved (team actively collaborating)
- → Move to Adoption stage
Exit Criteria (Failure):
- Day 30 reached without completing Objective #4
- → Move to At-Risk Onboarding job
```
***
## Step 2: Define your onboarding objectives
### Objective design principles
The best onboarding objectives are:
| Principle | What It Means | Example |
| ------------------- | ------------------------------------- | ------------------------------------------------- |
| **Sequential** | Each objective builds on the previous | Create project → Add task → Invite teammate |
| **Measurable** | Binary yes/no, detectable in data | "Created a project" not "understands the product" |
| **Value-connected** | Each moves customer closer to value | Not just setup steps—actual value realisation |
| **Time-bounded** | Clear target date for completion | "By Day 3" not "eventually" |
### Finding your "aha moment"
One objective should be your critical "aha moment"—the single milestone most predictive of long-term retention.
To identify your "aha moment":
1. Look at retained customers: What did they all do early on?
2. Look at churned customers: What did they fail to do?
3. Find the behaviour with the biggest retention gap between doers and non-doers
### Example: TeamFlow's onboarding objectives
| # | Objective | How We Measure It | Target | Why This Matters |
| - | ------------------------ | ----------------------------------- | ------ | ------------------------------------ |
| 1 | First Login | `first_login_timestamp` exists | Day 1 | Entry point—no login, no onboarding |
| 2 | Create First Project | `projects.count >= 1` | Day 3 | Container for all value |
| 3 | Add First Tasks | `tasks.count >= 5` in project | Day 7 | Real work, not just exploring |
| 4 | **Invite Team Member** ⭐ | `active_team_members >= 2` | Day 14 | **AHA MOMENT** - 4x retention impact |
| 5 | Team Activity | `distinct_users_with_activity >= 2` | Day 21 | Confirms real collaboration |
**Critical "Aha Moment":** TeamFlow's data showed that customers who invited a teammate by Day 14 had 89% retention, while customers who never invited a teammate had only 31% retention—a 58 percentage point gap.
***
## Step 3: Configure onboarding interventions
### Intervention design principles
* **Specificity:** One intervention per objective (don't bundle)
* **Timing:** Intervene soon after the target date passes
* **Helpfulness:** Focus on unblocking them, not guilting them
* **Urgency calibration:** Earlier objectives warrant faster intervention
* **Escalation path:** Plan for what happens if intervention doesn't work
### Example intervention design
**Problem:** Customer signed up but never logged in
**Urgency:** High (they may have already forgotten about us)
**Timing:** 24 hours after signup if no login
**Goal:** Get them to log in and start exploring
**Problem:** Customer logged in but didn't create a project
**Urgency:** Medium-high (they're exploring but not committing)
**Timing:** Day 4 if no project created
**Goal:** Help them create their first project
**Problem:** Customer created a project but it's empty
**Urgency:** Medium (they started but got stuck)
**Timing:** Day 8 if fewer than 5 tasks
**Goal:** Help them add real work to their project
**Problem:** Customer is working alone—hasn't invited anyone
**Urgency:** Highest (this is the aha moment!)
**Timing:** Day 10 (early intervention—don't wait until Day 15)
**Goal:** Make inviting a teammate feel easy and valuable
**Problem:** Teammate was invited but isn't engaging
**Urgency:** Medium (teammate may need their own nudge)
**Timing:** Day 22 if teammate hasn't taken action
**Goal:** Get the invited teammate to participate
***
## Step 4: Write your intervention messages
### Message philosophy
Onboarding messages should feel like a helpful friend, not a marketing automation.
| Feels Like Automation | Feels Like Help |
| ------------------------------------- | ----------------------------------------------- |
| "You haven't completed your setup!" | "Need help getting your first project started?" |
| "Don't forget to invite your team!" | "Here's a quick way to bring your teammates in" |
| "Complete these steps to get started" | "Most teams find it useful to start with..." |
### Message structure
Effective onboarding messages follow a simple structure:
1. **Acknowledge where they are** (not accusatory)
2. **Explain the benefit** of the next step (not the feature)
3. **Make the action extremely easy** (direct link, clear CTA)
4. **Offer help** if they're stuck (open the door)
### Example messages
```
Subject: Your [Product] account is ready
Hi {first_name},
Your [Product] account is set up and ready to go. You can log in
here and create your first project in about 2 minutes:
[Log In to {Product} →]
If you hit any snags getting in, just reply to this email and
I'll help you sort it out.
Sarah
Customer Success
```
```
Subject: Quick tip for getting started
Hi {first_name},
I saw you logged into [Product]—great! The fastest way to see
how it can help is to create a project for something you're
actually working on right now.
It doesn't have to be perfect. Most people start with a simple
project and build from there. You can create one here:
[Create Your First Project →]
If you're not sure what kind of project to start with, I'm
happy to share some examples from teams like yours.
Sarah
Customer Success
```
```
Subject: [Product] works better with your team
Hi {first_name},
I noticed you're using [Product] solo right now. That's a great
start, but here's what I've seen: teams that use [Product]
together spend way less time in status meetings and "where's
that file?" conversations.
The easiest way to try it: invite one teammate to collaborate
on {project_name}. Takes about 30 seconds:
[Invite a Teammate →]
They'll get an email with everything they need to jump in.
You can always add more people later.
If you'd prefer to keep this project private, that's totally
fine too—just let me know and I'll adjust your setup.
Sarah
Customer Success
```
***
## Step 5: Configure sender identity
### Options
| Sender Type | Best For |
| ------------------------------ | -------------------------------------------- |
| **Real onboarding specialist** | Maximum authenticity, but scalability issues |
| **Automated/Team sender** | Clearly automated, lower engagement |
| **Dedicated persona** | Consistent, human-feeling, scalable |
**Recommendation:** Use a dedicated persona (like "Sarah Chen") for most customers, with real CSM names for enterprise accounts (\$25K+) to establish relationships early.
***
## Step 6: Set message timing
### Timing principles
| Objective | Recommended Timing | Reasoning |
| -------------------------------- | ------------------------ | ---------------------------------------- |
| First login (Day 1) | 24 hours after signup | Give them a chance to log in organically |
| Early objectives (Day 3-7) | Morning of target day +1 | Catch them when they're fresh |
| Critical objectives (Aha moment) | Earlier than target | Don't wait—intervene proactively |
| Later objectives (Day 14+) | Next business day | Less urgency, avoid weekends |
***
## Step 7: Configure follow-up logic
### Follow-up design
Not every customer will respond to the first message. You need a plan for:
* **Persistence:** Some customers need multiple touches
* **Escalation:** When to involve humans
* **Exit:** When to stop trying (to avoid annoying customers)
### Example: "No teammate" follow-up sequence
| Days After First Message | Action |
| ------------------------ | --------------------------------------------------- |
| Day 0 | First message sent |
| Day 3 | Follow-up message (different angle, offer help) |
| Day 7 | Internal notification (human may need to intervene) |
| Day 14 | Exit job → Move to "at-risk onboarding" segment |
### Follow-up message example
```
Subject: Quick thought on [Product]
Hi {first_name},
I wanted to share something I've noticed: the teams that get the
most from [Product] usually start by inviting just one other
person—not the whole team, just someone they work closely with.
Would it help if I showed you how to set that up? I can do it
in a 5-minute call: [Book a Quick Call →]
Or if you'd prefer to just try it yourself: [Invite Someone →]
Sarah
```
***
## Step 8: Configure internal notifications
### Tiered notification system
| Level | Trigger | Channel | Action Expected |
| --------------------- | -------------------------------------- | ------------------- | ---------------------- |
| **1: Logging** | All interventions sent | Dashboard log | Daily digest review |
| **2: Reply Handling** | Customer replies | Slack DM to CS | Respond within 4 hours |
| **3: High-Value** | \$15K+ customer triggers intervention | CSM DM | Personal attention |
| **4: Escalation** | "Aha moment" intervention failed twice | Slack channel + CSM | Consider outreach |
| **5: Abandonment** | No login 14+ days | Leadership alert | Executive review |
### Sample high-value alert
```
⚠️ High-Value Onboarding Alert
Customer: Acme Corp ($28,000/year)
Onboarding Day: 10
Stuck At: No teammate invited (Objective #4)
Progress:
✅ First login (Day 1)
✅ Created project (Day 2)
✅ Added tasks (Day 5)
❌ Invited teammate ← BLOCKED
Intervention sent today. This is the "aha moment" objective.
Consider personal outreach.
📊 View Customer → [link]
```
***
## Step 9: Define success metrics
### Metrics to track
| Metric Type | What It Measures | Example |
| ------------------------- | ---------------------------------- | ------------------------------------------- |
| **Objective Completion** | Did the intervention work? | % who complete objective after intervention |
| **Time to Completion** | How quickly do they complete? | Days from intervention to completion |
| **Response Rate** | Are customers engaging? | % who reply or click |
| **Retention Correlation** | Does completion predict retention? | Retention rate by objective status |
### Setting benchmarks
For your first month, focus on establishing baselines:
* What % complete each objective without intervention?
* What % complete after intervention?
* How does timing affect completion?
Then iterate: adjust messaging, timing, and targeting based on data.
***
## Summary checklist
Onboarding stage defined with entry/exit criteria
4 to 7 objectives identified with clear completion criteria
"Aha moment" objective identified
Intervention triggers configured for each objective
Plain text messages written for each intervention
Follow-up sequences designed
Internal escalation paths configured
Success metrics defined
***
## Next steps
Build sticky habits after customers complete onboarding
Detailed guide on job configuration
# Renewal Jobs
Source: https://docs.trig.ai/use-cases/renewal-campaigns
Proactive renewal management that prevents churn before it happens
This guide walks you through configuring a renewal job in Trig, with detailed explanations of why each configuration choice matters and how to think through decisions for your specific business.
**Worked Example:** Throughout this guide, we'll follow TeamFlow, a collaborative project management tool with 2,000 customers. Their product is sticky when teams actively use it, but customers who don't achieve full team adoption often churn at renewal. With only 4 CSMs, they can't personally manage every renewal.
## Why proactive renewal management matters
### The renewal reality
By the time a customer tells you they're not renewing, the decision was made weeks or months ago. The renewal conversation is just the notification—the actual decision happened during:
* The month they stopped logging in
* The week their champion left
* The day they couldn't get a support issue resolved
Proactive renewal management means detecting these moments early enough to intervene.
### The cost of reactive renewal
| Approach | Detection Point | Intervention Success |
| --------------------- | --------------------------------------- | -------------------- |
| **Reactive** | Customer says "we're not renewing" | 10-20% save rate |
| **Proactive (late)** | 30 days before renewal, health check | 30-40% save rate |
| **Proactive (early)** | 60+ days before, warning signs detected | 50-70% save rate |
***
## Step 1: Define your renewal window
### What you're configuring
The renewal window determines how far in advance of a customer's renewal date they enter your renewal job.
### How to choose your window
Consider your typical "save" conversation timeline:
| Window Length | Best For | Considerations |
| ------------- | -------------------------- | ----------------------------------------------- |
| **30 days** | SMB, self-serve, low-touch | Fast cycles, quick decisions |
| **60 days** | Mid-market, moderate touch | Time for 1-2 intervention attempts |
| **90+ days** | Enterprise, high-touch | Complex buying processes, multiple stakeholders |
### Example: TeamFlow's decision
TeamFlow chose 60 days because their typical "save" conversation requires:
* **Week 1:** Identify the problem (usage drop, champion left, etc.)
* **Week 2:** Diagnostic call with the customer
* **Weeks 3 to 4:** Implement solution (training, configuration change)
* **Weeks 5 to 6:** Verify the solution is working
* **Weeks 7 to 8:** Buffer for delays
```
Renewal Window: 60 days before renewal date
```
***
## Step 2: Set your entry criteria
### Example configuration
```
Entry Criteria:
- Renewal date is within 60 days
- Customer status = Active
- Contract type = Annual
```
**Start simple.** You can add segment-specific criteria later (e.g., different windows for enterprise vs. SMB).
***
## Step 3: Configure renewal health assessment
### Healthy renewal indicators
These signals indicate a customer is on track to renew without intervention:
| Indicator | What It Means | How to Measure |
| ----------------------- | ------------------------------- | ---------------------------------------- |
| Consistent usage | Product is embedded in workflow | DAU/WAU/MAU stable or growing |
| Recent feature adoption | Still investing in learning | New features used in last 30 days |
| Expanding usage | More users or use cases | Seat count increase, new team adoption |
| Support engagement | They ask questions, they care | Support tickets with positive resolution |
| Champion engagement | Internal advocate is active | Champion user login frequency |
### TeamFlow's healthy indicators
```
Healthy Renewal Indicators:
- Usage in last 14 days: Yes
- Active users: ≥70% of licensed seats
- Champion last login: Within 7 days
- Open escalated tickets: 0
```
### At-risk renewal indicators
These warning signs signal a customer may not renew:
| Warning Sign | What It Signals | How to Measure |
| -------------------- | ----------------------- | -------------------------------- |
| Usage decline | Decreasing engagement | 30%+ drop vs prior period |
| Champion absence | Advocate has disengaged | No login in 30+ days |
| Low seat utilisation | Not getting full value | Under 50% of seats active |
| Support frustration | Unresolved issues | Open tickets, negative sentiment |
| Invoice issues | Financial friction | Late payments, billing disputes |
### TeamFlow's at-risk indicators
```
At-Risk Renewal Indicators:
- Usage decline: >30% drop in WAU vs 30 days ago
- Champion login: >21 days since last activity
- Seat utilisation: Under 50% of licensed seats active
- Open support tickets: >2 unresolved for >14 days
```
### Pattern recognition
TeamFlow identified four churn patterns from their data:
**Signal:** Usage drops 30%+ over 30 days
**Cause:** Often happens when a key project ends or team priorities shift
**Intervention:** Re-engage with new use case discovery
**Signal:** Primary buyer/champion stops logging in
**Cause:** Often means they've left the company or changed roles
**Intervention:** Identify and engage new stakeholder
**Signal:** Paying for 20 seats, only 8 active users
**Cause:** Often means the rollout stalled after initial enthusiasm
**Intervention:** Adoption support, training offer
**Signal:** Multiple support tickets unresolved for 14+ days
**Cause:** Often means they've hit a wall and are giving up
**Intervention:** Escalation, executive attention
***
## Step 4: Configure at-risk renewal interventions
### Trigger configuration
```
Trigger Condition:
- Customer is within 60 days of renewal
- AND matches any At-Risk Indicator
- AND has not received intervention in last 30 days
```
**OR vs AND Logic:** TeamFlow chose OR logic—any single warning sign triggers the job. "We'd rather have false positives than miss a churning customer."
***
## Step 5: Write your intervention message
### Message best practices
| Principle | Why It Works | Common Mistake |
| --------------------- | ----------------------------- | ------------------------------------------------ |
| Plain text format | Feels like a real email | HTML templates scream "marketing automation" |
| Human sender | People respond to people | "The TeamFlow Team" gets ignored |
| Acknowledge reality | Shows you're paying attention | Pretending everything is fine |
| Offer help, not sales | Reduces defensiveness | "Let's talk about your renewal" = instant delete |
| Single ask | Clear next step | Multiple CTAs create paralysis |
### Example message
```
Subject: Your TeamFlow Renewal is Coming Up
Dear {first_name},
We noticed that your annual TeamFlow subscription will be
renewing on {renewal_date}. We wanted to reach out to ensure
you have everything you need for a smooth renewal process.
Our records indicate some changes in your usage patterns
recently. We'd love to schedule a call to discuss how
TeamFlow can continue to support your team's project
management needs.
Please let us know if you have any questions.
Best regards,
The TeamFlow Customer Success Team
```
**Problems:**
* "Dear" is formal and cold
* "The TeamFlow Customer Success Team" isn't a person
* "smooth renewal process" makes it about the transaction
* "changes in your usage patterns" is vague and ominous
* No specific ask
```
Subject: Quick question about your team's projects
Hi {first_name},
I noticed your team's activity in [Product] has dropped off
over the past few weeks. Before your renewal comes up in
{days_until_renewal} days, I wanted to check in.
If something's not working the way you need it to, I'd
genuinely like to hear about it — there might be features
or configurations we haven't explored that could help.
Do you have 15 minutes this week for a quick call?
Sarah
Customer Success
```
**Why this works:**
* "Hi" is warm and normal
* Sarah is a real person (or believable persona)
* "dropped off" acknowledges reality without accusation
* Offers help, not a sales pitch
* Single clear ask: 15-minute call
### Message variants by trigger
| Trigger | Message Focus |
| --------------- | ----------------------------------------------------- |
| Usage drop | "I noticed activity has dropped..." |
| Champion absent | "I haven't seen in \[Product] recently..." |
| Low adoption | "I noticed only of your team members are active..." |
| Support issues | "I saw you've had some support tickets open..." |
***
## Step 6: Configure sender identity
### Options
| Sender Type | Best For |
| ------------------- | ------------------------------------- |
| Real CSM (dynamic) | Accounts with named CSM relationships |
| CS Persona (static) | Accounts without assigned CSMs |
| Functional Role | Transactional communications |
### TeamFlow's decision
* **High-value accounts (>\$25K):** Email from actual assigned CSM
* **All other accounts:** Email from "Sarah Chen" — a shared persona that any team member can respond as
***
## Step 7: Set message timing
### Timing considerations
| Option | Trade-off |
| -------------------------------- | --------------------------------------- |
| Immediately | Maximum relevance, unpredictable timing |
| Wait X hours | Less urgency, allows batching |
| Next business day, specific time | Predictable, but less contextual |
| Customer timezone optimised | Best of both, requires timezone data |
### TeamFlow's decision
```
Message Timing:
- Within 25 minutes of trigger
- Delivery window: 9:00 AM - 5:00 PM customer timezone
- If trigger fires outside window, queue for next available slot
```
***
## Step 8: Configure internal escalation
### Tiered escalation system
| Tier | Trigger | Channel | Action Expected |
| ----------------- | --------------------------------------- | ----------------------- | --------------------------------------------- |
| **1: Standard** | All at-risk triggers | #renewals-at-risk Slack | CSM reviews, decides on follow-up |
| **2: High-Value** | \$25K+ contracts | CSM DM + Manager | Same-day review, potential executive outreach |
| **3: Critical** | Multiple at-risk signals, under 30 days | CS Manager + VP Sales | Executive intervention, discount authority |
### Sample Slack notification
```
🚨 At-Risk Renewal Alert
Customer: Acme Corp
Contract Value: $18,000/year
Renewal Date: March 15 (47 days)
Warning Signs Detected:
• Usage down 42% vs last month
• Primary contact last login: 28 days ago
Automated intervention sent to: john.smith@acme.com
Subject: "Quick question about your team's projects"
📊 View in Trig → [link]
```
***
## Step 9: Configure follow-up logic
### Follow-up sequence
| Day | Action |
| ------ | ------------------------------------------------ |
| Day 0 | Initial intervention message sent |
| Day 5 | If no response → Send follow-up message |
| Day 10 | If no response → Internal escalation |
| Day 14 | If no response → Phone call attempt (high-value) |
### Follow-up message
```
Subject: Re: Quick question about your team's projects
Hi {first_name},
Just floating this back up—I'd love to help if something's
not working the way you need.
Even a quick reply with what's going on would help me point
you in the right direction.
Sarah
```
***
## Step 10: Define success metrics
### Metrics to track
| Metric | What It Measures |
| ------------------------------- | ----------------------------------------------- |
| **At-risk identification rate** | % of renewals flagged as at-risk |
| **Intervention response rate** | % who reply or engage |
| **Save rate** | % of at-risk customers who renew |
| **False positive rate** | % flagged at-risk who would have renewed anyway |
| **Net retention** | Overall renewal + expansion revenue |
### Benchmarking
| Metric | Target |
| -------------------------------- | ------------------ |
| At-risk identification | 20-30% of renewals |
| Intervention response | 15-25% |
| Save rate (with intervention) | 40-60% |
| Save rate (without intervention) | 10-20% |
***
## Summary checklist
Renewal window defined (30 to 90 days based on sales cycle)
Entry criteria set (active, annual contracts)
Healthy indicators defined (4 to 5 positive signals)
At-risk indicators defined (4 to 5 warning signs)
Trigger logic configured (OR vs AND)
Plain text intervention message written
Sender identity configured
Message timing set (business hours, customer timezone)
Internal escalation tiers configured
Follow-up sequence designed
Success metrics defined
***
## Next steps
Get customers to their "aha moment" before they give up
Proactively surface and act on customers who need attention