What Should an Outsourced IT Support Proposal Include?

What should be determined first in an outsourcing computing proposal?

User and device inventory, systems to be supported, working hours, on-site visits, demand management, reporting and out-of-scope expenses should be clear in the outsourcing IT service offer. For healthy comparison, all candidates should be given the same certificate of need. Simply listing the number of computers and asking for a monthly price can make different service scopes seem like the same job.

This article does not prepare all the legal provisions of a maintenance contract. It focuses on how the business can describe its technical and operational needs when requesting a quote. For general selection criteria enterprise IT support selection guide you can use Here, the focus is on what information to write in the request document, how to compare providers' responses, and how to define delivery.

Describe your business's needs in one paragraph

The initial description does not have to include the entire history of the company. Write down how many locations you work in, the approximate number of users, critical applications, and the main problem you want to solve. If there is an internal IT employee, specify which issues the external team will support. In a completely outsourcing model, it should be determined separately who will make daily decisions and approvals.

An example need statement might be: “We are looking for regular support for office computers, shared file access, and email user operations; we would also like to consider server migration.” This is not a customer case, it is an example of how demand can be limited. Such a statement makes for more viable offers than simply “do all our IT work.”

Don't create inventory from computers alone

Separate the assets to be supported into user computers, servers, network devices, and cloud services used. Printers or specific business applications may also be part of the support expectation. Tick ​​which system is managed by another company. Holding the provider responsible for an application that the provider cannot access or is not authorized for may lead to unnecessary delays in the future.

If you don't have a complete inventory, ask for it as a printout of the first inspection rather than hiding it. Creating a startup record is a separate workload. It is also important to separate approximate numbers from exact numbers. When it is known with what assumptions the proposal was prepared, it becomes more understandable how device or location differences that arise later affect the scope.

Write project work separately with daily support

User access problems, new staff accounts and routine software settings can be evaluated within daily support. Opening a new branch, server installation or moving all e-mails to another platform may be projects. Packing all of this work into one vague monthly fee makes it difficult to understand what's included.

In the request document, give your ongoing needs and the projects you expect under two separate headings. Ask for a response from the provider with the same distinction. Pricing a project separately is not a negative in itself; The important thing is to know this from the beginning. It should be clearly explained how to request a new job, at what stage approval will be obtained, and when the price will be determined.

Determine the request channel and approval person.

Write down the channel through which employees will submit support requests. Telephone, email or registration system can be used; The preferred method must be suitable for the way the business operates. Determine the people who will approve transactions such as user account opening, authorization and device delivery. It should not be assumed that every employee can seek all management changes on their own.

Separation of duties is especially important for public addresses and administrator accounts. The technical team's implementation of the process and the company's access decision-making are different responsibilities. Ask to see how this flow will work in the proposal response. If a problem arises and it is clear who is waiting for a decision and what information is missing, the support process can be carried out in a more traceable manner.

Allocate response, review and resolution times

Notifying that a request has been received, starting the technical investigation, and permanently resolving the problem are the different stages. Find out which phase the provider gives a deadline for in the contract. Whether the work depends on the internet operator, device supply or other software team may affect the solution. How these dependencies will be recorded and tracked should be explained in the proposal.

Do not determine priority based solely on the title of the person opening the request. Affected users, job loss and alternative employment opportunities should be evaluated. A single person not being able to access an application does not have the same impact as an entire company not being able to access a file server. Adding examples to the request document that illustrate this distinction helps service providers bid with the same understanding of priority.

On-site visit and remote support conditions

Specify the locations and the expected work pattern at each location. Regular visits, field work only when necessary or mainly remote support options create different workloads. Ask how items such as length of visit, transportation, and after-hours work will be handled. If a quote seems low, it may be because it doesn't include on-site work at all.

In remote access, authorized person approval and necessary access limits must be determined. Passwords do not need to be shared in a file during the initial offer phase. It can be planned what access is required for the technical review, how long it will be used and how it will be removed at the end of the study. This process supports both the customer's control of his own system and the execution of the service with certain responsibilities.

Request verification of maintenance and safety work

Make “updates available” more concrete. You may ask which systems will be evaluated, how changes will be approved, and what post-processing control will be done. NIST's enterprise patch management guide describes a process approach from identifying and prioritizing updates to verifying installation. This resource is not a certificate of a service provider or a certificate of compliance with a particular contract.

Backup tracking should be explained in a similar manner. A job registration that appears successful does not mean that the restore test has been performed. It should be stated which backups will be checked, whether testing is included, and who will approve in case of problems. Technical reports should show not only the number of transactions, but also the remaining risks and the decisions expected from the customer.

Compare offers on the same titles

Include assets to be supported, operating hours, site coverage, demand channel, reporting, initial review, and overhead in your comparison table. Ask each candidate for separate responses to these topics. This way, you won't treat a quote that doesn't include some items at all as a direct cheap alternative to a more comprehensive quote. Completing missing answers is a natural part of the interview.

In addition to the price, also ask about the service cycle. It should be clear how inventory, administrative access, and open requests will be transferred when the study ends. The company's control over its own data and systems must be maintained. Regular IT service should create traceable records and explainable responsibilities, rather than a structure where everything remains in a single person's memory.

Describe service acceptance with report example

You can ask the provider to explain the report format at the quote stage. Useful fields include the date the work was done, the system affected, the action applied, the result, and any open topics. Not every institution needs to ask for the same detail; The report should help the business make decisions. Seeing only the number of closed registrations may not be enough to understand which critical issues are ongoing. This is why it is important to separate open work from completed work.

In an example acceptance approach, the new user's account may be opened, access to the required public address may be attempted, and the company representative may be asked to confirm the result. This is an example of a task description, not an actual customer application claim. In a different system, the acceptance criteria will change. When it is written down what action the provider will take and what check the customer will perform, it is not assumed that the job is completed with just an email message.

Also review whether the report is useful in the monthly evaluation. A recurring problem may indicate the need for a new project; Missing customer approval may be stopping the technical team from progressing. Separating these prevents the service from remaining only a troubleshooting activity. Stating this evaluation expectation in the request document also clarifies what effort will be devoted to reporting.

Include in the request document how the scope change will be managed. When a new employee, new location or new application arrives, be clear about what information will be shared and when the offer will be reviewed. It is more appropriate to approximate the need for growth rather than hiding it. Also ask the provider to clearly show what inventory and usage assumptions the starting price is based on. This way, changes are more understandable for both parties.

Draft request for proposal that you can send

The one-page request document may include company and locations, approximate number of users/devices, critical applications, current issues, daily support expectations, and individual projects. Add to that the hours of operation, the need for on-site visits, the approval person, and the expectation of reporting. Ask the provider to separately specify the work not included and the assumptions to be verified in the initial review.

İz Medya computing and IT service You can start a scope conversation with this draft. Your document does not need to be complete; Unknown topics can be addressed in the first review. The important thing is to distinguish which need is based on ready knowledge and which topic is to be investigated. Thus, the offer received describes a workable working order rather than just a monthly figure.

Frequently Asked Questions