Frequently Asked Question

What IT Support Can and Cannot Do - Understanding Support, Consulting, and Projects

Last Updated 7 months ago

Purpose of This Article

This article explains what IT Support is designed to do, what it is not intended to cover, and why some requests are resolved quickly while others require more time, planning, or commercial approval.

This document is provided for general guidance only.
It does not create any binding obligation or service commitment.
Actual scope of work is governed strictly by the applicable written agreement, AMC, estimate, or contract.

What IT Support Is

IT Support focuses on keeping existing systems operational and addressing day-to-day technical issues that arise during normal usage.

IT Support typically involves:

Diagnosing reported issues
Restoring functionality where feasible
Troubleshooting errors, failures, or disruptions
Ensuring systems return to a usable state

Support work is generally reactive or preventive, not transformational.

What IT Support Is NOT

IT Support is not:

Consulting
System design
Infrastructure planning
Optimization or re-architecture
Large-scale changes or improvements

These activities fall under consulting or project work, even if they sound small at first.

Support vs Consulting vs Projects (Simple Explanation)

IT Support

Fixes issues in existing setups
Restores what was previously working
Handles routine operational problems

Example:
Printer not printing, email not syncing, system not booting.

IT Consulting

Analyzes current setup
Recommends improvements or changes
Evaluates performance, security, or scalability

Example:

“How can we improve network stability?”
“Which firewall should we use?”

This involves analysis and expertise, not just fixing.

IT Projects

Planned changes or new implementations
Multiple steps, coordination, and testing
Often involve new hardware, software, or design

Example:
Office network redesign, server migration, CCTV expansion, cloud migration.

Projects are structured, scoped, and separately estimated.

Why Some Issues Are Fixed Quickly (And Others Are Not)

Some issues are resolved quickly because they are:

Known and repetitive
Limited in scope
Independent of external dependencies

Other issues take longer because they may involve:

Multiple systems or devices
Network or infrastructure dependencies
Third-party vendors (ISP, OEM, software providers)
Data integrity or security risks
Incomplete access or information

Speed depends on complexity, not intention.

Why “It’s Just a Small Change” Is Often Not Small

In IT, a “small change” can:

Impact multiple systems
Affect security or data integrity
Cause downtime if done incorrectly
Require testing and rollback planning

Examples of “small changes” that are not actually small:

Changing IP settings
Modifying firewall rules
Upgrading software on live systems
Changing network topology

What looks minor on the surface may carry hidden technical risk.

Why Not Everything Is Included in Routine Support

Routine IT support is designed to:

Maintain stability
Reduce downtime
Address operational issues

It is not designed to:

Improve performance beyond baseline
Redesign environments
Implement new workflows
Absorb unlimited time or repeated changes

When work goes beyond routine support, it may require:

Additional approval
Separate estimation
Dedicated project handling

How This Benefits Everyone

Clear boundaries ensure:

Faster resolution of genuine support issues
Reduced downtime
Better planning for improvements
Fair and transparent billing
No last-minute surprises

Structured support leads to better outcomes for both the customer and the service provider.

Final Clarification

IT Support exists to keep systems running, not to continuously modify or redesign them.

For long-term improvements, scalability, or changes, consulting or project engagement is the correct and safer approach.

Important Note

This article is for general informational purposes only and does not override any written agreement, invoice, AMC, or contract.

All services are provided on a best-effort basis, subject to system condition, access, third-party dependencies, and operational feasibility.