Managed helpdesk
An agreed queue of user requests and incidents.
Request categories, coverage, user updates and escalation runbooks.
Most outsourced help desks are good at logging tickets and not so good at closing them. We run L1, L2 and L3 as one team, so the person who picks up a Microsoft 365, Google Workspace, Mac, Windows or network problem can usually fix it instead of passing it along. Your team keeps the decisions. We take the queue.

/ Fit check
Best for
Growing businesses on Microsoft 365, Google Workspace or mixed Windows and Mac fleets, and internal IT teams that need overflow or after-hours cover
Not for
Walk-up desk-side support or hardware repairs that need someone in the room
Works with
Your existing ticketing system, or ours if you don't have one
/ Direct answer
An outsourced L1, L2 and L3 help desk is an external support team that covers all three tiers under agreed response targets: first-line requests (password resets, access, how-to questions), second-line technical faults (Microsoft 365, Google Workspace, device management, email, endpoints and networks) and third-line root-cause and infrastructure work. BPro Technologies runs the tiers as one team and escalates to your staff or vendors only when a decision or physical task sits with them.
/ Scope your engagement
Agree which requests the helpdesk can resolve, which need specialist escalation and who updates the user. Response is acknowledgement and triage, not a promise that every incident is resolved within that time.
An agreed queue of user requests and incidents.
Request categories, coverage, user updates and escalation runbooks.
Assigned tickets when your team needs more capacity.
Shared priority rules and a clear return-to-team handoff.
L2/L3 investigation for issues beyond first-line troubleshooting.
Findings, approvals required and the next technical action.
This example illustrates the record format. It is not a client result or a service-level commitment. Your proposal lists the deliverables and responsible people.
| Stage | Work record | Handoff requirement |
|---|---|---|
| L1 intake | Affected users, impact, identity checks and initial troubleshooting | Assign priority and record the next update |
| L2 investigation | Diagnostics, dependencies, attempted fixes and approvals needed | Escalate with findings, not an empty ticket |
| L3 / vendor | Specialist analysis, proposed change and validation | Confirm outcome with the user and document follow-up |
Users, ticket volumes, required hours, internal IT responsibilities, current queue and escalation gaps.
/ 01
L1 resolves known, repeatable requests from a runbook: resets, access requests, licence assignment, basic device and app issues. L2 handles problems that need diagnosis, like a mailbox that stopped syncing for one team, a sign-in policy blocking the wrong users, or a device profile that won't apply. L3 takes the hardest problems: root causes, server and cloud infrastructure, configuration changes and vendor escalations. The label matters less than who owns the ticket from start to finish.
Split helpdesks usually fail in the gap between tiers. L1 logs the ticket, writes "escalated to L2", and the user waits while someone else re-reads the thread and asks the same questions again. We keep one engineer as the owner from first contact to close, and L2 joins the same ticket instead of opening a new one.
| Tier | Typical work | Usually owned by |
|---|---|---|
| L1 | Resets, access requests, licences, new-starter setup, known fixes, self-service guidance | BPro help desk |
| L2 | Microsoft 365 and Google Workspace faults, identity and device management, email, endpoint and network issues | BPro engineers |
| L3 | Root-cause analysis, server and cloud infrastructure, configuration changes, vendor escalations | BPro senior engineers, with your vendor or developers where the fault is in their product |
/ 02
A helpdesk SLA sets two clocks for each priority level: time to respond (a person acknowledges the ticket and starts work) and time to resolve or give a plan. Priority comes from impact and urgency, not from who shouts loudest. We agree the actual numbers during scoping, because the right targets depend on your hours, your users and what counts as business-stopping for you.
| Priority | What it looks like | How it's handled |
|---|---|---|
| P1 · Critical | Nobody can sign in, email is down for everyone, or a breach is suspected | Phone and ticket at once; an engineer stays on it until it's contained |
| P2 · High | A team or key system is degraded, with no good workaround | Worked ahead of the normal queue, with updates on an agreed interval |
| P3 · Normal | One person is blocked but has a workaround | Worked in order, within the agreed resolution window |
| P4 · Low | Requests, changes, how-to questions | Scheduled; batched where that's more efficient |
We don't publish one set of response times for every client. A 30-person firm with one working-day schedule and a 300-person team across three time zones need different targets, and a number that ignores that isn't really an SLA.
/ 03
Yes, and for a lot of clients that's the point. We take the volume (resets, access, onboarding, device issues) so your internal people can work on projects and decisions. The boundary is written down before we start: which tickets we close, which come back to you, who approves changes, and what we never touch without asking.
/ 04
It can be either, and the difference changes how you manage it. Staff augmentation puts named engineers inside your process, taking direction from your team and working your queue. A managed helpdesk runs on our process and tooling, and you manage the outcome through reporting and reviews. Some clients start with augmentation and move to a managed model once the runbooks exist.
| Staff augmentation | Managed helpdesk | |
|---|---|---|
| Who directs daily work | Your IT lead | BPro, against agreed priorities |
| Ticketing and runbooks | Yours | Ours, or yours if you prefer |
| Holiday and sick cover | Agreed per engineer | Our problem, not yours |
| Best when | You have a strong internal lead and just need hands | You want the queue owned end to end |
/ 05
Every escalation should arrive with enough context that nobody has to ask the user again: what's broken, who's affected, what was tried, what changed recently, and what we think the next step is. When the ticket comes back, it comes back with the fix, the cause if we found it, and whether it's likely to happen again.
Capture the impact, the user, the device, the exact error text and screenshots in the first contact.
Set priority against the agreed matrix and check for known issues or a wider outage.
Fix it, or escalate on the same ticket. The owner doesn't change.
Record the fix and the cause. If it's the third time this month, raise a problem record.
Repeat tickets become runbook updates, fixes or projects, so the queue gets smaller over time.
/ 06
Every managed client receives 24/7 monitoring and helpdesk. Response targets depend on incident priority and the agreed systems in scope; round-the-clock availability does not mean every issue has the same resolution time. Standalone staff-augmentation and co-managed engagements have their own coverage agreements.
For teams spread across regions, coverage is planned around where your users actually are. A handover note travels with every open ticket at the end of a shift, so the next engineer picks up where the last one stopped.
/ 07
Compare the same ticket categories, systems and coverage hours, then ask how the provider records outcomes. A fast acknowledgement is useful, but it does not show whether the user can work again. Keep response, restoration and final resolution separate in the report.
Helpdesk evaluation checklist: questions to agree before selecting a provider
| Check | What to ask for | Why it matters |
|---|---|---|
| Scope and exclusions | Written user, device, application and ticket-category coverage | Makes two quotes comparable and prevents surprise routing |
| Response and restoration | Priority rules, clock start, coverage hours and escalation contacts | Distinguishes an acknowledgement from getting people working |
| Queue quality | Ticket age, reopened tickets, repeat incidents and customer feedback | Shows whether the desk closes problems or only moves them |
| Security and access | Named accounts, least privilege, approval rules and an access-removal process | Keeps troubleshooting accountable and access controlled |
| Handover and exit | Runbook ownership, ticket export and supplier-transition responsibilities | Keeps operational knowledge available to your business |
These are evaluation criteria, not published performance results or contractual targets. Ask for the measures and commitments that apply to your proposed scope.
Usually within a few weeks rather than a day. The first stretch is discovery: users, devices, admin access, common ticket types and your escalation contacts. Taking live tickets before that means guessing, so we follow the 30-day onboarding plan and start with a limited set of ticket categories before widening scope.
Whichever keeps the history in one place. If your team already works in a helpdesk platform, we work inside it with named accounts. If you don't have one, ticketing is included and you can export the full history if you ever leave.
That's your call. Some clients want us to answer as their IT desk; others prefer clear BPro branding. Either way, users deal with named engineers rather than an anonymous queue.
We diagnose remotely first, which resolves most of them. If a job genuinely needs hands, such as a failed device, cabling or network kit that has to be physically reset, we write up exactly what's needed so your staff or a local contractor can do it in one visit.
Yes. Many internal IT teams bring us in for nights, weekends and holidays around their working hours, so their own people aren't permanently on call. We agree which priorities we handle alone and which need your on-call contact.
Microsoft 365 and Google Workspace, Windows and macOS devices, common business SaaS applications, networks and firewalls, and workloads in Azure, AWS and Google Cloud. If your environment runs something specialist, we document it during onboarding rather than guess.
By scope: users, devices, coverage hours, ticket categories, and whether you want a managed service or named engineers. We don't publish a flat per-user price because it would be wrong for most teams. A short discovery call gets you a written estimate.
/ Next step
Users, ticket volumes, required hours, internal IT responsibilities, current queue and escalation gaps.