The most common source of disputes and late deliveries in service marketplaces is not vendor skill - it is vendor work starting before the brief is complete. A designer who begins on a logo without knowing the brand colors, usage context, and file formats is doing speculative work. When the revision requests arrive, they reflect the gap between what the buyer assumed and what the vendor assumed - not a quality failure.
WP Sell Services handles this at the architecture level. Requirements collection is a first-class order state, not a note field or an afterthought. An order does not move to “In Progress” until the buyer has filled the intake form the vendor defined. This guide explains how to set up that form, what happens on the buyer side, and how to tune it so vendors get the information they actually need.
How the intake form connects to a service listing
Every service listing in WP Sell Services has an intake form attached to it. Vendors define the form questions when they create or edit a service. There is no separate “form builder” section to find - the form fields are part of the listing edit screen, directly below the package pricing configuration.
The form is unique per listing. A graphic designer might have one form for logo projects (questions about brand voice, color preferences, competitor logos to avoid) and a different form for social media templates (questions about platform dimensions, brand assets, posting cadence). Each listing carries its own set of questions.
When a buyer purchases the service, WP Sell Services does not immediately move the order to “In Progress.” It enters an intermediate state: “Awaiting Requirements.” In this state the vendor cannot begin work because the platform has not surfaced the buyer’s brief yet. The buyer receives an email prompting them to complete the intake form before the countdown begins.
This is not a courtesy feature. It protects vendors from scope creep and protects buyers from clock-ticking without having provided what the vendor needs.
Setting up the intake form fields
From the vendor’s listing edit screen, the intake form section lets you add fields of several types:
| Field type | Good for |
|---|---|
| Short text | Single-line answers: company name, website URL, target keyword |
| Long text | Open-ended briefs: describe your audience, explain the context |
| Single select | Constrained choices: preferred tone (formal / casual / playful) |
| Multiple select | Multiple applicable answers: platforms to cover, file formats needed |
| File upload | Source materials: brand guidelines PDF, raw audio, existing logo |
| URL | Links to reference examples, Google Docs briefs, GitHub repos |
A few guidelines that reduce revision cycles:
Make fields required only when the work genuinely cannot start without the answer. If color preferences are required for a logo project, mark that field required. If “any other context” is optional, mark it optional. Overly long required forms slow buyers down and create the same problem from the other direction - buyers submit minimal answers just to pass the gate.
Use field descriptions to explain why you are asking. A field labeled “Competitors to avoid” with a description that says “We will review their visual identities so your brand does not feel derivative of them” gets better answers than the same field without context.
Keep the form to 5-8 fields for most service types. Beyond that, buyers start abbreviating to get through it. If your service genuinely requires 15 pieces of information, consider breaking the service into a discovery consultation as a separate first-tier purchase, then a delivery purchase where the brief is already built from the consultation.
What the buyer sees
After completing checkout, the buyer lands on their order detail page. The intake form appears at the top of the page under the “Requirements Needed” heading. The order timeline on the right side of the page shows the current state as “Awaiting Requirements.”
The buyer fills the form, uploads any files, and submits. At that moment:
- The order state changes to “In Progress”
- The vendor receives a notification that requirements are in and work can begin
- The delivery countdown timer starts (the delivery window the vendor set on their package)
- The form responses are attached to the order record permanently
Both vendor and buyer can view the submitted requirements from the order detail page at any time during the project. If a dispute opens, the requirements form is part of the context admin sees.
Automatic reminders for buyers who go quiet
Buyers sometimes complete checkout and then disappear before filling the intake form. This creates a stuck order that the vendor cannot work on and the buyer may forget about.
WP Sell Services sends an automatic reminder email to buyers who have not submitted requirements within 48 hours. The reminder links directly to the order detail page and the pending form. No manual follow-up required from vendor or admin.
If the buyer does not respond within the platform’s configured maximum wait period, the order can be cancelled and the vendor earns a cancellation fee if that is configured in your marketplace settings.
Checking that your forms work before going live
Before publishing a listing, test the intake form from the buyer side. The easiest way to do this is to set up a second test account (buyer role), purchase the service using a test payment method or with the price set to $0 temporarily, and walk through the full requirements submission flow.
Check these specifically:
- Each required field actually blocks submission if left blank
- File upload fields accept the formats you specified (the plugin respects MIME type restrictions)
- Long text fields wrap correctly on mobile (a common layout issue with forms that were built on desktop)
- The order state visibly changes to “In Progress” after form submission
- The vendor receives a notification with the requirements content attached
Requirements forms on buyer-request orders
The intake form system also works in request mode (buyer posts a brief and vendors propose). In this flow, the buyer’s original brief serves as the initial requirements document - it is stored on the order when the buyer accepts a proposal and completes payment.
If the vendor needs additional information beyond what the buyer posted in their request, the vendor can mark the order as requiring supplemental requirements. This surfaces a secondary intake form the vendor defines - useful for services that need technical specifics (server access, file formats, brand asset dimensions) that a general brief would not cover.
A practical approach for vendors launching their first listing
If you are setting up your first service listing on a marketplace running WP Sell Services, start with the minimum requirements form that would prevent the most common revision you have needed on past projects.
Ask yourself: “What is the one thing I have needed to ask a client twice in the past?” Make that a required field. Add two or three more fields that map to the next most common information gaps. Launch with that.
After a few completed orders, review the form. If buyers are consistently leaving a particular field vague or blank even though it is required, rewrite the field description. If you keep needing to ask buyers something that is not on the form, add it.
The intake form is easy to update between orders - changes apply to new purchases of the listing, and existing orders keep the requirements that were submitted when they were placed.
For a broader look at how an order moves from requirements submission through delivery and completion, see our guide to the full order lifecycle.