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 the Requirements step of the service wizard, after pricing and gallery.
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: “Waiting for 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 |
| Number | Quantities: word count, number of pages, revisions wanted |
| Yes/No | Simple confirmations: do you already have a logo? |
| Dropdown | Constrained choices from a list: preferred tone (formal / casual / playful) |
| Multiple choice | One answer from a few visible options: the platform to design for |
| File upload | Source materials: brand guidelines PDF, raw audio, existing logo |
| Date | Deadlines and launch dates |
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.
Let the question explain why you are asking. Each requirement has a label, an answer type, a required switch and, for choice fields, a list of options. There is no separate helper-text box, so the reason has to live in the question itself. “Which competitor logos should we avoid resembling?” gets better answers than “Competitors”.
Keep the form to roughly five to eight fields for most service types. Beyond that, buyers start abbreviating to get through it. The free plugin allows five requirement fields per service and Pro lifts that ceiling, so on free the discipline is built in. 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, where the order shows the state “Waiting for Requirements” and a Submit Requirements button leads to the form.
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 automatic reminder emails to buyers who have not submitted requirements, 1, 3 and 5 days after purchase. The reminder links directly to the order detail page and the pending form. No manual follow-up required from vendor or admin.
You can also set a requirements timeout in your marketplace settings. After the timeout you set, the order either starts without requirements (the vendor is told to contact the buyer for the details) or is cancelled, depending on a second switch. The next section covers both.
When the buyer never answers
Every unanswered order passes through the same sequence, and each step is something you can tune. Knowing the sequence lets you decide how patient your marketplace should be.
- Payment clears and the order moves to Waiting for Requirements. The delivery clock has not started.
- One, three and five days after payment, the buyer gets a reminder by in-app notification and email. The vendor is told about the first reminder, so they know the delay is on the buyer’s side.
- When the requirements timeout is reached, the plugin acts. The timeout ships at seven days, and setting it to zero makes the order wait indefinitely.
- With auto-start on (the default), the order moves to In Progress without requirements and the vendor is told to contact the buyer. With auto-start off, the order is cancelled and both sides are told.
The default leans towards keeping the sale: a buyer who forgot the form should not lose the order, and the vendor should not lose the work. If your services truly cannot begin without the brief, such as a custom build that needs access credentials, switch auto-start off so the order cancels instead of drifting.
With the shipped defaults, the last reminder lands on day five and the timeout acts on day seven, so a buyer gets two days of warning before anything changes. The reminder days are fixed, so if you shorten the timeout below five days, the later reminders never go out, because the order has already left the waiting state.
There is also an “allow late requirements” setting, off by default. When it is on, a buyer whose order was auto-started can still send their details afterwards, which suits flexible services where work can begin on assumptions.
A worked example: a logo service
Take a vendor selling a logo package. This is an illustration, not a template you have to copy, but it shows how the answer types pair with the questions.
| Question | Answer type | Required |
|---|---|---|
| What is the company called, and what does it do? | Long text | Yes |
| Which style fits best? | Multiple choice | Yes |
| Do you already have a logo? | Yes/No | Yes |
| Upload anything we should keep or avoid | File upload | No |
| When do you need the final files? | Date | No |
Five fields, three required. The vendor can start from this brief without a follow-up message in most cases. The existing-logo question tells them at a glance whether this is a refresh or a first design, and the date field flags rush jobs before the delivery clock starts.
For the style question, the options are typed in as a comma-separated list, for example “Minimal, Playful, Corporate, Hand-drawn”. Keep that list short and mutually exclusive, because a buyer who cannot decide between two overlapping options will pick the first one.
Mistakes that cause weak briefs
- Asking for everything up front. A required field that the vendor does not actually need becomes an obstacle, and buyers fill it with filler.
- Using one generic form for every listing. The form belongs to the listing, so a logo service and a social media template service should ask different things.
- Leaving the choice lists vague. “Other” as an option with no follow-up field tells the vendor nothing.
- Treating the form as a contract. The answers are stored on the order, but if the buyer later wants something outside them, that is a revision or a new order, not an automatic obligation.
- Never reading the answers back. After the first few orders, check what buyers actually typed. The gaps in their answers show you what to rewrite.
What the vendor and the admin see
Once the buyer submits, the vendor sees each answer beside its question, with download links for uploaded files. The site owner sees the same answers on the order screen in the admin, and the dispute screen shows the brief next to the deliveries, so whoever settles an argument is reading the same words the vendor worked from.
A service with no questions still gets a requirements step. The buyer is sent to a generic form where they can describe what they want and attach files, so the order never starts completely blank.
File uploads follow your site-wide rules. The allowed file types and the maximum size are set once under Settings, Advanced, and the form refuses anything outside them. That setting is where you would widen the list if your vendors ask for design or audio source files.
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), buy the service with a test payment method or with the offline gateway (the buyer uploads proof and you approve it, which marks the order paid), 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
Request mode (the buyer posts a brief and vendors propose) uses the same waiting state, but there is no vendor-defined form to fill, because the order did not come from a listing. After the buyer accepts a fixed-price proposal and pays, the order still waits in Waiting for Requirements until the buyer submits their details and any files. Milestone contracts are different: they start In Progress with no upfront payment, and each phase is paid as it comes.
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: “What is the one thing a client has had to be asked twice on past projects?” 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.
Where this fits in your marketplace
The intake form is one of the smallest settings with the largest effect on how smoothly orders run. The features page shows how it connects to messaging, deliveries and disputes, and the vendor overview describes the rest of what a seller sets up. If you run design work, the design services marketplace use case shows intake forms in a complete setup, and the guide to selling services online covers the surrounding decisions.
For a broader look at how an order moves from requirements submission through delivery and completion, see our guide to the full order lifecycle.