Custom Content Scope Confirmation Form: Deliverables, Boundaries and Approval

Before you accept a custom request, turn the message into a shared written scope that names the deliverable, excludes what you will not make and records the buyer's approval. A request message is usually a starting point, not a production brief. This form gives a creator a repeatable way to move from an open question to one bounded instruction: clarify the ask, write what is included and excluded, confirm the version, put it into the calendar, then close it with a delivery record. It is deliberately operational. It does not set prices, promise a result or turn every request into work you must accept.

Treat the request message as intake, not approval

A buyer may ask for several things in one line: a format, a theme, a personal detail, a date and an assumption about what is included. If you simply answer “yes,” you have not created a shared definition of done. You may remember one interpretation while the buyer expects another. The practical fix is to separate intake from approval. Intake captures what the buyer wants to explore. Approval captures only the deliverable you have agreed to make.

Read an incoming request once for the decision it requires. Is the format clear? Is the quantity clear? Are there details you need before you can schedule it? Does the request contain something you will not include? Is there a time-sensitive assumption? Do not solve every question in your first reply. Mark the request Clarifying and ask only for the details that change the production instruction. This protects your attention as well as the buyer's expectations.

Keep the form in one location you actually use: a spreadsheet, task board, notes template or request database. Each record should have one request ID and one current version. That small discipline matters when several requests are open at once. It lets you see what has been approved, what is waiting on the buyer and what can be scheduled without reopening old messages.

Build a scope that can be delivered without guesswork

The best scope is concrete enough for you to produce from and short enough for the buyer to read. Start with the approved deliverable, not a description of the entire conversation. “One private video with the agreed outfit and approved name mention” is a scope field. “Something cute and personal” is an idea that needs clarification. The form should translate the second into the first before you accept production.

Next, write boundaries as exclusions and limits. Exclusions answer what the request does not contain. Limits answer how much of an included element is covered. For example, a scope can include one approved name mention while excluding extra names, new scenes or a reshoot. It can include one correction for a clear production error while excluding a creative rewrite after delivery. You are not trying to make a hostile document; you are making the decision legible before work begins.

Keep offer design separate from scope confirmation. If you need to decide what kinds of customs you want to make available in the first place, use the OnlyFans custom-content menu template. Once a buyer asks for something, this form narrows that broad menu into one specific deliverable, one set of exclusions and one approval moment.

Copy this scope confirmation form

Copy the fields below into the tool where you manage requests. Use plain language in the buyer-facing confirmation and keep internal notes separate if they are only useful to you. A field may be empty in Draft, but no request should move to Approved for production while the approved deliverable, exclusions, delivery window and approval record are still blank.

Use a two-step approval message

Two short messages are often enough. The first is a clarification message. It reflects the request back in neutral language and asks for the missing choice. The second is the confirmation message. It lists the approved deliverable, the important exclusions, the buyer action still required and the delivery window. The buyer should be able to reply with a clear approval rather than trying to infer what your “sounds good” meant.

Save the buyer's explicit approval alongside the exact version they approved. If they change a meaningful field after approval, do not bury the change in a follow-up. Move the record back to Re-scoped and re-approved, update the version and send a fresh confirmation. A new detail can affect your calendar, what is excluded or whether the request is still one you want to take on.

Worked example: a bounded custom request

Imagine a buyer asks for a “personal custom with my name, a specific outfit and a few extra ideas.” That is enough to open an intake record, but it is not enough to schedule. The phrase “a few extra ideas” is undefined. The creator can reply with a clarification choice instead of trying to price, plan or promise every possible extension in the same conversation.

This is an operational example, not a recommended price, service level, platform feature or claimed creator outcome. Its job is to show the difference between an open request and a confirmed instruction. Notice that the example does not promise an undefined “extra.” If the buyer asks to add an element after approval, the creator can decide whether to decline it, make a new version or place it in a later request. The form makes that choice visible instead of accidental.

Put approved work into the real production calendar

Approval is not scheduling. Once a request is approved, check the production dependencies and reserve the work in the same calendar that holds your regular posts, message time, admin and time away. Do not schedule from a blank mental picture of your week. The OnlyFans content calendar planning guide explains the wider calendar system; this request record should point to one actual production block and one delivery check.

Plan from the approved version, not the buyer's original note. If the record says a buyer action is required, leave the request in Awaiting approval or Awaiting buyer detail until it arrives. If a prop, setup or current platform-process check is unresolved, mark the dependency and pause production. This prevents the common operational mistake of shooting something close to the request while a key choice is still missing.

Keep custom production distinct from a broader release plan. A custom is a confirmed individual instruction; a PPV launch needs offer, timing and tracking decisions across a wider audience. When you need the latter, use the OnlyFans PPV launch checklist rather than blending the two workflows into one request record.

Close the request with a delivery record

A custom request is not complete when the file exists on your device. Close it only when the approved version is delivered through the recorded channel and you save a simple delivery record. Record the date, version, delivery channel and any permitted correction. This turns the form into a usable operating history. You can later see whether missed windows came from unclear approval, calendar crowding, a missing buyer action or a change that should have created a new version.

Review closed records for process friction, not for a vanity score. Count how often you had to ask for the same missing detail, how often a buyer asked for something that was already excluded, how many requests stalled before approval and how many required a re-scope. Those are signals to improve the form or menu language. They do not prove demand, satisfaction, revenue or performance on their own.

Use one modest improvement at a time. If name spellings are repeatedly missing, add a mandatory name field. If buyers assume an extra item is included, tighten the exclusion line. If delivery windows are impractical, change the calendar rule before accepting the next request. A versioned form makes these changes traceable and protects a creator from trying to remember a different rule for every conversation.

A five-minute request triage routine

1. Create a request ID and paste the buyer's ask into the intake field.
2. Mark the request Draft or Clarifying; do not treat an initial message as approval.
3. Write one proposed deliverable, then list the included limit and excluded elements.
4. Check what buyer action and production dependencies remain before scheduling.
5. Send the clarification or confirmation message and save the response.
6. On explicit approval, move the request to Approved for production and reserve a real calendar block.
7. Deliver the approved version, save the delivery record and select the close state.
8. When a meaningful field changes, create a new version instead of editing history.

This routine stays intentionally small. It gives you a repeatable path from enquiry to approved work without turning every custom into a long negotiation. A concise record can be more protective than a long thread because it tells both people what is being made, what is not being made and what has to happen next.