Contact Assignment
Many tickets arrive without a clean PSA contact attached — an email lands in a shared or “catch-all” mailbox, comes from an unrecognized sender, or is generated automatically by a monitoring tool. Contact Assignment reads the ticket to work out who actually sent it and which company they belong to, then reassigns the ticket to that contact in your PSA — before triage, categorization, or title generation even run.
Why It Matters for MSPs
- No more tickets stuck under a generic contact. Tickets get routed to the right person and company automatically, instead of sitting under a catch-all mailbox contact.
- More accurate downstream automation. Triage, categorization, and title generation all depend on knowing who a ticket is from — getting attribution right early makes everything after it more accurate.
- Scales with your intake volume. Technicians no longer need to manually track down who a shared-inbox ticket really belongs to.
How It Works
This runs once, the first time a ticket is processed — it isn’t re-evaluated on later reprocessing of the same ticket (for example after an edit or a board move).
Mizo reads the ticket’s subject, body, sender, and any attachments to work out who appears to have sent it — pulling out an email address, phone number, name, job title, and company, including from signature blocks and forwarded headers. It then tries to match what it found against your existing PSA contacts by email, phone, or name. Only when that lookup doesn’t produce one confident match does Mizo do a deeper AI pass to choose between candidates or infer the company from the sender’s domain.
For tickets that already have a specific requester attached (not a shared/catch-all mailbox), Mizo will still correct a wrongly matched contact if it’s confident about the right one, but it won’t move the ticket to a different company unless the ticket came in through a catch-all mailbox or the client has been explicitly flagged for reattribution.
Tickets recognized as coming from an automated system (a monitoring alert, an automation-generated email) aren’t attached to a specific human contact, but Mizo can still recognize which managed company the alert is about — for example from a hostname in the title — and move the ticket to that company.
When Mizo can’t identify anything better than what’s already on the ticket, it leaves the ticket exactly as it is — this is the most common outcome and is silent by design.
Once Mizo has confirmed which company a ticket belongs to, that company also feeds downstream contract/agreement selection — the right PSA agreement is picked based on the same attributed company.
Configuring Contact Assignment
The setting appears in the backoffice as “Automate [contact/user] assignment” (wording follows your PSA’s own terms).
| Setting | What happens |
|---|---|
| Off | Contact Assignment doesn’t run at all. No analysis, no to-do, nothing written to the PSA. |
| Recommendation | Mizo determines the contact/company and, if it would change anything, creates an “Update end user” / “Update company” action for a technician to review and apply with one click. |
| Automation | Mizo writes the new contact/company to the PSA itself as soon as it’s confident, with no human step. |
A separate setting, “Companies with reattribution enabled,” lists specific clients where Mizo is allowed to reassign the company even on tickets that didn’t come through a catch-all mailbox.
Roles and Permissions
Changing the automation level — and the “Companies with reattribution enabled” list — requires full access to the Workflow page in the backoffice; technicians with read-only access can view the current setting but not change it.
Executing a pending Recommendation-level “Update end user” / “Update company” action works differently: a technician does this from the PSA-embedded ticket panel, and any technician who can open the ticket there can trigger it, regardless of their Mizo backoffice role — the action isn’t gated by the same page-level permission that controls the setting itself. The acting technician’s identity is still recorded for the audit trail, and any successful PSA write, from either level, is logged in the ticket’s audit history.
Concrete Usage Examples
A ticket lands in the shared support inbox from an unrecognized personal email. Mizo can’t match it to an existing contact by email, phone, or name, and there’s no company hint in the content — it leaves the ticket where it landed. Nothing visible changes.
A ticket arrives from [email protected], and Jane already exists as a PSA contact at Acme Corp, but the ticket landed under the shared mailbox’s default contact. Mizo matches Jane by email, confirms Acme Corp is her company, and — depending on the setting — either reassigns the ticket automatically or offers a one-click “Update end user” recommendation.
A monitoring alert creates a ticket with a device hostname in the title but no human sender. Mizo recognizes it as an automated alert and doesn’t try to attach a person, but if the hostname or title clearly points to a specific managed client, it can still move the ticket to that client’s company.
Best Practices
- Start new clients on Recommendation so a technician can confirm the first few reassignments before trusting Mizo to write directly to the PSA. Move to Automation once attribution has proven reliable for that tenant.
- Unwanted reassignments on non-catch-all tickets? Check whether that client was added to “Companies with reattribution enabled” — that setting deliberately widens reattribution beyond catch-all tickets for selected companies.
- If Contact Assignment never seems to fire for a client, the most common cause is that the PSA’s catch-all/shared-mailbox setup isn’t recognized. Mizo determines the catch-all company from how the PSA’s email connectors are configured, so a misconfigured or missing default company means Mizo treats every ticket for that client as already correctly attributed.
Troubleshooting
There’s no dedicated attribution error banner. If a technician clicks to execute a pending “Update end user” / “Update company” recommendation and the PSA write fails, they see the generic to-do error: “Failed to execute task. Please try again.” Check the PSA connection and whether the proposed contact/company still exists.
When Mizo can’t resolve a contact at all, this is silent by design — no note, no error, no to-do; the ticket simply keeps its existing attribution.
Frequently Asked Questions
Why didn’t Mizo reassign this ticket to the right client? Most often because nothing in the ticket gave Mizo enough to work with, or because the ticket isn’t from a catch-all mailbox and that client isn’t on the reattribution-enabled list. Silence here is expected behavior, not a bug.
Can we turn this off for one client? The automation level is tenant-wide, but a client can be excluded from the broader reattribution behavior by not adding them to “Companies with reattribution enabled” — catch-all attribution still applies to all clients.
Per-PSA Differences
On HaloPSA, company-only reassignment requires Mizo to find a “main contact” for that client in Halo. If none is set up, Mizo silently skips the company reassignment rather than partially updating the ticket.
On ConnectWise and Autotask, Mizo can move a ticket to the correct company even without a main contact — it updates the company field alone and leaves the specific contact blank if it can’t identify one.