Overview
Each workflow is composed of two primary elements:
- When to Use statement: Defines when a workflow is eligible to run
- Response Template: Defines what content is generated and how it is written
This guide focuses on writing effective When to Use statements and choosing the correct execution mode.
Scope and Intended Use
Stylo’s classification and response models are optimized for external, customer-facing communications. Incoming customer messages are evaluated to determine intent and select the most appropriate workflow.
Supported Use Cases
| Use case | Recommended mode | Notes |
|---|---|---|
| Automated customer replies | public | Fully automated; response is sent directly to the customer |
| Draft responses for review | copilot | Pre-generated; agent reviews before sending |
| Internal agent notes | internal | Posted as internal comments only |
| On-demand execution | manual | Invoked explicitly via Stylo Assist |
Guidance for Internal Workflows
For internal use cases such as:
- Escalation summaries
- Ticket triage notes
- Internal routing recommendations
- Agent decision support
Use internal or copilot mode so outputs are reviewed by agents and never sent directly to customers.
Alternatively, set the workflow to manual and invoke it manually via Stylo Assist when needed.
When to Use Statements
The When to Use statement determines whether a workflow is eligible to run for a given ticket. It is evaluated against the full conversation history using Stylo’s LLM-based classification system.
How Eligibility Is Evaluated
The classifier looks for specific, recognized keyword patterns. To ensure reliable matching, structure rules using the phrases below.
Note: Stylo's classification system is trained on English, for best results write your "When to Use" in English.
Trigger Conditions
At least one trigger must match for the workflow to be considered.
| Pattern | Example |
|---|---|
Use when... | Use when customer asks about order status. |
Apply when... | Apply when customer requests a refund. |
Fires when... | Fires when customer mentions a shipping delay. |
Invoke when... | Invoke when customer provides an order number. |
Compound triggers using and require all parts to be true:
Fires when customer mentions a refund and the order is more than 30 days old.
Required Conditions
All required conditions must be satisfied.
| Pattern | Example |
|---|---|
Only if... | Only if the ticket contains an order number. |
Only when... | Only when the customer is a verified account holder. |
Must... | Must have shipping information available. |
Blocking Conditions
If any blocking condition matches, the workflow is excluded.
| Pattern | Example |
|---|---|
Do not use... | Do not use for damaged item reports. |
Don't use... | Don’t use when customer mentions an attorney. |
Never... | Never use for tickets tagged as VIP. |
Exclude... | Exclude tickets with open disputes. |
Not for... | Not for warranty claims. |
Evaluation Order
- Blocking conditions - Any match immediately excludes the workflow
- Required conditions - All must be true
- Trigger conditions - At least one must match
The system is intentionally conservative:
if a match feels vague or forced, it is treated as a non-match.
Writing Effective When to Use Statements
Core Principles
- Focus on customer intent, not keywords alone
- Use recognized keyword patterns
- Always include blocking conditions
- Account for conversation stage, not just the first message
Strong Example
Use when customer asks about order delivery status. Fires when customer mentions tracking, shipping, or “where is my order.” Fires when customer asks when their package will arrive. Only if the ticket contains a valid order number or the customer email is verified. Only when the most recent message is from the customer. Do not use when customer reports a damaged or missing item. Do not use when customer requests a refund or cancellation. Do not use if tracking information was already provided earlier. Never use for tickets tagged as escalated or fraud-review. Not for product quality complaints.
Why this works
- Captures multiple expressions of the same intent
- Ensures required context exists
- Prevents overlap with adjacent workflows
- Accounts for prior responses in the conversation
Weak Example
Handle order questions. Respond to customers asking about shipping. Be helpful and professional.
Why this fails
- No recognized trigger patterns
- Overly broad intent
- No blocking conditions
- Mixes eligibility with response behavior
Execution Modes
Each workflow has a background execution mode that controls automation behavior.
manual
- Never runs automatically
- Available only via manual invocation in Stylo Assist
- Best for: Sensitive, complex, or judgment-based workflows
copilot
- Generates a response when matched
- Cached for 24 hours and surfaced in Stylo Assist
- Agent reviews, edits, or discards
- Best for: High-volume scenarios requiring human review
internal
- Automatically posts output as an internal note
- Never visible to customers
- Best for: Escalations, triage notes, internal guidance
public
- Automatically sends response to the customer
- Includes quality assurance validation
- Best for: High-confidence, well-tested workflows
Choosing the Right Mode
| Scenario | Mode |
|---|---|
| New or untested workflow | copilot or manual |
| High-confidence automation | public |
| Internal agent content | internal |
| Sensitive or ambiguous cases | manual |
| Predictable, high-volume requests | public (after validation) |
Structured Conditions vs. When to Use
Stylo supports two layers of filtering:
Structured Conditions
Deterministic rules based on ticket conditions:
- Status
- Channel
- Tags
- Custom fields
- Assignee or group
Evaluated first; no LLM involved.
When to Use Statement
Natural language, intent-based matching:
- Customer intent
- Conversation context
- Semantic meaning
Best practice:
Use structured conditions for hard constraints and When to Use for intent detection.
Quality Assurance for Public Workflows
Workflows in public mode undergo additional validation:
- Does the response match the intended use case?
- Is it appropriate given conversation history?
- Does it fully address the latest message?
- Is it redundant with prior responses?
- Is the language correct?
If validation fails, the system may retry once. If it fails again, the response is not sent.
Common Mistakes to Avoid
Missing trigger patterns
❌ Handle refund requests ✅ Use when customer requests a refund.
Overly broad intent
❌ Fires when customer has a question. ✅ Fires when customer asks about return shipping labels.
No blocking rules
❌ Use when customer mentions order. ✅ Use when customer mentions order. Do not use for fraud or chargeback claims.
Mixing eligibility and response logic
❌ Use when customer asks about shipping. Be friendly and include tracking. ✅ When to Use: Use when customer asks about shipping status. Do not use for lost package reports.
Ignoring conversation stage
❌ Fires when order number is mentioned. ✅ Fires when customer asks about order status. Do not use if tracking was already shared.
Deployment Checklist
Before enabling automation:
- Triggers defined using supported patterns
- Required conditions included where needed
- Blocking conditions clearly stated
- Execution mode appropriate for risk level
- Overlap with other workflows avoided
- Tested against real tickets
Summary
| Component | Purpose |
|---|---|
| When to Use | Determines eligibility |
| Structured Conditions | Hard, deterministic filters |
| Execution Mode | Controls automation level |
| Response Template | Defines generated output |
For help configuring or validating workflows, contact your Stylo implementation team.
Comments
0 comments
Please sign in to leave a comment.