Fine tuning

Mizo’s AI-powered automation can be fine-tuned to match your organization’s specific workflows, priorities, and business logic. This guide provides comprehensive instructions for configuring the AI behavior through the Fine-Tuning tab in the Mizo console.

How Fine-Tuning Works

Fine-tuning is how you change what Mizo decides without touching any code. The Fine-Tuning section of the console is organized into five pages — Intake, Triage, Dispatch, Resolution, and Communication — each covering a different stage of how a ticket is processed. On most of these pages, you write plain-English rules into a text box: for example, “never change the category on tickets from the Acme board” or “always route VPN issues to the Network team.”

Under the hood, that text is inserted directly into the instructions Mizo’s AI reads right before it makes the matching decision — picking a category, picking a technician, writing a title, and so on. The AI weighs your rule alongside everything else it sees (the ticket content, your PSA data, its own general instructions) and produces a judgment call. Two things follow from that:

• A rule influences a decision — it doesn’t guarantee an outcome the way a PSA workflow rule would. A clear, specific rule is followed in the large majority of cases, but it’s competing for attention with everything else Mizo is shown, rather than executing as code.
• A rule can only be as good as the information Mizo can see for that decision. If a rule references a field or a system Mizo doesn’t read at that step, it won’t produce an error — it will simply have no effect.

Rules are evaluated even for features set to “Recommendation,” where a technician has to approve the suggestion before anything reaches the PSA. Only the write-back to the PSA is gated by the automation level — the underlying decision still runs and can be shaped by your rules. Use the Test Rules tool (see below) to confirm what a rule actually produced, rather than relying only on what shows up in the PSA.

On the Intake and Triage pages only, an AI drafting assistant called “Train Mizo with your flow” can interview a customer about how they want a given decision handled and draft rule text for them to review before saving. It’s a drafting aid, not a separate behavior — it only ever produces text for the same rule box, and someone still has to read it and save it before it takes effect.

Key Principles:

• Fine-tuning rules are applied as additional instructions to the AI

• Rules are processed in the order they appear

• More specific rules should be placed before general rules

• Rules can enable, disable, or modify AI behavior for specific scenarios

Rule Structure and Priority

Each fine-tuning rule consists of:

1. Condition: The criteria that triggers the rule (e.g., ticket title pattern, content keywords, company name)
2. Action: What the AI should do when the condition is met (e.g., select a specific value, skip a step, apply a pattern)
3. Context: Additional information to help the AI make better decisions (e.g., definitions, exceptions, examples)

Rule Priority

• Rules are evaluated in the order they are written
• Earlier rules take precedence over later ones
• Use this to create fallback logic (specific cases first, general cases last)

Writing Effective Rules

Good Rule:

If the ticket title contains “Printer” or “Print”, categorize it as “Hardware / Printers”.

Poor Rule:

Sometimes tickets about printers should go to hardware. Why? The good rule is specific, actionable, and unambiguous. The poor rule is vague and leaves too much to interpretation.

Using @Mentions, /Macros, and Location Overrides

Every rule box in Fine-Tuning is a smart editor that recognizes two special elements:

• @mentions (e.g. @ticket.title) are an authoring aid, not live data. Typing one does not insert real ticket information — the literal text you typed is what reaches the AI. Its purpose is to keep your rule anchored to something Mizo can actually see for that decision; the suggestion list that appears after typing @ is exactly the set of fields available at that step.
• /macros (e.g. /Important, /DoNotUpdate) are genuinely expanded before your rule is used. /Important adds emphasis to the text that follows; /DoNotUpdate becomes a fixed instruction telling Mizo to leave that field unchanged. Which macros are available depends on the field — /Important is available everywhere.

Most rule fields on the Intake and Triage pages (and the text fields on Dispatch) come with an @mention suggestion list. A few fields — everything on the Resolution and Communication pages, the pre-assistance-questions rule, and the on/off Dispatch toggles — don’t have one. Rule text still reaches the AI there, but nothing validates it against what Mizo can see, so double-check those rules carefully and lean on Test Rules below.

Some fields also support a location-specific override for tenants split across multiple locations. A rule is tenant-wide by default; an override lets you set different behavior for one location. If you create an override and leave it blank, it silently suppresses the tenant-wide rule for that location — so an empty-looking override is a common cause of “the rule works everywhere except this one client.”

Testing Your Rules

Before trusting a new or edited rule in production, validate it with the Test Rules tool against the ticket that prompted the change, and against a couple of tickets it should not affect. Only saved rules are included in a test run — unsaved edits in the box are ignored, so save first. Test Rules previews the outcome without writing anything to your PSA.

If a rule doesn’t seem to be working, walk through this checklist before assuming it’s wrong:

1. Is the underlying feature itself turned on for this client or board?
2. Does the rule reference a field or @mention Mizo can actually see for that decision? An inline warning while typing is a strong hint it can’t.
3. Is there an empty location override quietly cancelling the tenant-wide rule?
4. Does another rule on the same or a neighboring field already say something different?

Fine-Tuning vs. Memories

Fine-tuning and Memories are both configured from the same navigation menu, but they’re different features. Fine-tuning rules shape Mizo’s pipeline decisions — categorization, dispatch, titling, and so on. Memories are short facts Mizo learns from conversation that a technician approves or rejects, and they’re only used by Ticket Chat — they can’t explain or correct a wrong category, a wrong dispatch, or any other pipeline decision.

Troubleshooting

Saving a rule has almost no validation. There’s no error for saving a rule that references something Mizo can’t see, contradicts another rule, or won’t actually change anything — it saves successfully and simply has no effect afterward. That means “we wrote a rule and nothing changed” looks identical to “the rule saved and Mizo ignored it,” and there’s no message anywhere to tell the two apart.

Two narrower cases do surface something on screen, while you’re typing:

• Typing an @mention the field’s editor doesn’t recognize underlines it and shows an inline tooltip: ”@{segment} isn’t a suggested field, the AI assistant may not have this information” (or, for a mention under a recognized parent, ”@{parent} has no suggested field {segment}”). This is a warning shown while typing, not a save-time block — the rule saves as typed either way, and the unrecognized reference is just inert text to the model.
• Typing a /macro name that isn’t available for that field shows a similar inline warning: ”/{name} isn’t an available macro for this field.” It’s likewise not blocked from saving — it’s left in the rule as literal text (for example, a stray /Urgent) rather than being expanded.

Outside those two cases, expect silence: a badly written or ineffective rule produces no error message anywhere — not on the rule editor, not on the ticket, not on a dashboard. The only way to know whether a saved rule is doing what you intended is to check a ticket’s actual outcome, or run Test Rules. If a rule doesn’t seem to be working, walk through this checklist before assuming it’s wrong:

1. Is the underlying feature itself turned on for this client or board?
2. Does the rule reference a field or @mention Mizo can actually see for that decision? An inline warning while typing is a strong hint it can’t.
3. Is there an empty location override quietly cancelling the tenant-wide rule?
4. Does another rule on the same or a neighboring field already say something different?

Dependencies and Prerequisites

• Fine-tuning only shapes a decision Mizo is already making. Turning on a rule for a feature that’s itself switched off — its automation setting is Off, or the whole workflow step never runs for that ticket — has no effect, since there’s nothing for the rule to steer.
• A rule can’t make Mizo pick something the client’s PSA doesn’t have. It can only choose among categories, agreements, statuses, or employees that genuinely exist and were synced from the PSA — a rule referencing a category or technician the PSA doesn’t have won’t create one.
• A handful of fine-tuning fields aren’t free text at all: a company picker and an employee/team allow-list (used for enabling reattribution on specific companies, and for which technicians or teams are eligible for dispatch) are toggled on a list, never typed as a sentence.
• Two hard constraints apply no matter what a rule says: a dispatch note can never exceed roughly two sentences, and dispatch rules can never leave an eligible technician’s ticket unassigned. Rules that try to override these need a different approach — see Concrete Usage Examples below.
• The Test Rules dry-run tool is only available for tenants where it’s been enabled. Where it hasn’t, a customer’s only way to validate a rule is to watch it play out on real tickets.

Triage Fine-Tuning

Triage is where Mizo reads the ticket and sets the foundational data: the title, the category, the priority, and the contact attribution. Getting triage right has a compounding effect — every downstream step works from what triage produces.

1.Ticket Title Rules

Controls how Mizo renames tickets for clarity and consistency.

Disabling Renaming

Use Case: Preserve original titles for template tickets or specific patterns • If the ticket title starts with “Order #”, do not rename the ticket. • If the ticket title contains “URGENT:” at the beginning, do not rename the ticket. • If the ticket title is “Monthly Report Delivery”, set the updated title to “undefined”.

Custom Renaming Patterns

Use Case: Apply consistent naming conventions

• Rename tickets using this pattern: [{ClientName}] {UpdatedTicketTitle}
• For VIP clients (ACME Corp, Global Industries), use this pattern: [VIP] {UpdatedTicketTitle}
• If the ticket is from an end user (not an internal email), prepend the title with the end user’s name: {EndUserName} - {UpdatedTicketTitle}

Conditional Renaming

Use Case: Different rules for different ticket types

• If the ticket is about password reset, use the pattern: “Password Reset - {EndUserName} - {SystemName}”
• If the ticket mentions “down” or “outage”, prepend “OUTAGE:” to the title.
• For tickets about software requests, use: “Software Request: {SoftwareName} for {EndUserName}”

Advanced Example: 

Ticket Renaming Rules: 
 
1. Template Tickets (Preserve Original): 
   - If the title starts with “Send report -”, do not rename 
   - If the title starts with “Order #”, do not rename 
   - If the title is exactly “User Departure: {Name}”, do not rename 
 
2. Emergency/Outage Tickets: 
   - If the description contains “down”, “outage”, “offline”, or “not working” and affects multiple users, 
     use pattern: “[OUTAGE] {SystemName} - {Problem}” 
 
3. User Request Tickets: 
   - Use pattern: {EndUserName} - {RequestType} - {Summary} 
   - Example: “John Smith - Software Install - Adobe Acrobat” 
 
4. Default Renaming: 
   - Maximum 80 characters 

2. Ticket Urgency & Impact Rules 

Controls how Mizo sets priority levels (urgency and impact). 

Disabling Priority Setting 

Use Case: Preserve manually set priorities or skip for certain templates 

• If the ticket title contains “Monthly Report”, do not set urgency or impact. 

• If the ticket is created by the “Automation User”, do not modify urgency or impact. 

For tickets with “Template:” in the title, do not set urgency or impact. 

Setting Specific Priorities 

Use Case: Enforce priority levels for critical scenarios 

• If the ticket mentions “server down”, “complete outage”, or “network down”, set urgency to High and impact to Company-Wide. 

• If the ticket is about password reset, set urgency to Medium and impact to Single User. 

• If the client is “VIP Corp” and the ticket contains “urgent”, set urgency to High. \

Advanced Example: 

1. Priority Rules: 
 
. VIP Client Rules: 
   - Clients: ACME Corp, Global Industries, Premium Partners LLC 
   - Minimum urgency: Medium 
   - If they use “urgent” or “ASAP”, set urgency to High 
 
2. Template Tickets (Skip Priority): 
   - If title starts with “Scheduled -” or “Report -”, do not set priority 
   - These tickets have predefined SLAs 

3. Ticket Category Rules 

Controls how Mizo categorizes tickets into your service desk’s category structure. 

Category Selection Rules 

Use Case: Guide the AI to the correct category 

• If the ticket is about “Novipro”, categorize as “ERP”. 

Never select the “Archived” category or any of its subcategories. \

Dispatch Fine-Tuning 

4 - Catch-All Attribution Instructions

Attribution rules apply when tickets arrive through a generic mailbox and the AI needs to figure out which company and contact they belong to.

Attribution Rules: 

1. Internal Tickets: 
   - If sender email is from @ourcompany.com, it’s an internal ticket 
   - Do not update attribution for internal tickets 

5- Agreement Selection Rules

Agreement rules determine which billing agreement gets applied to a ticket in ConnectWise. This directly affects how time is logged and invoiced, so accuracy here has real financial consequences. Write a clear default first, then override it for exceptions.

Examples :

• By default, always use “Managed Service SH Agreement”

• If the request requires an on-site visit, use “On-Site Visit / Extra Hours” agreement

Dispatch Fine-Tuning

1. Team (Halo), Board (Connectwise), Queue (Autotask) Definitions 

Defines what each team handles and their expertise areas. 

Use Case: Help AI understand team responsibilities 

Team Definitions: 
 
Service Desk (Tier 1): 
- Handles: Password resets, basic how-to questions, initial triage 
- Skills: Windows basics, Office 365, Active Directory basics 
- Escalates to: Infrastructure Team (network/server issues), Desktop Team (hardware) 
- SLA: 15-minute response time 
 
Desktop Support Team: 
- Handles: Hardware issues, laptop/desktop problems, printer issues, mobile devices 
- Skills: Hardware repair, Windows troubleshooting, driver installation 
- Escalates to: Service Desk (after hours), Vendor Support (warranty issues) 
 
Infrastructure Team: 
- Handles: Server issues, network problems, storage, backups, virtualization 
- Skills: Windows Server, VMware, networking, SAN/NAS, backup systems 
- On-call: 24/7 for critical issues 
- Escalates to: Vendor Support (hardware failures) 
 
Application Team: 
- Handles: Line-of-business applications, database issues, custom software 
- Skills: SQL Server, .NET applications, web applications 
- Escalates to: Software Vendor (application bugs) 
 
Security Team: 
- Handles: Security incidents, malware, suspicious activity, access control 
- Skills: Firewall, antivirus, SIEM, security policies 
- Priority: All security tickets are high priority 
- Available: 24/7 for security incidents 

Before writing dispatch rules, define what each board represents. These definitions give the AI the context it needs to make routing decisions. Keep them factual and specific.

• Integration board is for all L2 issues.
• Professional Services board is for all L1 issues.

2. Dispatch Rules 

Controls how tickets are assigned to teams and technicians. 

Team Assignment Rules 

• Always assign password reset tickets to the Service Desk team. 

• Assign all tickets from VIP Corp to the “Premium Support” team regardless of ticket type. 

• If the ticket is about servers or network infrastructure, assign to the Infrastructure Team. 

• Do not assign tickets to the “Training” team - this team is for internal use only. 
    

Conditional Dispatch Logic 

1. Team Assignment Rules: 
 
1. Issue Type Routing: 
   - Security-related keywords (“phishing”, “malware”, “breach”) → Security Team 
   - Hardware issues → Desktop Support Team 
   - Server/network issues → Infrastructure Team 
   - Application-specific issues → Application Team 
   - Everything else → Service Desk Team 
 

User Assignment Rules 

• If the ticket is for “ACME Corp” and involves SQL Server, assign to John Smith (SQL expert). 

• If the ticket is about the “Legacy CRM” application, assign to the Legacy App team or Sarah Johnson. 

• Do not assign tickets to users in the “Disabled Users” list: Bob Wilson, Jane Doe. 

• For tickets about Office 365 admin tasks, assign to users with “O365 Admin” in their team description. 

3- Dispatch Note Instructions

The dispatch note is the internal note Mizo adds to the ticket when it assigns it. A good dispatch note tells the technician why the ticket was assigned to them — not just that it was.

Example : Include ticket summary and reasons for the dispatch.

This is especially useful for routing decisions that might not be obvious. If a ticket goes to the Security Team because it contains the word “phishing” buried in a long description, the dispatch note should make that visible.

Communication Rules

1- First Response Communication Rules

The first response email is the pre-assistance message Mizo sends to the end user before a technician starts working on the ticket. Its job is to gather additional information to speed up resolution.

Example :

• Question limits

Only include the 2 most relevant non-technical questions.

• Urgent tickets — call instead of email

Do not include any questions if the ticket is urgent.

• Formatting standards

Do not use any ” —” punctuation in emails.

Do not include a closing greeting (“Best regards”, “Thanks”, etc.).

Never insert or display the agent signature or [membersignature].

Resolution Configuration

1 - Resolution Steps Rules

Resolution rules guide how Mizo generates the step-by-step troubleshooting instructions shown to technicians in the ticket.

Example:

• Tag all risky operations as high risk, regardless of the source documentation: 

Tag all risky operations (deletions, running scripts, changing permissions, modifying registry keys, etc.) as ⚠️ [HIGH RISK].

2 -Knowledge Base Creation Rules

KB rules define how Mizo turns a resolved ticket into a reusable knowledge base article. Specify a title format and stick to it. Define mandatory sections so every article follows the same structure. Example :

• Title format Use pattern: [Category] Issue Title — Resolution Summary
• Mandatory sectionsEvery KB article must include: Problem Description, Resolution Steps, Affected Systems, and Prevention Notes.

General Rules

1. Update Satus Rules 

In each category — Triage, Dispatch, and Resolution — you can add rules.

Example:
When a ticket is dispatched, change the status to “Dispatched.”

Best Practices 

1. Start Simple, Iterate 

Begin with a few high-impact rules and expand over time: 

1. Start with 3-5 rules addressing your most common scenarios 

2. Monitor results for 1-2 weeks 

3. Refine rules based on AI behavior 

4. Add new rules gradually 

2. Be Specific and Clear 

Good: 

• If the ticket title contains “printer” or “printing” (case-insensitive), categorize as “Hardware / Printers”. 

Poor: 

• Printer tickets should probably go to hardware. 
    

3. Use Examples in Rules 

Help the AI understand by providing examples: 

• For password reset tickets (examples: “forgot password”, “locked out”, “cannot login”), assign to Service Desk and set urgency to Medium. 
    

4. Order Matters 

Place specific rules before general rules: 

Good Order: 
1. If ticket is from VIP Corp about SQL Server, assign to John Smith 
2. If ticket is about SQL Server, assign to Database Team 
3. If ticket is from VIP Corp, assign to Premium Support 
 
Poor Order: 
1. If ticket is from VIP Corp, assign to Premium Support 
2. If ticket is about SQL Server, assign to Database Team 
3. If ticket is from VIP Corp about SQL Server, assign to John Smith 
   (This rule will never be reached!) 
  

5. Document Your Intent 

Add comments to explain complex rules: 

Team Assignment Rules: 
 
# VIP Client Handling 
# VIP clients pay for premium support with faster response times 
# They should always go to the Premium Support team regardless of issue type 
If the client is “VIP Corp” or “Global Industries”, assign to Premium Support Team. 
 
# Security Incidents 
# Security issues need immediate attention 24/7 
# Route directly to Security Team 
If the ticket contains security-related keywords (list below), assign to Security Team immediately: 
- “phishing”, “malware”, “virus”, “ransomware” 
- “hacked”, “breach”, “unauthorized access” 
- “suspicious email”, “spam with attachment” 
  

6. Avoid Over-Specification 

Don’t create rules for every single scenario. Let the AI use its intelligence: 

Too Many Rules (Avoid): 

- If ticket includes “Space X”, categorize as “Space X —> {Matching Category}” 
- If ticket includes “Tesla”, categorize as ” Tesla —> {Matching Category}” 
- If ticket includes “Mizo”, categorize as “Mizo —> {Matching Category}” 
… (50 more Customer variations) 
  

Better Approach: 

- If ticket is from a customer, categorize as “{Customer Name} / {Matching Category}” 
- The AI will understand variations naturally 
  

7. Regular Review and Maintenance 

Schedule periodic reviews: 

• Weekly: Check for tickets that were miscategorized/assigned 

• Monthly: Review overall rule effectiveness 

• Quarterly: Major rule updates based on changing business needs 

 Getting Help 

If you continue to experience issues with fine-tuning: 

1. Check the Logs: Review processed tickets to see how rules were applied 

2. Contact Support: Email [email protected] with: 

1. Description of the issue 

2. The rule you’re trying to implement 

3. Example tickets where it’s not working 

4. What you expected vs. what happened 

3. Request a Review: Your Mizo contact can review your fine-tuning configuration and suggest improvements 

Roles and Permissions

Fine-tuning lives behind the Fine-Tuning page permission: read-only access can view every saved rule; changing or saving a rule requires full access. Running Test Rules also requires full Fine-Tuning access — it changes nothing in the PSA regardless of access level, since it’s a preview, not an action.

One setting is more restricted than the rest: the ConnectWise-only “skip automations by ticket source” list can only be viewed or changed by Mizo staff, not by a customer’s own backoffice user — even one with full Fine-Tuning access. If a ConnectWise customer asks to add or remove a source from that list, it has to go through Mizo, not their own admin.

Location-specific overrides live on the same page as the tenant-wide rule they override, so anyone with full access to the page can set one — there’s no separate permission for overrides.

Per-PSA Differences

• ConnectWise gets one fine-tuning capability the other two platforms don’t have at all: a list of ConnectWise ticket sources (e.g. Phone, Internal) that Mizo should skip entirely, so technicians can create and edit those tickets directly without Mizo’s automated updates colliding with them. HaloPSA and Autotask tenants have no equivalent setting anywhere in Fine-Tuning. This is the same field restricted to Mizo staff, described above under Roles and Permissions.
• The exact vocabulary a customer can reference in a category rule, and in some dispatch rules, differs slightly by PSA, because each platform models that data differently — for example, Autotask’s category structure isn’t the same shape as ConnectWise’s or Halo’s, and HaloPSA tickets expose an additional ticket-type field that dispatch rules can reference that the other two platforms don’t. The rule box always shows the right suggestion list for the client’s actual PSA, so in practice this mostly shows up as “a rule phrased around one PSA’s fields doesn’t carry over verbatim to another” when a technician copies rule text between tenants on different platforms.

Concrete Usage Examples

• A customer notices Mizo keeps picking “General” instead of “Network” for VPN-related tickets. They add a Triage rule: “classify VPN and remote-access issues under the Network category.” Mizo starts picking Network going forward — because “Network” already exists in their PSA’s category list; if it didn’t, the rule would have nothing to select.
• A customer wants a specific technician excluded from ever receiving billing-related tickets. A Dispatch rule (“never assign billing tickets to [name]”) works, because dispatch rules act as eligibility filters. The reverse ask — “always assign every VIP ticket to [name], even if they’re out” — won’t reliably hold, because Mizo can only pick from technicians it was actually shown as available for that ticket; someone unavailable isn’t a candidate no matter what the rule says.
• “We wrote a rule and nothing changed — why?” Work through, in order: is the underlying feature itself switched on for this client or board; does the rule use wording or an @mention the model can actually see (an inline warning while typing is a strong hint it can’t); is there an empty location override quietly cancelling the tenant-wide rule; does another rule on the same or a neighboring field already say something different. Then confirm with Test Rules rather than waiting for the next real ticket.
• “Can we make Mizo always do X?” Usually yes, if X is something the feature can already do at all — pick from an existing category, agreement, or employee list, skip an update, phrase something a certain way — written as an explicit, bounded rule. It’s not possible when X requires fabricating PSA data that doesn’t exist, or overriding a behavior that’s fixed by design — for example, a dispatch note can never exceed roughly two sentences, and dispatch rules can never leave a ticket unassigned while an eligible technician remains. Those need a change on the customer’s PSA side, or count as a feature request rather than a fine-tuning rule.

Appendix: Quick Reference 

Triage Quick Reference 

 Dispatch Quick Reference 

Attribution Quick Reference 

Conclusion 

Fine-tuning Mizo’s AI is an iterative process that improves over time. Start with your most important use cases, validate results, and expand gradually. Well-crafted fine-tuning rules will help Mizo automate more of your ticket workflow accurately and consistently. 

For questions or assistance, contact [email protected] or your Mizo account representative.