Describe your support categories, employees, devices, and approval rules. Makeform turns the brief into an editable IT request form that captures the affected service, business impact, troubleshooting, screenshots, equipment details, and access context before the request reaches your team.
Send IT requests to Slack, Google Sheets, email, and Zapier.
Sample prompts for the IT request form builder
Choose the support workflow closest to yours, replace the example systems and policies, then send the prompt to the Makeform builder. Each structure is an editable example, not a live generated result.
Prompt ready4 formats
Audience
Employees reporting device, account, or network problems
Format
Support intake with issue-specific branching
Prompt size
531 chars
Brief qualitySends to builder
Example form structure
Support intake with issue-specific branching
Prompt exampleEditable in builder
Employee, location, and contact
Short answerFirst ask
2
Device and issue category
Dropdown
3
What happened and what have you tried?
Long answer
4
How many people are affected?
Number
5
Screenshot of the error
File upload
Suggested routing tags
Suggested
Technical support
Access request
Equipment request
Ask separately about impact and urgency. An employee may call an issue urgent, but affected users, blocked work, and a deadline give the service desk better triage evidence.
Step 1
Identify
employee selects the service, device, or equipment need
Step 2
Explain
impact, symptoms, timing, and evidence arrive together
Step 3
Route
category and location give the request a clear owner
Step 4
Review
IT assesses support, access, inventory, or approval needs
Better IT intake
Start troubleshooting before the first reply.
A message that says the computer is broken gives the service desk no device, symptom, impact, or evidence. A structured IT request form asks for the next useful facts while the employee still has the issue in front of them.
Branch by IT request type
Account trouble can ask for the system and username, hardware trouble can ask for an asset tag and symptoms, and equipment requests can ask for specifications and a needed-by date. Employees answer only the path that matches their need.
Capture triage evidence
Exact error text, start time, affected users, blocked work, troubleshooting steps, and screenshots provide more signal than an unstructured urgency label. The team can compare requests without reconstructing every report by email.
Keep secrets out of intake
Place a visible reminder beside technical fields: never submit passwords, multifactor codes, recovery codes, private keys, or API secrets. Ask for the system name and safe identifiers instead of credentials.
One front door, focused paths
Handle support and planned requests without one giant form.
Begin with a short choice that reflects the employee's goal, then reveal focused questions. The same form can receive incidents and service requests while preserving the details each path needs.
Technical support
Collect device, operating system, connection, error, start time, impact, and steps tried. Include an obvious separate route for security concerns and show any urgent contact instructions before ordinary submission.
Hardware and equipment
Ask whether the item is new, additional, or a replacement; capture the current asset when relevant; and gather role, compatibility, location, specifications, business purpose, and timing.
Accounts and access
Identify the person, system, requested role, business reason, manager, and duration. Avoid collecting credentials, and make the confirmation clear that submission starts review rather than granting access.
Software and onboarding
Bundle applications, licenses, device choices, start dates, shipping, and role-specific system access. Conditional sections keep routine setup short while preserving context for nonstandard requests.
Build the intake workflow
Create an IT request form around triage decisions.
Work backward from what the service desk must decide: which queue owns the work, what is affected, how disruptive it is, what evidence exists, and whether another person must review it.
Tell Makeform who submits requests, which categories your IT team handles, what device and identity details are useful, and which paths need a manager or system owner. Include your real service names and safe-data guidance.
02
Edit conditional question paths
Keep identity and summary questions common, then branch into support, access, software, equipment, and onboarding sections. Make only actionable fields required, add Other choices, and remove data the team will not use.
03
Configure notifications and handoffs
Use category, location, or service to organize where a response should go and who needs to see it. Keep the request details together so a screenshot, asset tag, impact statement, and requester contact are not split across channels.
04
Test every route, then publish
Submit a realistic example for each request type. Verify hidden fields, required questions, mobile usability, file uploads, notifications, secret warnings, and confirmation wording before sharing the link on an intranet or help page.
Choose an intake method
Structure helps the service desk act on the first handoff.
Chat and email are useful for conversation, but an IT request form establishes a consistent starting record. The employee sees what details matter, and IT receives context that can be reviewed and routed.
Approach
What IT receives
Best fit
ApproachChat or hallway request
What IT receivesA quick description with context scattered across messages and no consistent device, impact, or ownership fields.
Best fitLive conversation when someone is available to investigate immediately.
ApproachEmail to the support inbox
What IT receivesA durable message and attachments, but variable subjects, missing diagnostics, and manual follow-up for standard questions.
Best fitFree-form situations that do not need repeatable routing or comparison.
Approach
Conditional IT request form
What IT receivesConsistent employee and impact details plus focused diagnostics, access context, equipment specifications, and files for the selected path.
Best fitA shared front door for recurring support and technology requests.
Field guide
Six parts of an actionable IT request form.
Good intake captures more than a problem statement. It identifies the employee and asset, classifies the request, records symptoms and evidence, measures impact, supports planned purchases or access review, and sets a clear next step.
Requester & environment
Know who needs help and where they work.
Collect the employee's work contact and the environment in which the issue occurs. Department, office or remote location, time zone, and preferred contact channel can affect ownership and follow-up. Avoid gathering personal information that is unrelated to resolving the request.
Employee name, work email, department, and contact preference.
Office, building, remote location, or time zone when relevant.
Requester versus intended user for manager-submitted or shared-device requests.
Device & service
Name the technology without asking for secrets.
A safe identifier connects the report to the affected technology. Ask for device type, asset tag, operating system, application, service, or network. Add help text that excludes passwords, recovery codes, private keys, API secrets, and multifactor authentication codes from every submission.
Device type, asset tag, operating system, and connection method.
Application, account, service, printer, or network name.
A visible warning never to enter passwords or authentication secrets.
Symptom & evidence
Turn broken into a reproducible description.
Pair a concise summary with structured diagnostic prompts. Ask what the employee expected, what actually happened, when it started, whether it is repeatable, and which steps have already been tried. Exact error text and screenshots reduce ambiguity without forcing employees to diagnose the cause.
Expected behavior, actual behavior, start time, and frequency.
Exact error message and the action that triggers it.
Troubleshooting attempted plus optional screenshots or screen recordings.
Impact & urgency
Measure disruption with observable facts.
Urgent means different things to different people. Ask whether a workaround exists, how many users or locations are affected, which task is blocked, and whether there is a fixed deadline. Define priority choices in plain language and place separate security or emergency directions before the form.
One person, a team, a site, or an organization-wide service affected.
Work blocked, degraded, or inconvenient, with any workaround described.
Deadline or business event affected, without promising a response time.
Access & equipment context
Gather the facts needed for review.
Planned requests need different evidence from incidents. For access, ask for the system, role, business task, manager, and duration. For equipment, ask for the intended user, specifications, compatibility, location, business purpose, needed-by date, and current asset details when replacing something.
Requested role or permission, business reason, manager, and duration.
Item, quantity, specifications, compatibility needs, and work location.
Current asset tag and condition for replacement or repair requests.
Review & confirmation
Let employees verify the handoff.
A review page helps catch the wrong asset, system, location, or date before submission. The confirmation should repeat a useful summary, say that IT will review the request, and distinguish intake from access approval, equipment availability, purchase authorization, or completed support work.
Review screen for category, device, impact, dates, and attachments.
Confirmation that the request was received for review, not approved.
A reference or follow-up route when your operating process provides one.
Related tools
Build focused forms for each IT service path.
Use the shared IT intake as a front door, or open a specialized Makeform tool when service tickets, equipment, software, or access requests need their own workflow.
Practical answers for service desk leads, IT administrators, operations teams, and office managers improving employee technology intake.
What is an IT request form?
An IT request form is a structured intake point for employees to report technology problems or request services such as equipment, software, account access, onboarding setup, and device support. It collects consistent identity, category, asset, impact, timing, and evidence fields so the IT team can understand and route the submission. The form records the request; it does not by itself approve access, authorize a purchase, or complete the work.
What fields should an IT request form include?
Start with employee name, work contact, department, location, request category, short summary, detailed description, affected device or service, business impact, urgency, and attachments. Use conditional sections for exact error messages and troubleshooting on support issues, system and role on access requests, or specifications and needed-by date on equipment requests. Include a warning not to submit passwords, multifactor codes, recovery codes, private keys, or API secrets.
How can one form handle support, access, software, and equipment requests?
Put a request-type choice near the beginning and show a focused conditional section for the selected goal. Keep identity, contact, summary, and impact questions common. Then ask technical diagnostics for support, role and duration for access, vendor and integration context for software, or item specifications and location for equipment. Include an Other route for requests that do not fit the list, and test every branch before publishing.
How should an IT request form ask about priority?
Ask for observable impact instead of relying on High, Medium, and Low alone. Useful questions include how many people are affected, whether work is blocked or degraded, whether a workaround exists, which service or deadline is affected, and when the issue began. Define any urgency choices in plain language. Put your real security-incident or emergency contact path before the normal form rather than implying every submission is continuously monitored.
Can employees upload screenshots and device photos?
Yes. A file upload can collect error screenshots, photos of physical damage, or other evidence that helps describe the request. Label the field with what is useful, make it optional when not every request needs a file, and remind employees to check images for visible credentials or sensitive information. The written fields should still capture the exact error and the action that produced it so the request remains understandable without opening every attachment.
Is this IT request form generator free?
Yes. Makeform supports unlimited free forms and responses, so you can generate, edit, publish, test, and collect IT requests at no charge. The paid tier removes the Makeform badge. You can adapt the generated questions to your systems, support categories, device inventory, safe-data guidance, and review process before sharing the form with employees.
Does an IT request submission grant access or approve equipment?
No. Submission creates an intake record for the workflow you configure. It does not automatically mean a manager, system owner, budget holder, security reviewer, or IT team has approved the request. State that distinction in the confirmation message. Collect approver or manager context where it is useful, but avoid wording that promises access, inventory, purchasing, delivery, or resolution before the responsible team reviews the details.
How do I improve an IT request form after publishing it?
Review the clarification questions the service desk asks repeatedly. Turn recurring missing facts into concise fields, help text, or conditional questions. Check whether employees recognize the categories, can find an asset tag, understand urgency definitions, and know what files are safe to upload. Remove questions that do not affect routing or resolution, and submit a test response after every meaningful change to verify branches, required fields, notifications, and confirmation text.
Give every technology need a clear front door.
Generate an IT request form that arrives ready to review.
Unlimited free forms and responsesConditional IT request pathsEditable fields and confirmation