Here’s a scenario every MSP knows well: you deploy a sleek new client portal, spend hours configuring it, send onboarding emails to all your customers, and two weeks later, they’re still calling. Still emailing your personal inbox. Still messaging you on Teams, expecting someone to respond.
The problem isn’t your customers. It’s the assumption that they’ll change their behaviour to match your tool. They won’t.
The MSPs winning on customer experience right now aren’t the ones with the best portal; they’re the ones who’ve stopped asking customers to go somewhere specific and started showing up wherever the customer already is.
That’s what multichannel ticket creation is. And this guide will walk you through exactly how to implement it, channel by channel, step by step.
Most MSPs think about ticket creation from the inside: which board should this land on, which tech should pick it up, and how do we categorize it? That’s the right conversation to have internally. But your customers aren’t thinking about any of that. They’re thinking: I have a problem, who do I tell?
“You’ve got to go to where the customer is, as opposed to trying to make the customer come to where you want them.”
That quote came from a real MSP we spoke to during a product demo. He manages a mixed workforce; some customers prefer email, some live in Teams, and field techs are on their phones all day. Forcing all of them into a single channel means losing most of them.
The business case for multichannel isn’t just customer satisfaction; it’s operational. When customers can’t easily reach you, they either:
All three outcomes cost you more time than a properly routed ticket ever would. Multichannel fixes the front end of your support process so everything downstream: triage, routing, SLA tracking, and billing, can actually work.
| What You’ll Have By the End of This Guide • A configured support mailbox that turns emails into tickets automatically • A Microsoft Teams app your customers can use to raise and track issues • Branded desktop and mobile apps for your customers • A web portal for browser-based ticket submission • Routing rules that send every channel into the right tech queue• A tested end-to-end flow from your customer’s perspective |
Email is still the highest-volume ticket creation channel for most MSPs, and it’s also the one most likely to go wrong without proper configuration. Emails landing in a shared inbox that someone manually checks, copy-pastes into a ticket, and files? That’s a bottleneck and a compliance risk.
What to configure:
Common mistakes to avoid:
| How this works in DeskDay In DeskDay, you connect your Office 365 or Google support mailbox directly in Channel Settings. Once linked, every email to that address creates a ticket on your configured board automatically. DeskDay’s email threading keeps the full conversation intact. When a customer replies to any notification email, their reply appends to the original ticket chat rather than creating a new one. The auto-acknowledgement email includes the ticket ID and a summary of the issue, so customers always have confirmation. You can set any added mailbox as your primary for full customization. All outgoing emails for announcements, user onboarding, reports, and billing will be sent from the primary mailbox. You can add up to five support mailboxes and map each one to the board of your choice, ensuring that tickets are routed and organized exactly where you need them. |
Teams has become the default communication layer for most business customers, especially those on Microsoft 365. If your customers are already in Teams for internal communication, they should be able to raise a support ticket from there without switching apps.
What to configure:
One critical thing to get right: notification volume.
This is where Teams integrations most commonly go wrong. Every status change, every assignment, every internal comment firing as a Teams notification is a fast path to customers disabling the app entirely.
| Notification Rule of Thumb Send notifications for: tech reply, ticket resolved, scheduled maintenanceDo NOT send notifications for: status changes, internal reassignments, internal notes. One MSP we spoke with had to disable Teams notifications entirely because the volumewas so high customers were complaining. Start minimal; you can always add more. |
| How this works in DeskDay DeskDay’s Teams app installs directly into your customer’s Teams environment through IT-Connect. Customers can submit tickets by using the built-in ticket form and chat with the techs right there. Notification controls are granular: you can configure exactly which events trigger a Teams notification, per customer tenant if needed. Single sign-on is available through Microsoft Entra (Azure AD), so customers authenticate with the account they’re already logged into. |
A branded desktop and mobile app is the channel that does the most to change customer behaviour, especially for customers who have previously ignored portals. The reason is simple: an app on their taskbar or home screen is in their line of sight. A web portal they have to remember the URL for is not.
Desktop app:
Mobile app:
| How this works in DeskDay DeskDay’s IT-Connect is the customer-facing app suite available on desktop (Windows/Mac), iOS, and Android. It’s branded to your MSP, so customers see your logo and colours, not DeskDay’s. Customers can submit tickets, upload photos, view ticket history, and receive push notifications, all from one app. For deployment, the IT-Connect desktop can be pushed to all managed devices. The mobile app is available on both app stores under your branding. Single sign-on is supported through Microsoft Entra, Google Workspace, and Okta, so customers log in with the accounts they already use. |
The web portal isn’t dead, it’s just no longer your primary channel. There will always be customers who prefer to access support from a browser, especially those without the desktop app installed or who are working on a personal device. Your portal should be fast, clean, and require minimal steps to submit a ticket.
What to configure:
What to avoid:
| How this works in DeskDay DeskDay’s web portal is available at a custom subdomain of your choice and is fully branded to your MSP. The ticket submission experience is designed around the three-click rule: customers can go from landing on the portal to submitting a ticket in under 60 seconds. The portal also shows a full ticket history, live status, and chat with techs, so customers have a reason to come back after initial submission. SSO is available via Microsoft, Google, and Okta. |
Multichannel only works if every channel lands in the right place. Without routing rules, you get a single inbox where a low-priority network outage and a password reset sit next to each other with equal urgency. That’s not a unified queue; it’s chaos with better branding.
Routing rules to configure:
What good routing feels like:
A tech opening their queue should see only the tickets relevant to them, with accurate priorities, clear context, and no noise from other teams. A customer submitting from any channel should never need to know or care which board their ticket landed on.
| How this works in DeskDay In DeskDay, routing rules are configured in the Board Settings and Workflow Automation sections. You can set default board assignments per channel, create rules based on customer tier, contact type, or ticket keywords, and define after-hours routing using your configured business hours and holiday calendar. DeskDay’s AI Triage Agent (coming soon) will handle dynamic routing automatically, reading the ticket content, assessing priority, and routing to the right board and tech based on skills, workload, and SLA timers. For MSPs who want to get ahead of this, the groundwork starts with a clean board structure and well-labelled routing rules. |
This step is skipped more often than any other, and it’s the most important one. Before rolling out any channel to customers, you need to experience it as they will.
Testing checklist:
| Before You Go Live: Final Checklist • Support mailbox connected and auto-acknowledgement configured • Teams app installed and notification rules set to minimal • Desktop and mobile app deployed with SSO enabled • Web portal live with clean branding and short submission form • Routing rules set for default board, after-hours, and priority escalation • Full end-to-end test completed from a real customer account • Customer communication sent explaining the new channels available |
Setup is the easy part. Adoption is where most MSPs stall. Here’s what works:
Lead with the channel they already use most
Don’t announce five new ways to reach you at once. Look at where the majority of your tickets already come from: email, probably, and make sure that channel works flawlessly first. Then layer in Teams for customers who are heavy Microsoft 365 users, then mobile for field-facing customers.
Make the first experience effortless
The first time a customer submits a ticket through a new channel, it either earns trust or loses it permanently. Make sure the experience is fast, the acknowledgement is immediate, and the first response from a tech arrives quickly. A great first impression carries enormous weight.
Show them, don’t just tell them
A one-minute screen recording showing how to submit a ticket from Teams or the mobile app beats a three-page instruction email every time. If you have a customer success manager or account manager, a 5-minute walkthrough on a scheduled call is even better.
Use your announcement system for maintenance windows
One underused feature in most PSA platforms is the ability to broadcast announcements to customers: proactive communication about planned outages, maintenance windows, or service updates. When customers see this working, they start trusting the app as a real communication channel rather than just a ticket form.
| How this works in DeskDay DeskDay includes an Announcement feature that lets you broadcast messages to specific customer tenants or all customers simultaneously, directly through IT-Connect. Customers see the announcement as a notification in the app, so they don’t need to be monitoring email to stay informed. This is particularly useful for proactive communication during outages and maintenance windows, and it’s one of the fastest ways to build customer trust in the platform. |
Multichannel ticket creation isn’t about giving customers more options for its own sake. It’s about removing the friction between a customer having a problem and your team knowing about it. Every channel you add that a customer actually uses is a ticket that gets logged, tracked, and resolved instead of falling through the cracks.
The MSPs who get this right stop measuring success by portal login rates. They measure it by what doesn’t happen: the phone call that never came because the Teams app handled it, the escalation that never happened because the customer got a push notification before they got frustrated, the lost ticket that never got lost because every channel feeds the same queue.
“You don’t need every customer to use every channel. You need every customer to find at least one channel easy enough to actually use.”
Start with email. It’s already working and just needs to be automated properly. Add Teams for your Microsoft-heavy customers. Deploy the mobile app for field-facing contacts. And let the portal catch everyone else. You don’t have to do it all at once. But do test each channel before you go live, and do it from your customer’s seat.
That’s where the real work is.
Ready to set up multichannel ticketing in DeskDay?