By the Templateez Team · Licensed Attorney · June 2026

IT Support & Computer Repair Intake Forms: What MSPs and Repair Shops Need to Capture

A client walks into your repair shop, sets a laptop on the counter, and says "it's slow." That is not a diagnosis. It is not even a starting point. "Slow" could mean a failing hard drive, 47 browser toolbars, a malware infection, 4 GB of RAM trying to run Windows 11, a dying battery throttling the CPU, or a perfectly healthy machine whose owner has unrealistic expectations. Without structured intake, your technician is going to spend the first thirty minutes of billable time figuring out what the client should have told you before the device ever left their hands.

Most IT shops and managed service providers collect a name, phone number, and a one-line description of the problem. That is a repair tag, not an intake. A real IT support intake form captures the device profile, the problem history, the data situation, the authorization scope, and the client's environment — everything your technician needs to diagnose accurately, protect client data, and avoid the liability issues that come with touching someone else's machine. Here is what that form should include.

Device information: know what you are working on before you open it

Every repair starts with the device. Your intake should build a complete profile before a technician touches anything:

• Device type — desktop, laptop, tablet, all-in-one, server, network appliance. This determines your workflow, your parts sources, and whether the repair happens on your bench or on-site.
• Make and model — "HP laptop" is not enough. You need the exact model number. An HP Pavilion and an HP EliteBook have completely different internals, different part availability, and different serviceability. The model number tells you whether RAM is soldered, whether the battery is user-replaceable, and whether you need proprietary screwdrivers to open the case.
• Serial number — for warranty verification, parts ordering, and matching the device to the work order if you have multiple machines on your bench. Photograph or scan it at intake — do not rely on the client to provide it accurately.
• Operating system and version — Windows 10 vs. Windows 11, macOS Sonoma vs. Ventura, the specific Linux distribution. Version matters for driver compatibility, software support, and whether the OS itself is the problem. A machine running Windows 10 21H1 that has not been updated in three years has a different issue profile than one on the current release.
• Warranty status — is the device under manufacturer warranty, an extended warranty, or an AppleCare plan? Opening a device that is still under warranty can void coverage. Your intake needs to flag this before your technician removes the first screw.
• Physical condition at intake — document existing damage before you start work. Cracked screens, dents, missing keys, liquid damage indicators. If a client claims you cracked their screen during a RAM upgrade, your intake documentation is your defense.

Problem description: symptoms, timeline, and what changed

The difference between a ten-minute fix and a four-hour diagnostic rabbit hole is almost always in the problem history. Your intake form needs to extract the story behind the symptom:

• Primary symptom — what is the device doing (or not doing) that brought the client in? Be specific. "Won't turn on" is different from "turns on but no display" is different from "turns on, shows logo, then blue screens." Each points to a completely different subsystem.
• When it started — did this begin suddenly or gradually? After a specific event? After a Windows update? After the client's teenager installed something? The timeline narrows the cause dramatically.
• Error messages — exact text, error codes, blue screen stop codes. "Some error popped up" is useless. "CRITICAL_PROCESS_DIED" is a diagnosis. Ask the client to photograph error messages if they recur.
• Recent changes — new software installed, hardware added, Windows update, dropped the device, power surge, liquid exposure. Clients often do not volunteer this information because they do not think it is related, or because they are embarrassed. Your form needs to ask directly.
• Frequency and reproducibility — does the problem happen every time, intermittently, or only under specific conditions (under load, when running a particular application, after the device heats up, only on battery)? Intermittent problems that your technician cannot reproduce on the bench are the most expensive to diagnose.

This structured diagnostic intake follows the same logic that auto repair shops use — symptoms, timeline, recent changes, and reproducibility. The difference is the machine on the bench, not the diagnostic methodology.

Data backup status: the highest-stakes question on the form

No other field on your intake form carries more liability than data. A hard drive failure during a motherboard repair. A technician who reformats the wrong partition. A ransomware removal that wipes encrypted files the client assumed you would recover. These are not hypothetical scenarios — they are Tuesday at a busy repair shop.

Your intake must establish the data situation before any work begins:

• Last backup date and method — when was the device last backed up? To what — cloud (iCloud, OneDrive, Google Drive, Backblaze), external drive, NAS, or "I don't back up"? A client who has never backed up and has ten years of family photos on a single drive needs to understand the risk before you open the case.
• Critical data on the device — is there data on this device that exists nowhere else? Tax documents, business records, family photos, a dissertation in progress? If the answer is yes, your workflow changes. You may need to image the drive before doing anything else.
• Data recovery expectations — if data loss occurs, does the client expect you to attempt recovery? Do they understand that data recovery is a separate service with separate pricing? Establishing this at intake prevents the conversation where a client assumes data recovery was included in a $75 diagnostic fee.

Login credentials and access: the security minefield

Your technician needs to log into the device to diagnose it. That means handling client credentials, which is a security and liability issue that most repair shops handle poorly — sticky notes on the keyboard, passwords written on the intake tag in plain text, or technicians asking clients to shout their password across the counter.

Your intake form needs a structured approach:

• Device login password or PIN — captured in a way that is not visible to other customers and is stored securely. Some shops use a sealed envelope. Others use a separate credentials form that is stapled face-down to the work order. Whatever your method, document it.
• Local account vs. domain account — for business machines, is this a standalone local login or a domain-joined machine? Domain machines may require the domain admin credentials or a separate local administrator account for off-network troubleshooting.
• BitLocker or FileVault status — full-disk encryption changes everything. If the drive is BitLocker-encrypted and you do not have the recovery key, certain repairs (including BIOS updates and hardware changes) can lock you out of the data permanently. Ask at intake. Require the recovery key before accepting the device for service.
• Administrator access — does the client have admin privileges on the device, or is it managed by their employer's IT department? If the device is company-managed, your client may not have the authority to authorize repairs, and the MDM policy may block your technician's tools.

Service authorization: scope, limits, and consent

IT repair creates unique authorization issues because the scope of work often changes mid-repair. You open a laptop for a fan replacement and discover the thermal paste has never been replaced and the heat sink is caked with dust. Do you fix what you found? You need authorization before you expand scope.

• Repair authorization limit — a dollar amount above which you must contact the client for approval before proceeding. "$200 maximum without prior approval" is a clear, enforceable boundary. Without it, a technician who replaces a logic board on a machine the client was going to scrap anyway has created a billing dispute.
• Parts authorization — OEM parts, aftermarket parts, or refurbished? OEM costs more. Aftermarket may not fit perfectly or carry the same warranty. The client should choose at intake, not when the technician is holding a soldering iron.
• Data handling consent — explicit written consent for your technicians to access the device, view files as necessary for diagnosis, and handle data during repair. This is not optional — it is your legal protection. If a technician encounters illegal content during a repair, your consent form and your reporting obligations intersect in ways you need to have thought through before it happens.
• Abandoned device policy — what happens if the client does not pick up the device? After 30 days? 60 days? 90 days? State laws vary on unclaimed property, and your intake form should state your policy clearly so the client has acknowledged it in writing.

Business vs. residential: two different intake tracks

A home user with a slow laptop and a business with 50 endpoints, a file server, and a compliance requirement are fundamentally different clients. Your intake needs to branch based on the client type:

Residential clients. The intake focuses on the individual device, the problem, and the authorization. Turnaround expectations are flexible — "a few days" is usually acceptable. The client relationship is transactional unless you convert them to a maintenance plan.

Business and MSP clients. The intake expands dramatically:

• SLA expectations — what is the agreed response time? Is this a 4-hour, 8-hour, or next-business-day SLA? What is the escalation path if the SLA is missed?
• Priority level — is this a P1 (business down, all users affected), P2 (significant impact, workaround available), P3 (single user, non-critical), or P4 (enhancement request)? Priority determines resource allocation and communication cadence.
• After-hours and emergency support — does the client have after-hours coverage? What constitutes an emergency? What is the after-hours rate differential? A client who calls at 2 AM on a Saturday because their email is "acting weird" is a different situation than one whose server crashed and their entire office cannot work on Monday morning.
• Point of contact and authorization chain — who can authorize repairs? Who gets status updates? Is there a ticketing system you need to integrate with? For business clients, the person dropping off the device is rarely the person who approves the invoice.

Network environment: the MSP intake layer

For managed service providers taking on a new business client, the device-level intake is just the first layer. You need a complete picture of the client's IT environment:

• Endpoints — total number of desktops, laptops, and mobile devices. Operating system mix. Age of hardware. This drives your licensing costs, your monitoring agent deployment, and your refresh cycle recommendations.
• Servers — on-premises servers, cloud servers (Azure, AWS, GCP), or hybrid. What roles — file server, domain controller, application server, print server? Physical or virtualized?
• Cloud services — Microsoft 365, Google Workspace, Salesforce, line-of-business SaaS applications. What does the client depend on that you did not build and cannot control?
• Current security stack — antivirus, endpoint detection and response, firewall (hardware and software), email filtering, DNS filtering, MFA status. You need to know what is already in place before you can assess gaps or propose your managed security offering.
• Network topology — number of locations, WAN connections, ISP details, wireless infrastructure, VPN configuration. A single-office client with one ISP and a consumer router is a different engagement than a multi-site client with SD-WAN and site-to-site tunnels.
• Remote access setup — does the client already have remote access tools deployed (RMM agents, TeamViewer, AnyDesk)? If you are deploying your own RMM, do they need to be removed? Are there VPN connections for remote employees that you will be managing?

When the engagement goes beyond break-fix support into strategic technology planning — cloud migration, compliance audits, disaster recovery design, or a full infrastructure overhaul — a dedicated IT consulting intake form captures the compliance frameworks, technology roadmap, and business-continuity requirements that an MSP break-fix intake is not designed to surface.

Software licensing and installed applications

Software licensing is a compliance issue that most repair shops ignore and most MSPs handle reactively. Your intake should establish the baseline:

• Installed software inventory — what is installed on the device? For business clients, this extends to the entire environment. Unlicensed software is a liability — for the client and potentially for you if you are managing the environment.
• License keys and subscription status — does the client have their Windows product key? Their Office license? Are these perpetual licenses or subscriptions? A client whose Microsoft 365 subscription lapsed three months ago and is now locked out of their email has a different problem than one whose Outlook is crashing.
• Line-of-business applications — accounting software, industry-specific tools, ERP systems, custom-built applications. These often have their own support contracts, and a technician who reinstalls the OS without accounting for a specialized application that requires a vendor-assisted reinstall has created a much bigger problem than the one they were hired to fix.

Previous repair history and insurance claims

Repair history tells you what has already been tried, what has already failed, and whether the device has a pattern of problems that suggests a deeper issue:

• Previous repairs — has this device been serviced before? By whom? What was done? A laptop that has had its motherboard replaced twice in eighteen months has a different prognosis than one coming in for its first repair.
• Previous diagnosis — did the client take this to another shop first? What did they say? This saves you from duplicating diagnostic work and gives you a second opinion to either confirm or challenge.
• Insurance or warranty claims — is the client planning to file an insurance claim or a warranty claim based on your diagnosis? If so, your documentation requirements change. The repair report becomes evidence, and your description of the problem and the cause needs to be precise enough to support a claim. "Hard drive failed" is not the same as "Western Digital WD10EZEX, S/N WCC4J1234567, developed bad sectors in LBA range 0x1A000000–0x1B000000 consistent with mechanical head failure, resulting in total data loss. Device was 14 months old, outside manufacturer warranty."

Building trust through thoroughness

IT support is a trust business. Clients are handing you a device that contains their email, their photos, their financial records, their browsing history, and their passwords. A one-page intake form with a name and a phone number does not communicate that you take that responsibility seriously. A structured intake that asks about encryption status, data backup, credentials handling, and repair authorization tells the client that you understand the stakes — and that you have a process for protecting what matters to them.

If you are building documentation across multiple service trades, the Trade Services Bundle includes IT support alongside 51 other service categories, each with trade-specific intake fields.