As documentation writers, we usually spend hours going through long help documents, reading, extracting key points, identifying possible confusion, and manually structuring FAQs that are clear and practical. It becomes even harder when we try to think about edge cases, limitations, and real-world scenarios that are not directly stated.
Sometimes we understand how a feature works, but converting that into user-focused questions takes effort. We have to think like a beginner, an admin, and an advanced user—all at the same time.
With the FAQ Generator agent, this becomes much simpler. You submit the help document and it generates structured, meaningful FAQs by analyzing the feature, surfacing limitations and edge cases, and explaining system behavior clearly. It doesn't just summarize; it anticipates user questions.
Since it strictly uses the submitted document as the source of truth, it also ensures accuracy, consistency, and data privacy.
Agent Overview
What the agent does
- Acts as an intelligent FAQ writing assistant that studies your help document and understands the feature before generating anything.
- Identifies key functionality, limitations, edge cases, and user pain points embedded in the content.
- Transforms the document into structured, user-focused FAQs that feel natural and support-ready.
- Writes clear, detailed answers with practical examples while avoiding repetition or marketing fluff.
- Allows refinements and adjustments to tone, depth, and structure to match your documentation style.
How the agent works
When you ask the agent a question about your data, the agent
- Interprets your request - Figures out what metric you want (count, sum, average, etc.) and any filters you need (by country, date, product, etc.)
- Access your spreadsheet - Retrieves the relevant data from your Zoho Sheet
- Apply the right operations - Filters the data based on your conditions and perform the calculations you need
- Give you clear results - Provides the answer along with a brief explanation of what I found
Implementation Guide
Test checklist
- resource_id: Available in the spreadsheet's URL path
- You may treat the optional parameter worksheet name as a constant and input its value.
Agent Instructions
The content below is the set of instructions for the agent:
You generate deep, structured, and critically reasoned FAQs derived from a given help document.
Your goal is not to re-state the document; your goal is to anticipate the user's questions.
The FAQs must cover all possible user thought patterns, address beginner to advanced users, include limitations, edge cases, integrations, dependencies, and examples, avoid repetition, avoid fluff, and provide complete yet clear answers.
The output must feel like it was written by a highly paid product documentation expert.
Before generating FAQs, analyze the help document and identify:
What problem does this feature solve?
Who is it for?
Where does it sit in the workflow?
What are its dependencies?
What configurations are required?
What are its limitations?
What other features interact with it?
What could go wrong?
Do not write FAQs until this internal analysis is complete.
FAQ structure requirement
Foundational understanding (conceptual clarity)
Example question types:
What is [Feature Name]?
How is this different from [similar feature]?
Why would a team enable this?
How do I set up [Feature Name]?
Answers must be clear, include practical examples, avoid vague benefits like “improves efficiency” and explain real impact.
How it works (functional understanding)
How does it function?
What happens behind the scenes?
What triggers it?
What conditions affect it?
Example question types:
How does [Feature Name] work?
What triggers this feature?
Does it work in real-time?
What data does it use?
Does it apply to existing records or only new ones?
Answers must explain logic flow, clarify automation behavior, explain system conditions, and include scenario-based examples.
How-to
How to configure
How to enable
How to disable
How to modify
Example question types:
How do I enable this feature?
Can it be edited after activation?
Can I apply it to specific departments?
Can it be restricted by role?
Answers must avoid duplicating the help doc step-by-step and instead summarize logically, clarify decision points, and mention prerequisites.
Limits and constraints
This section is CRITICAL.
Every feature has limits. Users may ask: How many can I create? Is there a maximum? Is it plan-dependent? Does it work across all modules? Does it support all field types? Does it work on mobile? Does it work via API?
You must explicitly surface: quantitative limits, plan restrictions, unsupported cases, and behavioral edge cases
Example:
How many rules can be configured?
Can this be used across departments?
Does it work with custom modules?
What happens if conditions conflict?
Answers must be precise and realistic.
Integrations and cross-feature interactions
Users think beyond one feature.
Include questions like: How does this work with automation rules? Can it be combined with assignment rules? Does it affect reporting? Does it impact SLAs? Does it reflect in analytics? Can it trigger workflows?
Answers must connect the feature to ecosystem context to explain interaction logic and clarify hierarchy/priority.
Edge and hypothetical cases
This is what separates average documentation from elite documentation.
Ask:
What happens if a ticket is moved?
What if the field is deleted?
What if permissions change?
What if the rule conflicts?
What if configuration is incomplete?
Answers must explain system behavior, clarify fallback logic, and address confusion points
Administrative and governance questions
Admins think differently.
Include:
Who can configure this?
Is this logged in audit logs?
Can it be tracked?
Can it be exported?
Is it reversible?
Does it affect compliance?
Performance and data behavior
Users worry about:
Does this affect performance?
Does it slow down ticket processing?
Is it applied retroactively?
Is data recalculated?
Writing standards
1. No shallow answers
Avoid answers like: This feature helps improve productivity.
Instead write: This feature reduces manual reassignment by automatically routing tickets based on predefined conditions, which helps prevent SLA breaches during peak volumes.
2. Use realistic examples
Every two to three answers should include examples.
Example: For instance, if a ticket contains the keyword “refund” and the customer belongs to the EU region, the rule can automatically assign it to the EU Billing queue.
3. Anticipate confusion
Clarify things users won't ask clearly but will think:
Does this override manual actions?
Does it respect profile permissions?
What takes priority?
4. Do NOT:
Repeat the help document line by line.
Write marketing fluff.
Make vague statements.
Length requirement
The FAQ must be comprehensive, not artificially limited, and cover all realistic user concerns.
This is not a short FAQ. The length of the FAQ needs to be justifiable. Do not number the questions.
Use the following format to re-state FAQs and their answers:
Question
Answer
Input
You can now give the agent any piece of information from which the FAQs has to be framed from. Here is a sample input.
"Workflow rules are a powerful automation tool for support teams, but they are limited when actions need to be triggered based on time. This is where time-based automation rules, also known as supervisor rules, become essential. Executing a workflow rule immediately after a condition is met may not always be effective, especially when follow-ups or escalations depend on elapsed time. Time-based rules are similar to workflow rules where predefined actions such as triggering alerts, creating tasks, and updating fields are carried out by the system whenever the said condition is satisfied. The key difference is in when the action takes place. Unlike workflow rules, which execute instantly when a ticket is created or updated, time-based rules are triggered only when a specified time condition is met. Here are some ways to use time-based rules: Notify agents when their tickets stay unresolved for x hours. Notify Queue Managers when tickets remain unassigned for x hours. Notify agents x hours after they've received a new response. Notify and assign re-opened tickets after x hours of receiving them. Notify Support Managers when agents reassign their tickets. Notify Support Managers of the approximate number of hours it took for agents to respond since assignment. Permission Required Users with the Support Administrator permission profile can access this feature. Time-based rules are triggered when a timed event occurs.
Zoho Desk provides the following time-based condition for tickets:
Hours since status updated
Hours since closed
Hours since re-opened
Hours since assigned
Hours since first assigned
Hours since requestor responded
Hours since agent responded
Hours since due date
Hours to due date
Hours since modified
Hours since created
Hours since first response pending
Hours since agent response pending
Hours since requestor response pending
Points to remember:
Time-based rules run automatically once every hour.
During each run, the system checks only those tickets that have received a customer response within the last 30 days.
Tickets without a recent customer reply are ignored by these rules.
The time value in the time-based conditions must always be a whole number.
Decimal values, such as 1.5 or 0.5 are not read by the system.
While creating the rule, users can compare the time value using three options: is less than, is greater than, and is equal to. These options determine which tickets match the rule based on how much time has passed since an event, such as ticket creation.
The system evaluates time-based rules in one-hour intervals, not by exact minutes.
To understand how this works, assume the current time is 08:00 AM and the rule is being evaluated at that moment. If the condition is hours since created <is greater than 2> - the rule will apply to tickets that were created before 06:00 AM. This is because those tickets are older than two hours at the time of the check. If the condition is hours since created <is less than 2> - the rule will apply to tickets that were created between 06:00 AM and 08:00 AM. These tickets are less than two hours old when the rule runs. If the condition is hours since created <is 2> - the rule will apply to tickets that fall into the two-hour window during the hourly check. In practice, this means tickets created between 05:00 AM and 06:00 AM will match when the rule runs at 08:00 AM. Creating time-based rules Time-based rules are used to automate actions based on how much time has passed on a ticket. These rules support only three types of actions: alerts, tasks, and field updates.
Note: Time-based rules are applicable only for the Tickets module. Administrator can create a maximum of 5 rules/15 rules/30 rules per department in the Standard, Professional, and Enterprise editions, respectively. Administrator can associate each rule with up to three time-based actions (1 alert, 1 task & 1 field update).
To create a time-based rule
Navigate to Setup > Automation > Supervisor Rules.
Select the Department. Click Create Rule.
In the Time-based action page, enter the Rule Name and Description.
Mark the rule Active.
Select the Business hours or Calendar hours during which this rule will apply. Click Next.
Under Criteria, click Select field and select a time-based criteria from the available options.
Under Action, click + to add actions to be performed when the time-based action is executed.
To create an alert Provide a Name and Description.
Select an Email template or Create an email template.
Choose who to send the email alert to: team/role/role and subordinate/agents.
Under Also Notify, the email can be sent to the record owner/record creator/notify contact/additional recipients as well.
Click Save.
To update the field value Provide the assignment value Name and Description.
Under Assignment Value, select the Fields that need to be updated.
Provide the Value that needs to be changed.
To set up a task Enter the Task subject.
Choose the Task's status. Set the Task priority.
Check ticket owner, if they should also be assigned as the task owner.
Select an agent who needs to be assigned to this task. Set the Due date for the task from the Supervisor Rules trigger time by clicking the timer and time selector (minutes, hours, days, or months).
Provide a Description. Click Save.
To associate an existing action with a rule:
Click the Add icon and select Existing from the drop-down list for the required action type, such as alerts, tasks, or field updates.
In the Associate Existing Action page, choose the appropriate action and link it to the rule.
Click Save to save the overall Supervisor rule.
Deactivating time-based rules Administrators can activate or deactivate the time-based rules at any time.
When the rule has been deactivated, it will be removed from the Active Rule list.
All the scheduled actions will be terminated upon deactivation.
To deactivate time-based rules
Go to Setup >Automation > Supervise
In the Supervisor Rules List page, click the Deactivate icon for the corresponding rule.
You can activate the rules from the Inactive Rules List by clicking the Activate icon.
Alternatively, you can click the Schedulers toggle to activate or deactivate multiple rules at one go.
Deleting time-based rules
Time-based rules can be deleted when not in use. When you delete a rule, it will be permanently removed from your help desk and cannot be recovered. To delete time-based rules
Click on Setup > Automation > Supervisor Rules.
In the Supervisor Rules List page, click the Delete icon for the corresponding rule.
Click Ok to confirm."
Output
Foundational understanding (conceptual clarity)
What are time-based automation rules (supervisor rules) and how do they differ from standard workflow rules?
Time-based automation rules, or supervisor rules, trigger actions based on elapsed time rather than immediately when a condition is met. Unlike standard workflow rules that execute instantly upon ticket creation or update, time-based rules wait until a specified time condition (e.g., hours since last update) is satisfied before executing predefined actions such as alerts, tasks, or field updates. This allows support teams to automate follow-ups, escalations, or reminders that depend on how long a ticket has been in a particular state.
Who benefits the most from using time-based rules?
Support administrators and managers who need to monitor ticket aging, ensure timely responses, and automate escalations benefit most. For example, notifying agents if tickets remain unresolved for a set number of hours or alerting queue managers about unassigned tickets helps maintain service quality and accountability.
In what scenarios are time-based rules most useful?
They are ideal when actions depend on elapsed time rather than immediate events. For example, sending reminders if a ticket has been open for more than 24 hours, escalating tickets that remain unassigned for several hours, or creating tasks to follow up after a customer's response delay.
When might time-based rules not be appropriate?
If immediate action is required upon ticket creation or update, standard workflow rules are better suited. Also, if ticket activity is infrequent or outside the 30-day recent customer response window, time-based rules may not trigger as expected.
How it works (functional understanding)
How do time-based rules operate behind the scenes?
Time-based rules run automatically once every hour. During each run, the system evaluates tickets that have received a customer response within the last 30 days against the rule's time conditions. If a ticket meets the specified time criteria based on events like “hours since assigned” or “hours since agent responded,” the system triggers the associated actions (alerts, tasks, or field updates).
What time-based conditions can be used to trigger these rules?
The system supports conditions such as:
Hours since status updated
Hours since closed
Hours since re-opened
Hours since assigned
Hours since first assigned
Hours since requestor responded
Hours since agent responded
Hours since due date
Hours to due date
Hours since modified
Hours since created
Hours since first response pending
Hours since agent response pending
Hours since requestor response pending
How does the system evaluate time values in these conditions?
Time values must be whole numbers; decimals are not supported. The system checks tickets in one-hour intervals. For example, if the current time is 08:00 AM and the condition is “hours since created is greater than 2,” tickets created before 06:00 AM will match. This hourly evaluation means exact minutes are not considered.
Do time-based rules apply to all tickets or only specific ones?
Only tickets with a customer response in the last 30 days are evaluated. Tickets without recent customer replies are excluded to ensure the system focuses on active or recently active tickets.
How-to and operational questions
How do I create a time-based rule?
Navigate to Setup > Automation > Supervisor Rules, select the department, and click Create Rule. Define the rule name, description, and activate it. Choose business or calendar hours for the rule's applicability, set the time-based criteria, and add up to three actions (one alert, one task, one field update). Finally, save the rule.
Can I modify a time-based rule after it's created?
Yes, administrators with the Support Administrator profile can edit rules, including their criteria and associated actions, as long as the rule is active or inactive but not deleted.
Can I restrict time-based rules to specific departments or roles?
Yes, rules are created within specific departments to allow for targeted automation. Alerts can be sent to specific teams, roles, or agents, providing granular control over notifications.
How do I deactivate or reactivate time-based rules?
From Setup > Automation > Supervisor Rules, use the Deactivate icon to disable a rule, which stops all scheduled actions immediately. Reactivate from the Inactive Rules List or use the Schedulers toggle to manage multiple rules simultaneously.
Can I delete a time-based rule?
Yes, deletion permanently removes the rule and its scheduled actions from the system. This action cannot be undone.
Limits and constraints
How many time-based rules can I create?
Limits depend on your edition and department:
Standard Edition: up to 5 rules per department
Professional Edition: up to 15 rules per department
Enterprise Edition: up to 30 rules per department
How many actions can be associated with a single time-based rule?
Each rule can have up to three time-based actions: one alert, one task, and one field update.
Do time-based rules work on modules other than Tickets?
No, time-based rules apply exclusively to the Tickets module.
Are decimal time values supported in conditions?
No, time values must be whole numbers. The system ignores decimal values such as 1.5 or 0.5 hours.
What happens if multiple time-based rules apply to the same ticket?
All matching rules execute their respective actions independently. There is no built-in priority or conflict resolution; administrators should design rules to avoid contradictory actions.
Do time-based rules run in real time?
No, they run in hourly intervals, so actions may trigger up to an hour after the condition is met.
Are tickets without recent customer responses evaluated?
No, only tickets with customer responses within the last 30 days are considered.
Integrations and cross-feature interactions
Can time-based rules trigger other automations like workflow rules or assignment rules?
Time-based rules operate independently but can complement other automations. For example, a time-based alert can notify agents about tickets that workflow rules have assigned. However, time-based rules do not directly trigger workflow or assignment rules.
Do time-based rule actions affect SLA calculations or reporting?
Indirectly, yes. For instance, alerts about delayed responses can prompt agents to act faster, which affects SLA adherence. However, time-based rules themselves do not modify SLA timers or reporting data directly.
Can time-based rules trigger workflows or other downstream automations?
Actions like field updates from time-based rules may trigger workflow rules if those workflows are configured to respond to field changes, enabling chained automation.
Edge and hypothetical cases
What happens if a ticket is moved to a different department?
Time-based rules are department-specific. If a ticket moves departments, it will no longer be evaluated by the original department's rules and may be evaluated by the new department's rules, if applicable.
What if a field used in a time-based rule action is deleted or renamed?
The associated action may fail or not execute correctly. Administrators should verify and update rules after modifying fields to ensure continued functionality.
What if permissions for the Support Administrator change?
Users who lose the Support Administrator profile will no longer be able to create, modify, or delete time-based rules. Existing rules remain active unless deactivated by an administrator.
What if a time-based rule condition conflicts with manual ticket actions?
Manual updates can override automated actions, but time-based rules will continue to evaluate tickets based on their conditions. For example, if a ticket is manually reassigned before the rule triggers, the rule may no longer match the original condition.
What occurs if a time-based rule is deactivated while actions are scheduled?
All pending scheduled actions for that rule are immediately terminated and will not execute.
Administrative and governance
Who can create and manage time-based rules?
Only users with the Support Administrator permission profile can create, edit, activate/deactivate, or delete time-based rules.
Are changes to time-based rules logged or auditable?
While not explicitly stated, typical administrator actions like rule creation and modification are generally tracked in audit logs for compliance and governance.
Can time-based rules be exported or backed up?
There is no direct export feature for time-based rules; administrators should document configurations externally if needed.
Are time-based rulesreversible?
Rules can be deactivated or deleted. Deactivating stops future actions but preserves the rule for later reactivation. Deletion is permanent and irreversible.
Do time-based rules impact compliance requirements?
By automating timely responses and escalations, time-based rules can help meet compliance SLAs and audit requirements, but administrators must ensure rules align with organizational policies.
Performance and data behavior
Do time-based rules affect system performance or ticket processing speed?
Time-based rules run hourly and process only tickets with recent customer responses, minimizing performance impact. They do not slow down real-time ticket updates or immediate workflows.
Are time-based rules applied retroactively to old tickets?
No, only tickets with customer responses within the last 30 days are evaluated. Older tickets are excluded.
Is data recalculated when a time-based rule triggers a field update?
Field updates via time-based rules change ticket data, which may trigger recalculations or downstream automations depending on system setup.
Can time-based rules be triggered via API?
Time-based rules are system-scheduled automations and cannot be triggered directly through API calls.