1. Introduction
In Professional Services Automation (PSA) systems, accurately classifying customer support tickets by priority is essential for ensuring timely service response and maintaining customer satisfaction. The system typically provides a predefined list of priority options—such as “Priority 1 - Emergency Response” or “Priority 4 - Normal Response.” To help frontline support staff, customers, or automated systems select the correct priority, we need to create clear, structured, and actionable custom instructions.
This guide is designed to help you manually write priority classification instructions that comply with established standards. These instructions will be used directly in PSA system interfaces, knowledge base articles, or AI prompt templates to help users quickly understand when each priority level applies.
I will use priority for example in this guilde.
2. Official Priority Candidate List (Strictly Enforced)
Before writing any instructions, confirm that you use exact matches from the following official priority list. Do not add, remove, abbreviate, reword, or merge any names:
- Priority 5 - Routine Response
- Priority 4Q - Quick Fix
- Please Change
- Priority 1 - Emergency Response
- Priority 2 - Critical Response
- VIP
- Priority 3 - Elevated Response
- Priority 4 - Normal Response
✅ Correct: Priority 1 - Emergency Response
❌ Incorrect: P1 Emergency, Priority One, Emergency (P1)
Any deviation from the official naming may cause system misclassification, automation failures, or inconsistent user behavior.
3. Instruction Structure Requirements
Each priority instruction must follow a uniform Markdown block format containing four required elements:
{Priority Name} Use when: [concise condition] |
3.1 "{Priority Name}" Header Line
- Must be copied verbatim from the official candidate list.
- Do not bold, number, or add extra punctuation.
- Standalone on its own line, with no extra blank lines before or after (except between multiple instruction blocks).
3.2 “Use when:” Condition Statement
- Keep it concise, specific, and objectively verifiable.
- Focus on business impact, system state, or customer role—not technical implementation details.
- Use active voice and avoid vague terms like “might,” “sometimes,” or “generally.”
✅ Good example:
Use when: Your entire production system is down and revenue is impacted.
❌ Poor example:
Use when: Something might be wrong with the system.
3.3 “Examples:” Section
- Provide 1–3 realistic or typical scenarios to help users self-diagnose.
- Examples should come from historical tickets, user feedback, or documented business rules.
- End each example with a period; separate multiple examples with commas (in English contexts).
✅ Good example:
Examples: All users cannot log in, payment processing has stopped, critical API is returning 500 errors.
❌ Poor example:
Examples: System is slow, maybe broken.
3.4 Closing Sentence
- Always use the fixed phrase: Select this if your issue matches the above criteria.
- Do not modify, omit, or translate this sentence.
- This reinforces user decision-making and discourages random selection.
4. Writing Principles & Best Practices
4.1 Only Write for Priorities Mentioned by the User
Do not write instructions for every possible priority. Only create blocks for priorities explicitly referenced in the current context or user input. For example, if a user only mentions “emergency” and “VIP,” write instructions only for Priority 1 - Emergency Response and VIP.
📌 Reason: Prevents information overload and keeps guidance tightly aligned with the user’s actual scenario.
4.2 Faithfully Preserve Original User Conditions and Examples
If the user provides their own rationale or examples (e.g., “This should be Priority 2 because the database primary node is down”), quote or paraphrase directly—do not “clean up” or over-generalize.
✅ Correct:
Use when: Database primary node is down.
Examples: PostgreSQL primary instance unreachable, MySQL master-slave sync broken with master offline.
❌ Incorrect:
Use when: Critical infrastructure failure. (Too abstract; loses original context)
4.3 Avoid Subjective Judgment or Assumptions
Base instructions on observable facts or explicit business rules, not personal opinion or emotion.
❌ Avoid:
Use when: You think it’s really bad.
Use when: The client is angry.
✅ Instead:
Use when: SLA requires response within 15 minutes.
Use when: Customer is a contracted VIP account.
4.4 Clearly Differentiate Similar Priorities
Some priorities are easily confused (e.g., Priority 1 vs. Priority 2, or Priority 4 vs. Priority 4Q). Use contrastive descriptions to highlight key distinctions.
| Priority | Key Differentiator |
| Priority 1 | Full business outage with direct financial, safety, or compliance impact |
| Priority 2 | Core functionality unavailable, but a temporary workaround exists |
| Priority 4Q | Minor issue with a very fast fix (<1 hour), requiring no deep investigation |
| Priority 4 | Standard issue handled through normal support workflows |
Example contrast:
Priority 1 - Emergency Response Use when: Complete business outage with financial or legal impact. Priority 2 - Critical Response Use when: Major functionality broken, but partial workaround exists. |
5. Full Writing Example
Suppose a user submits the following description:
“Our CEO can’t log into the system, and today is quarterly earnings day. This should be VIP or Priority 1. A similar incident last year was classified as Priority 1.”
Based on this input, you would manually write:
VIP Use when: The requester is a designated VIP user (e.g., C-level executive) and the issue impacts their ability to perform critical duties. Priority 1 - Emergency Response Use when: Complete access loss for a VIP user during a business-critical event with revenue or compliance implications. |
🔍 Analysis: Only includes the two priorities mentioned: VIP and Priority 1 “Use when” integrates key facts from the user (CEO, earnings day)“Examples” blends the user’s historical reference with the current scenario. No extra priorities (e.g., Priority 2) are added.
6. Common Mistakes and How to Avoid Them
| Mistake Type | Bad Example | Correct Approach |
| Inconsistent naming | “P1 - Emergency” | Use exact name: “Priority 1 - Emergency Response” |
| Extra content | Starts with “Here are the instructions:” | Output only the instruction blocks—no intro or outro |
| Inventing new priorities | Adds “Priority 0 - Catastrophic” | Use only options from the official list |
| Vague examples | “System is broken.” | “User authentication fails for all employees.” |
| Ambiguous conditions | “When it’s urgent.” | “When SLA mandates <30 min response.” |
7. Output Format Requirements (for System Integration)
When your writing is complete, the final output must consist only of Markdown blocks in this format:
{Priority Name} Use when: ... {Another Priority Name} Use when: ... |
- Separate blocks with one blank line
- No numbering, headings, or explanatory text
- Plain text only—ready to paste directly into system prompts or knowledge bases
8. Conclusion
Writing high-quality priority classification instructions hinges on accuracy, consistency, and user-centered clarity. By following the structure and principles in this guide, you ensure that:
- Support staff can classify tickets correctly and quickly
- Customers can self-serve with confidence
- AI/automation systems (e.g., LLM classifiers) can reliably parse and act on the instructions
- The system remains extensible for future priority additions or field expansions
Remember: Great instructions aren’t about sounding polished—they’re about being understood. Stay grounded in real user scenarios, preserve original intent, and prioritize clarity over cleverness.