The pillar (The Complete Guide to Automation and Workflows) covers the what and why. This post covers the how. The architecture beneath every HonorElevate workflow. For owners who want to understand or customize, this is the level of detail that matters.
Triggers: the four types
Type 1: Event triggers
Something happened in the system. Most common type. Examples:
- New contact created (from any source)
- Form submitted
- Web chat session ended
- Inbound call answered
- Inbound call missed
- SMS reply received
- Pipeline stage changed
- Tag added or removed
- Appointment booked
- Appointment canceled
- Payment received
- Review posted
- Job completed (via ServiceTitan/Jobber API)
Type 2: Time-based triggers
A specific time or date arrived. Examples:
- X minutes/hours/days after another event (most common: 30 min after Closed Won fires review request)
- X days/weeks before a scheduled event (24 hr before appointment = day-before reminder)
- Recurring schedule (monthly maintenance, quarterly check-in)
- Specific date (customer birthday, plan renewal anniversary)
- Inactivity threshold (no engagement in 30/60/90/180 days)
Type 3: Field-change triggers
A specific data point changed. Examples:
- Lead score crossed 80 threshold
- Custom field value updated
- Pipeline stage moved to specific state
- Tag combination achieved (Returning + Maintenance Plan Active)
Type 4: External triggers
An external system signaled. Examples:
- ServiceTitan job complete event
- Stripe payment webhook
- Calendly booking webhook
- Zapier-mediated event from any external service
- Custom API endpoint hit
Conditions: the filter layer
Conditions are optional. Some simple workflows have none ("when missed call → send SMS, always"). Most workflows benefit from at least one condition to prevent unwanted firing.
Common condition operators
- Equals / Does not equal: field is exactly value X
- Contains / Does not contain: field includes substring X
- Greater than / Less than: numeric comparison (lead score, ticket value, days in stage)
- Before / After: date comparison (Last Service Date older than 12 months ago)
- Has tag / Missing tag: contact has or does not have specified tag
- In list / Not in list: field value matches one of a set
- Is empty / Is not empty: field has any value or no value
Common condition patterns
| Condition | Use case |
|---|---|
| Service Area = Saugus OR Valencia OR Newhall | Only fire for core-area customers |
| Lead Score > 80 | Priority queue routing |
| Last Service Date > 12 months ago | Annual reminder eligibility |
| Has tag "Returning Customer" | Personalized messaging for repeat customers |
| Missing tag "DNC" | Respect Do-Not-Contact opt-outs |
| Current time between 8 AM and 9 PM local | Quiet-hours compliance |
| Pipeline Stage = Quote Sent AND days in stage > 1 | Stale quote follow-up trigger |
AND vs OR logic
Multiple conditions can be combined with AND (all must be true) or OR (any must be true). Most production workflows mix both. Example: "Send maintenance plan offer IF (current stage = Closed Won) AND (14 days since Closed Won) AND (NOT tagged Maintenance Plan Active) AND (NOT tagged DNC) AND (NOT tagged Plan Offer Declined Recently)."
Actions: the things that fire
Communication actions
- Send SMS (single or multi-part, templated or dynamic)
- Send email (templated with personalization tokens)
- Ringless voicemail drop (high-volume reactivation campaigns)
- Internal notification (Slack-style alert to owner or team)
- Push notification (to staff mobile devices)
CRM update actions
- Update pipeline stage (move contact to specific stage)
- Add tag (apply behavioral/status marker)
- Remove tag (clear marker)
- Update custom field (set specific data point)
- Adjust lead score (increment, decrement, or set absolute)
- Update contact details (name, email, phone, address corrections)
Task and calendar actions
- Create task (assigned to specific user with due date)
- Schedule appointment (book on the calendar)
- Reschedule appointment (move existing booking)
- Cancel appointment (release calendar slot)
External actions
- Push to ServiceTitan/Jobber/Housecall Pro (create job in dispatch system)
- Call Stripe (charge card, refund, subscription change)
- Trigger Zapier/Make webhook (route to external service)
- Custom HTTP request (any API endpoint)
Workflow control actions
- Wait X time (delay before next step)
- Trigger another workflow (hand off to a different workflow)
- End workflow (exit early when goal is met)
- Conditional branch (if/else path within the workflow)
Branching logic: if/else inside a workflow
Most non-trivial workflows have branches. Example pattern: post-job review request.
- Trigger: Pipeline = Closed Won
- Wait 30 minutes
- Send SMS: "Hi Maria, how did Mike do today?"
- Wait 4 hours
- BRANCH:
- IF customer replied → end workflow (human or AI handles thread)
- ELSE → continue
- Send email: Review request email
- Wait 48 hours
- BRANCH:
- IF review posted OR customer replied → end workflow
- ELSE → continue
- Send SMS: Final follow-up
- End workflow
The branches prevent the workflow from spamming customers who already engaged. Each step has a clear continuation criteria.
Time delays: the underrated lever
The right time delay between steps is often more important than the copy. Examples that work:
- Review request first touch: 30 minutes after job (NOT immediately, NOT next day)
- Maintenance plan offer: 14 days after job (NOT 1 day, NOT 90 days)
- 30-day winback: exactly 30 days after Closed Lost (NOT 7, NOT 60)
- Day-before reminder: 24 hours before appointment (NOT 1 hour, NOT 1 week)
- On-the-way SMS: when tech checks in en-route (NOT before, NOT after arrival)
HonorElevate's defaults are tuned based on industry-specific testing. Owners can adjust, but the defaults are evidence-based.
Goal completion: knowing when to stop
Most workflows are not infinite loops. Each has a goal. When the goal is achieved, the workflow exits.
- Review request workflow goal: Customer posts a review OR opts out.
- Stale quote follow-up goal: Customer books OR declines OR enters DNC.
- 30-day winback goal: Customer re-engages OR explicitly opts out.
- Maintenance plan offer goal: Customer signs up OR declines OR opts out of marketing.
Goal completion exits the workflow gracefully. The contact is not stuck in a perpetual loop sending SMS forever.
Want custom workflows for your specific business?
Free 30-minute AI audit. We map your operational patterns, identify what would benefit from custom workflows, and build them during onboarding.
Book My Free AI AuditPersonalization tokens: dynamic data in messages
Every SMS, email, and message in a workflow can include dynamic personalization tokens. The system resolves these at send time based on the specific contact and context.
Common tokens:
- {{contact.first_name}} – Maria
- {{contact.last_name}} – Hernandez
- {{contact.service_area}} – Saugus
- {{contact.last_service_date}} – 2026-05-16
- {{contact.last_tech_name}} – Mike Sanchez
- {{appointment.date}} – tomorrow at 7 AM
- {{appointment.tech}} – Mike
- {{business.name}} – Smith Heating and Air
The discipline: only use tokens for verified data. If a token can resolve to garbage (because the field is empty), use conditional copy: "Hi {{contact.first_name|there}}" falls back to "there" if the first name is missing.
Common workflow patterns
Pattern 1: Linear sequence
Trigger → Action → Wait → Action → End. Used for nurture sequences and follow-up cadences.
Pattern 2: Wait-and-branch
Trigger → Wait → Branch on response → Different paths. Used when customer behavior determines the next step.
Pattern 3: Goal-completion loop
Trigger → Send → Wait → Check goal → Loop or end. Used when escalating until the customer responds.
Pattern 4: Conditional fork at start
Trigger → Evaluate conditions → Route to specific sub-workflow. Used for handling different customer segments with the same starting event.
Pattern 5: Multi-workflow chain
One workflow ends by triggering another. Used for complex multi-stage customer journeys (e.g., new customer onboarding → first-job follow-up → maintenance plan enrollment).
The honest disclosure on what powers this
The HonorElevate workflow engine sits on a white-labeled deployment of an enterprise-grade automation platform. The trigger types, condition operators, and action types described above are the platform's native capabilities. The 25+ pre-built workflows that ship with HonorElevate are my configurations using these primitives. Same as the pillar (guide here) notes for the rest of the platform.
The bottom line
Workflow architecture is the same across HonorElevate's 25+ defaults: trigger + condition + action. The combinations let one platform handle missed call recovery, review requests, stale-quote follow-up, maintenance plan offers, winback sequences, and any other process a service business can describe.
Most owners do not need to build their own workflows. Understanding the architecture matters mainly for two cases: customizing a default workflow for your specific needs, or designing a new workflow for an operational pattern unique to your business. Either way, the language is the same.
For the pillar, read The Complete Guide to Automation and Workflows. For the top 10 workflows ready to run, read The 10 Highest-ROI Workflows. For a real workflow firing in production, read Inside a HonorElevate Workflow That Books Jobs While You Sleep.