Skip to main content
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.