How to Choose On-Site vs Remote Support

Match the work to the constraint

Remote is fast when it fits. On-site is essential when it does not. Trouble starts when the wrong mode is the default: travel for a password reset, or endless remote attempts on a dead switch.

You want a decision frame your office manager can use under pressure.

This how-to covers intake questions, stop lines, visit prep, and after-hours rules so mode selection gets boring in the best way.

Why this gets messy

Remote support is fast when it fits. On-site support is essential when it does not. Problems arise when the wrong mode is chosen by default: travel for a password reset, or endless remote attempts on a dead switch.

A simple decision frame saves money and downtime. Match the work to the constraint: software access versus physical access versus multi-step change.

This guide helps owners and office managers choose a mode without turning every request into an argument.

Choose remote when

Prefer remote support when the device is reachable, the user can stay available, and the fix is configuration or software oriented.

• Account, email, and cloud permission issues
• Software installs and policy changes on healthy endpoints
• Troubleshooting that benefits from logs and remote tools
• Guidance for a staff member who can click through steps
• Quick checks after a change window when the endpoint is online

Choose on-site when

Schedule on-site help when the work requires presence, or when remote attempts have already proven the barrier is physical.

• Hardware replacement, cabling, or rack work
• Devices that will not power on or join the network
• Closet changes, ISP handoffs, and vendor escort
• Office moves, expansions, or multi-device cutovers better handled as a planned visit or project
• Conference room AV that only fails in the physical room path

Choose project time when

Projects are for work with design decisions, multiple dependencies, or a finish line measured in days rather than a single visit. Using Smart Hands as a substitute for project planning creates thrash: repeated visits that never converge on a stable design.

• Network redesigns, VLAN changes, and major Wi-Fi overhauls
• Tenant migrations and major identity changes
• Full office IT relocations with disconnect and reconnect windows
• Multi-site rollouts with sequencing and change control

Intake script for your team

When someone reports an issue, capture enough detail that the partner can recommend a mode quickly.

• What stopped working, and when did it start?
• Is the device powered on, and are there link or status lights?
• Can the user stay available for a remote session now?
• Is this blocking revenue, safety, or a small inconvenience?
• Is site access available after hours if needed?

What good looks like in practice

Your IT partner states the mode up front, explains why, and updates you if the mode should change. Remote tickets include a clear stop line: if physical access is required, the next step is a scheduled visit with a job list.

On-site days start prepared. Parts, credentials, and access are arranged before arrival so the visit finishes the agreed work.

You receive notes after on-site work. Future tickets should not rediscover the same closet surprise.

Scenario: password reset versus patch panel

A new hire cannot sign in because MFA was never registered. Remote closes that in minutes. The same morning, half a floor loses network after furniture installers tugged cables in a closet. Remote cannot reseat patch cables. On-site (or a planned Smart Hands visit) can.

Both are “IT problems.” Only one belongs in a remote queue. Treating them as the same request type is how queues get angry and offices lose time.

Cost and speed in plain language

Remote is usually faster to start and cheaper per issue when it fits. On-site adds travel and scheduling but finishes physical work. Projects cost more up front and save money when they prevent a string of confused visits.

The expensive pattern is mixing modes badly: remote thrash, then an unprepared on-site visit, then another remote thrash. One clear decision early is almost always cheaper.

Rules of engagement

Write three rules your staff can remember.

• Start remote when the device is online and the user can join a session.
• Escalate to on-site when power, cabling, closet, or hardware presence is required.
• Open a project conversation when the request changes design or spans multiple days and dependencies.

Multi-location decisions

If you have a headquarters in Austin and a smaller presence in Round Rock or elsewhere, decide which sites justify standing on-site capacity versus on-demand Smart Hands. Most small businesses do not need a technician in every suite. They need a clear rule for when someone travels.

Document site access differences. A suite with 24/7 badge access is not the same as a building that requires landlord escort after 6 p.m. Those details change whether an evening remote escalation can finish with a same-night visit.

Avoid the everyone-on-site reflex

During a scary outage, leaders sometimes demand bodies on site immediately. Sometimes that is right. Sometimes it puts a technician in a car while the actual fix is a cloud status page or a firewall rule that remote can change in minutes.

A good partner will say which facts would change the mode. No link lights across a floor points on site. A vendor SaaS outage does not. Asking for that reasoning keeps urgency productive.

Office manager role clarity

Office managers often become accidental IT coordinators. Give them a short playbook so they are not stuck translating panic into tickets.

• Collect symptoms and urgency before calling.
• Confirm whether the user can join a remote session.
• For on-site needs, confirm access windows and parts status.
• Do not promise staff a mode before the partner recommends one.

After-hours decision guide

Not every evening issue deserves an emergency visit. Use impact: is revenue or safety blocked, is a whole site down, or is one person inconvenienced until morning?

Write the after-hours rule before you need it. Include who can authorize overtime on-site work and what remote checks must happen first. Clarity at 10 a.m. prevents expensive confusion at 10 p.m.

Worked examples you can reuse in tickets

Use these examples to train staff and office managers on mode selection.

• Cannot sign into Microsoft 365 but the laptop browses the web: remote.
• Laptop will not power on after a move: on-site or depot swap path.
• One user cannot print, others can, queue exists: remote first.
• Whole floor lost network after a cleaning crew was in the closet: on-site.
• Need a new VLAN design for a remodeled wing: project.
• ISP tech scheduled Tuesday 1, 3 p.m. and needs an escort: Smart Hands / on-site.

SLA language that stays honest

Response time is not the same as restore time. Remote response can be fast while a parts-dependent on-site fix still takes a day. Ask providers to separate those ideas in plain language.

Also ask how priorities are set when multiple clients need on-site help. Honest constraints beat impossible promises.

Parts and spares change the mode

On-site help without parts is often diagnosis only. That can still be valuable, but it is not the same as repair. Ask whether common spares are available, whether same-day procurement is realistic, and whether a loaner workstation path exists for broken laptops.

Remote support can prepare the ground: confirm model numbers, warranty status, and configuration backups before anyone drives. That preparation is how on-site time turns into completion.

Conference rooms

Rooms fail in public. Remote can fix account and calendar issues. Displays, cameras, table boxes, and cabling usually need eyes in the room. If client meetings depend on a room, treat recurring failures as a mini-project with a known-good configuration note, not as endless one-off tickets.

One-page help note for staff

Create a one-page note titled “How we get IT help” and post it where staff already look. Include the remote-first rule, the physical-escalation rule, and examples from your own office rather than generic IT jargon.

Update the page when your partner or ticket path changes. A stale help page creates shadow IT faster than no page at all.

If you want Cytrix to help draft that page as part of onboarding or a support review, bring your current ticket path and the two or three issues that most often confuse people about remote versus on-site.

Decision frame in one paragraph

Match work to constraint. Software and account work with a reachable device is remote. Physical barriers need on-site or Smart Hands. Design and multi-day sequencing need project time.

Say the mode out loud when a ticket opens. Silence invites assumptions.

Remote-first criteria and examples

Prefer remote when the device is online, the user can stay available, and the fix is configuration oriented.

• Account and email permission issues.
• Software installs on healthy endpoints.
• Log-driven troubleshooting.
• Guided steps with a staff member at the keyboard.
• Post-change verification when systems are reachable.

On-site criteria and examples

Schedule on-site when presence is required or remote has proven a physical barrier.

• Hardware replacement, cabling, rack work.
• Devices that will not power on or join the network.
• Closet changes, ISP handoffs, vendor escort.
• Moves, expansions, multi-device cutovers.
• Room AV physical path failures.

Project criteria and examples

Projects are for design decisions, dependencies, and finish lines measured in days.

• Network redesigns and major Wi-Fi overhauls.
• Tenant migrations and major identity changes.
• Full office IT relocations.
• Multi-site rollouts with sequencing.

Intake script for staff and managers

What stopped working and when? Is the device powered and are there lights? Can the user join remote now? Is this blocking revenue or safety? Is site access available after hours?

These five answers usually unlock the right mode quickly.

Cost and speed tradeoffs

Remote is usually faster to start and cheaper per issue when it fits. On-site adds travel and scheduling but finishes physical work. Projects cost more up front and save money when they prevent a string of confused visits.

The expensive pattern is mixing modes badly.

SLA language that stays honest

Response time is not restore time. Remote response can be fast while parts-dependent on-site work still takes a day. Ask providers to separate those ideas.

Also ask how priorities are set when multiple clients need on-site help the same afternoon.

Multi-location rules for Central Texas teams

Decide which sites justify on-demand Smart Hands versus standing presence. Document access differences: 24/7 badge versus landlord escort after 6 p.m.

A headquarters in Austin and a smaller Round Rock suite should not silently share the same assumptions.

After-hours decision guide

Whole site down or safety impact can justify emergency on-site. One user inconvenience often waits until morning after remote checks.

Write authorization rules for overtime visits before you need them at 10 p.m.

Avoiding the everyone on site reflex

During scary outages, leaders sometimes demand bodies immediately. Sometimes that is right. Sometimes the fix is a cloud status page or a firewall rule remote can change in minutes.

Ask which facts would change the mode. No link lights across a floor points on site. A vendor SaaS outage does not.

Rules of engagement one-pager

Start remote when online and the user can join. Escalate on-site when power, cabling, closet, or hardware presence is required. Open a project when design changes or multi-day dependencies appear.

Post this where staff look. Update when ticket paths change.

Worked examples library

Cannot sign into Microsoft 365 but browsing works: remote. Laptop will not power on: on-site or depot path. One user cannot print and others can: remote first. Whole floor lost network after cleaners in the closet: on-site. New VLAN design for a remodel: project. ISP tech needs escort: on-site Smart Hands.

Parts, spares, and loaners

Mode choice depends on inventory. Diagnosis-only visits should be labeled as such. Loaner laptops reduce downtime when repairs take days.

Remote should gather model and warranty data before travel when possible.

Conference room playbook

Separate account issues from physical path issues. Keep a known-good config note per critical room. Stock common adapters if rooms are client-facing.

Recurring room failures deserve a mini-project, not endless tickets.

Measuring mode quality

Track bounce rate from remote to on-site, revisit rate after visits, and time to mode decision. Improve intake where bounce rate is high for trivial reasons.

Celebrate clean remote closes and clean first-visit finishes. Both are healthy.

Scenario matrix for leadership

Show three recent tickets rewritten as mode decisions. Leaders learn faster from your real history than from abstract charts.

If you lack history, use the worked examples library until you have your own.

FAQ: on-site vs remote support

Who chooses? Partner recommends with reasons; you can challenge with business context.

Can we require on-site for everything? You can, but you will overpay and often wait longer.

What if we disagree? Ask for the evidence threshold that would change the recommendation.

How does Cytrix help? Recommend the path that can finish the work and execute it with clear notes.

Step-by-step: deciding mode on a new ticket

Step 1: capture impact and symptoms. Step 2: determine reachability. Step 3: attempt remote if safe. Step 4: apply stop criteria. Step 5: schedule on-site with a job list or open a project conversation.

Teach this sequence to anyone who triages. Consistency beats heroics.

• Impact and urgency stated.
• Reachability checked.
• Remote attempted or skipped with reason.
• Stop criteria applied.
• Next mode scheduled with owner.

Step-by-step: preparing an on-site visit

Confirm access, parts, parking, escort needs, and definition of done. Attach photos. Book the remote bridge if configuration help is required. Notify the badge holder.

A prepared visit finishes. An unprepared visit becomes a paid discovery tour.

Step-by-step: running the visit

Confirm scope on arrival. Execute the list. Pause for discoveries. Verify with tests. Capture closeout. Confirm monitoring expectations before leaving.

If the visit cannot finish, leave the site safe and document the blocker clearly.

Step-by-step: returning to remote after on-site

Attach closeout to the ticket. Complete residual remote configuration. Confirm with the user. Update asset records. Close or schedule follow-up explicitly.

This handback prevents the on-site win from being undone by a missing monitoring or DNS step.

Decision trees for common categories

Printing: others work vs nobody works vs hardware errors. Network: one user vs one room vs whole floor. Identity: prompts and passwords vs total lockout. Rooms: calendar vs physical path.

Write tiny trees for your top categories. They train new coordinators quickly.

Building a local site profile pack

For each suite: address, parking, badge process, closet location, ISP, after-hours rules, hazards, and preferred windows. Keep photos of the rack and demarc if allowed.

Site profiles make remote dispatching accurate and Smart Hands arrival smoother across Austin-area locations.

When office politics push the wrong mode

Sometimes a leader demands on-site because it feels decisive, or demands remote-only because of cost. Use evidence and impact. Offer a time-boxed remote attempt with an automatic on-site trigger if stop criteria hit.

Compromise procedures beat arguments when emotions are high.

Training plan for a new office manager

Week one: shadow ticket intake. Week two: practice the five-question script. Week three: observe one on-site visit. Keep the one-page rules of engagement handy.

Office managers amplify whatever system you give them. Give them a clear one.

FAQ expansion: edge cases

What if the only person with keys is unavailable? That is an access problem to solve before the outage, not during it. What if remote tools are blocked by the outage itself? That is a strong on-site signal. What if a vendor insists on their own technician? Decide escort and coordination roles early.

Edge cases belong in the site profile and support agreement, not in improvisation.

Appendix: sample status updates

Remote in progress: we are connected with the user and testing X. Escalating on-site: remote confirmed no link light on switch A; visit proposed at 2 p.m. with spare switch. Project recommended: closet has no documentation and three failing devices; stabilization done; redesign quote next.

Templates keep communication calm and consistent.

Extended scenarios library for training

Accounting cannot open the shared drive but web apps work: start remote, check identity and mappings. Warehouse scanner only works when cradled: likely physical or vendor path, gather model details remotely, schedule on-site if cradle or cable faults appear. Whole office VPN fails after ISP change: remote firewall checks first, on-site if handoff or appliance is dark.

Owner wants every laptop upgraded this weekend: that is a project or staged Smart Hands plus remote configuration, not a single remote ticket. Badge door fails after furniture move: often vendor plus on-site coordination, not a password reset.

Creating a mode-selection cheat sheet for your MSP

Ask your partner to publish a one-page cheat sheet customized to your sites and systems. Include stop criteria, after-hours rules, and who authorizes overtime visits.

Keep it with the office manager and in the ticket portal. Review it quarterly when sites or providers change.

Handling vendor-driven on-site work

Software vendors sometimes insist on their engineer while you provide network access. Decide who escorts, who owns the change window, and who verifies afterward. Remote monitoring should know a change is happening.

Unescorted vendor work in closets is how mystery cables appear.

Capacity planning for seasonal spikes

Tax season, campus move-in, healthcare busy periods, and summer office moves change demand for on-site work. Tell your partner about seasonal spikes so scheduling capacity is honest.

Surprise spikes turn into missed windows. Known spikes become staffing plans.

Documentation artifacts that make both modes faster

Asset tags, rack photos, known-good room notes, printer maps, and site profiles reduce both remote troubleshooting time and on-site wandering. Fund documentation as stabilize work on the roadmap when tribal knowledge dominates.

Every repeated scavenger hunt is a documentation ticket in disguise.

Glossary for non-technical coordinators

Remote session: a technician connects to a device over the network with permission. Smart Hands: an on-site technician completes a defined physical task. Project: planned work with design and a finish line. Sev-1: major business stoppage. Punch list: open items with owners after a visit or move.

Shared language prevents false urgency and false calm.

Practice drills for coordinators

Once a quarter, give the office manager three fictional tickets and ask which mode they would recommend and what info they would gather. Compare notes with your IT partner.

Drills are short and expose ambiguity before a real outage does.

Appendix: sample job lists

Firewall swap: confirm backup config, rack new unit, cable WAN and LAN as photographed, bring up with remote engineer, verify internet and VPN, update monitoring, leave old unit labeled. Desk staging: place dock and monitors, confirm drop, sign-in smoke test, print test, note asset tag.

Copy and adapt. Specificity is kindness to future you.

Complete operating manual summary

Capture impact and reachability. Start remote when safe. Escalate with evidence and a job list when physical barriers appear. Open a project when design and sequencing dominate. Prepare visits with access and parts. Close with notes and monitoring updates. Review bounce patterns monthly.

Keep site profiles current for every Austin-area suite. Train office managers with the five-question script. Write after-hours authorization rules before you need them. These habits make mode selection boring in the best way.

Case study style walkthrough: mixed morning

At 8:30 a new hire cannot enroll MFA: remote. At 9:15 a conference room camera fails before a client call: remote checks calendar and device join, then on-site if the USB path is dead. At 11:00 half a floor loses network after a cleaning crew was in the closet: on-site with urgency.

At 2:00 leadership asks for a redesign of guest Wi-Fi across two suites: project conversation, not a same-day Smart Hands improvisation. One morning, four modes of thinking, no arguments required if the frame is shared.

Implementation checklist for the next two weeks

Publish rules of engagement. Publish the intake script. Build or update site profiles. Ask your partner for stop criteria in writing. Schedule one coordinator drill. Review the last ten tickets for mode mismatches and fix the pattern, not only the tickets.

Two weeks of implementation beats six months of debating philosophy.

• Rules of engagement posted.
• Intake script shared.
• Site profiles updated.
• Stop criteria documented.
• Coordinator drill scheduled.
• Recent ticket mode review completed.

Owner briefing script for mode strategy

We use remote support when software access can finish the job quickly. We use on-site Smart Hands when power, cabling, closets, or hardware presence is required. We use projects when design and multi-day sequencing are the real work.

This keeps us from overpaying for travel on password resets and from underestimating physical work that remote cannot finish. Here is our stop-line rule, our after-hours authorization rule, and our last month's bounce-ticket review. That is the strategy in plain language.

Final checklist before you change how your office requests help

Confirm the ticket path, publish the mode rules, update site profiles, and tell staff what will feel different. Ask your partner to acknowledge stop criteria in writing. Run one practice scenario with the office manager.

Then use the next month of real tickets as feedback. Adjust the cheat sheet where mismatches appear. Mode strategy improves through use, not through a single announcement.

When to call Cytrix

Contact Cytrix when you need help deciding whether an issue stays remote or needs Smart Hands or project time. Describe symptoms, urgency, and site access. We will recommend the path that can finish the work.

You can also call 512-518-1228 for a quick triage conversation during business hours.