What should an MSP service request form include?

Include client organization, requester, service category, affected user or asset, site, impact, urgency, approval requirement, attachments, and workflow or PSA mappings.

Can one MSP service request form work for many clients?

Yes, when the form carries organization context and dynamic fields scope options to the selected or authenticated client.

MSP service request template

MSP service request form template

A customer-facing MSP service request form template for portal intake, live customer data, approvals, PSA handoff, and workflow automation.

Direct answer

An MSP service request form template should collect client organization, requester, service category, affected user or asset, site, business impact, urgency, required approval, attachments, and PSA or workflow mappings before the request becomes a ticket or automation job.

Best for

Use this template when the form is part of an operational workflow.

MSPs replacing shared inbox intake with structured customer portal forms.
Client-facing service requests that need PSA/RMM/Microsoft 365 context.
n8n, Make, Zapier, Power Automate, or PSA workflows that need clean request data.

Dynamic sources

Typical systems this template may need to read before n8n fulfills the request:

ConnectWiseHaloPSAAutotaskNinjaOneMicrosoft 365CIPPn8n

Field structure

Fields this form should include

Field	Purpose
Client organization	Scopes the request to the right customer, tenant, and integration mappings.
Requester	Captures the portal user or external contact making the request.
Service category	Routes the request to ticket intake, access, license, onboarding, approval, or maintenance workflows.
Affected user, site, or asset	Loads customer-specific options so the workflow gets stable source IDs.
Impact and urgency	Supports priority calculation without parsing a long description.
Approval and attachments	Captures signoff and supporting evidence before fulfillment.

Approval notes

Use approval for access, licensing, purchases, scheduled maintenance, security changes, and any service request that creates customer-visible risk or spend.

Webhook notes

Send organization mappings, PSA company/site/contact IDs, selected asset or user IDs, priority inputs, approval state, and submission ID to the receiving workflow.

Implementation order

Build the form first, then wire the workflow.

Map each client

Store PSA, RMM, Microsoft 365, and automation mappings on the customer organization.

Build request categories

Use service categories that route cleanly to the right ticket board or workflow.

Wire live customer data

Load sites, contacts, users, devices, tickets, or licenses from source systems through webhooks.

Publish to the portal

Expose the form in the customer portal or through scoped links, then test final webhook delivery.

MSP forms glossary MSP form production checklist MSP form builder MSP customer portal