Day-to-day IT support is the part of an IT partnership your people judge every single day. NetFusion Designs supports organizations across the Greater Toronto Area, Kitchener-Waterloo, Montreal and Winnipeg — from the faults that stop one person working to the ones that stop the whole business.
Support is easier to buy when the boundary is drawn before you need it. Ours sits around the technology your people use to do their jobs, and around keeping it in the condition it was signed off in. Everything below is handled by one team under one agreement.
Sign-in trouble, multi-factor prompts that will not clear, mailboxes and shared calendars, file permissions, printing, conferencing hardware, mobile devices, the applications your team lives in, and the laptop behaving oddly for no reason anybody can name. This is most of the volume, and most of it settles inside a single session.
Behind the first response sits work needing more depth: identity and directory faults, mail flow and deliverability, network and firewall behaviour, server and virtualization problems, backup and restore requests, and anything where the symptom and the cause are in two different places. These are engineering problems wearing the costume of a support ticket, and they are staffed accordingly.
A suspected compromise is not a request for help; it is a containment job against the clock. Anything carrying a security signature leaves the general queue immediately for our Security Operations Centre, staffed round the clock alongside our support team.
Unlimited means nobody counts tickets or minutes against you, and no member of your staff should ever hesitate to raise something small in case it costs money. That hesitation is how minor faults grow into outages. What unlimited does not mean is unlimited scope. Work that restructures your estate — a tenant migration, a firewall replacement, a new office build, a line-of-business application deployed for the first time — is quoted separately as a project, because it needs a plan, a window and a rollback position rather than a place in a queue. Which side of that line something falls on is answered when you ask, not once we have started.
Nobody should have to remember a procedure while something is broken. Each route below lands in one system and produces one record, so the choice is about convenience, not consequence.
A person answers, at any hour, and can start work while you are still describing the fault instead of logging a callback for somebody else. Use this when work has actually stopped.
One monitored address. A ticket opens automatically and the acknowledgement carries a reference; reply to it and your message joins the original ticket rather than opening a rival one that nobody links back.
Raise and track requests, check status without asking anybody, and submit routine changes that need no conversation — a new starter, an access request, a software install.
Your ticket is read and classified the moment it lands, rather than at the point it eventually comes up for attention. Classification establishes how many people are affected, whether anything is time-critical, and whether the request is really a security matter in disguise. You get an acknowledgement carrying a reference and the name of the engineer who now owns it. If the answer will take longer than the first conversation, you are told so during the first conversation.
Two clocks matter here and they are routinely confused. Response is how long before a competent person is engaged with your problem. Resolution is how long before your people can work again. A provider advertising one impressive number is quoting the first and letting you assume the second.
We publish the first: critical, business-down issues carry a 15-minute response target. We do not publish the second, because a resolution figure with no scope attached commits us to nothing and tells you nothing. Both clocks are specific to your environment, your definitions of severity and the hours you genuinely operate, so they belong in your service agreement — negotiated before signature, then reviewed with you monthly.
Every provider says it escalates. The mechanism matters far more than the promise, and it reduces to three things being true at once.
Your account has a small group of engineers holding its context, and one of them owns each ticket from classification through to closure. Bringing in a specialist adds a person; it does not transfer the ticket and end the original owner’s interest. That distinction is the whole difference between escalating something and passing it on.
Before anyone picks up, your build standards, network layout, applications, dependencies and fault history are already in front of them. Documentation is maintained continuously as part of the service, not assembled mid-incident — the moment it is least likely to be complete or correct.
Escalation fires on the nature of the problem and on elapsed time, without waiting for anyone to request it. Nothing stalls out of sight with an engineer who has run out of ideas and has not yet said so. You are never asked to retell the history either: whoever joins reads the thread before speaking to you.
Where the cause turns out to be a third party — a software vendor, an internet carrier, a telephone provider — we take it up with them on your behalf. Leaving your people queuing on somebody else’s support line to explain a fault they did not create wastes an afternoon.
The service scales, but the reason organizations arrive at it changes with size and circumstance.
There is no internal IT, so by default the role has landed on whoever looked most capable with a computer during the first year. They did not volunteer, it is not in their job description, and it interrupts the work they were hired to do. Managed IT support gives that person their week back.
One or two internal staff exist and are permanently underwater, holding support, projects and vendor relationships simultaneously, and taking no holiday without a laptop. At this size the constraint is coverage, not competence.
Multiple locations, hybrid staff and a support load that no longer behaves predictably week to week. The requirement becomes consistency — the same process, standards and reporting whether the request comes from head office or a branch two provinces away.
Manufacturing, distribution, healthcare, hospitality and anyone whose most expensive hours are not between nine and five. Round-the-clock staffing is not a nicety in these environments; it is the entire reason for the arrangement.
A capable internal IT manager is worth keeping. What they usually need is not a successor but a floor underneath them — somebody absorbing the volume, and somebody beside them for the parts of the estate outside their specialism.
In a co-managed arrangement the division of labour is agreed explicitly and written down. Most often we take first response and out-of-hours cover, so your internal person is not carrying a phone every night, plus depth on security, identity and infrastructure. They keep the things only an insider does well: knowing the business, owning the roadmap, and being the person leadership actually trusts on technology decisions.
Tooling, documentation and reporting are shared rather than held hostage, which matters if the arrangement ever ends. It also removes a single point of failure. Holidays, illness and resignations stop being events that put the organization at risk, because the environment is documented and our team is already familiar with it.
Yes, on exactly the same terms as anyone sitting in an office — same agreement, same three routes in, same tooling. Home broadband and personally owned equipment sit outside what we manage, but we will help establish when they are the cause rather than leaving somebody guessing.
No. Hourly and ad-hoc support is a genuine option and a number of clients begin there. What it leaves out is the proactive monitoring and patching that reduces how often anything breaks, so volume tends to stay where it is.
Critical, business-down issues carry a 15-minute response target. Every other severity level is defined within your service agreement, and performance against all of them is reported to you monthly. We publish that one figure because the severity that defines it is written down beside it — a number quoted without the scope behind it is a marketing claim rather than a commitment.
Yes. Our support team is staffed 24/7, as is our Security Operations Centre. A call at three in the morning reaches a person who can act, not a voicemail box heard when the office opens.
Discovery comes before tooling. We document the environment, agree severity definitions and coverage hours, put access and monitoring in place, then tell your staff how to reach us. You can raise tickets from day one; what improves over the following weeks is how much context the person answering already holds.
Yes, for francophone staff and for clients in Quebec, where we have a Montreal presence alongside our Ontario and Winnipeg operations.
Describe what keeps going wrong and how often. You will get a straight answer on what a proper fix involves — a fully managed arrangement, a co-managed one alongside the people you already employ, or a piece of work that ought to be scoped and quoted as a project before anybody touches it.
%20(1).avif){kind=logo}
%201.avif)
