Custom Content Quote Acceptance Record: Price, Scope and Change Requests

Direct answer: once a custom request is ready to quote, send one short record that names the deliverable, included details, total price, delivery window, payment or booking state, and the one reply that counts as acceptance. Save that exact version before production starts. If the subscriber asks for something new later, log it as a change request and send a revised record rather than trying to remember what the original quote covered.

This is an operating tool for creators, not a page of legal language. It helps you turn a DM exchange into a brief you can actually produce. Start with the custom content menu and intake template if the request is still vague, use the custom content strategy for the wider offer workflow, and keep your own number-setting process in the OnlyFans pricing strategy guide. This page owns the handoff between quote, acceptance, production and a later request to change the work.

Why a quote needs an acceptance record

A quote can become unclear when it is spread across several messages: a subscriber asks for a video, mentions an outfit two messages later, adds a name after the total has been sent, then asks whether a different deadline is possible. A single acceptance record gives both people the same reference point. It is not about sounding formal. It is about making the work visible before you reserve time for it.

The record should answer five practical questions: what will be made, what is included, what is not included, what is the total for this version, and what happens next. That lets a subscriber correct a misunderstanding before the request becomes a production task. It also gives you a clean note to place in your content board instead of relying on a long DM thread.

A clear record is especially useful when your public menu uses starting points or categories. The menu describes the types of work you may take. The quote record describes one defined request. OnlyFans has told Ofcom that creators set the price for custom content and interactions within the platform's terms, so the record should reflect your selected price and boundaries rather than a generic rate card. OnlyFans' response hosted by Ofcom supports that narrow platform context; it does not prescribe a price, fulfilment policy or quote template.

Build the record from one completed request

Do not create a quote from shorthand such as “custom vid, red outfit, urgent.” First turn the request into a completed brief. Ask for the format, agreed quantity or length, concept, personalisation, available wardrobe or setup choice, any essential detail, and a delivery preference. If one detail changes the work, put it in the record. If it is only a preference you have not agreed to include, label it as a preference instead of silently treating it as a promise.

Use clear field names. The general design principle is useful even when the record lives in a direct message or spreadsheet: W3C's form guidance says labels should identify the purpose of an input and that instructions should make the expected information clear. That is why “delivery window” is stronger than “timing,” and “included spoken line” is stronger than “notes.” See the W3C form-label guidance, updated 13 May 2024 for the broader usability principle.

Give the request a reference ID that means something in your own workflow, such as CC-2026-07-28-04. Do not use the subscriber's legal name in a shared production board. A screen name, internal order number or another privacy-conscious identifier is usually enough for the creator to connect the record to the conversation.

Copy the quote acceptance record

Copy this message only after you have decided the request fits your availability and boundaries. Replace every bracket. Delete a field if it is not relevant, but do not delete the fields that identify scope, total, version, delivery window and acceptance state. The goal is a concise production brief, not a long negotiation recap.

CUSTOM QUOTE RECORD — [REFERENCE ID] — VERSION 1

Deliverable: [format] — [quantity or agreed length].
Included scope: [one setup / agreed outfit / agreed concept / agreed personalisation / standard edit].
Not included in this version: [extra length, second setup, new script, rush change, exclusivity, or none].
Creator notes confirmed: [repeat the must-have detail or say none].
Total for version 1: [currency and total].
Delivery window: [your stated range or date range after acceptance].
Booking state: [awaiting acceptance / accepted / scheduled].
Acceptance step: Reply ACCEPT [REFERENCE ID] if this matches your request. If you want to add or change anything, send it before accepting so I can confirm whether the scope, total or delivery window changes.

Keep the acceptance step deliberate. A heart reaction, “okay,” or a fresh idea is not as easy to retrieve later as a reply tied to the record ID. The wording above gives the subscriber a straightforward branch: accept the stated version or request a revision before it is scheduled. Use the payment and delivery process that is appropriate for your page and the platform's current rules; do not use this template to make promises that conflict with them.

The total should be the total for the defined version, not a partial figure that later needs explanation. Put it beside the current deliverable, included detail and delivery window so the creator can compare one complete version before accepting it. If any of those fields changes, issue a new quote version instead of adding a loose note to the old one.

Make scope observable before accepting it

Scope is observable when another person could read the record and identify the unit of work. “A custom video” is a category. “One video in the agreed length band, one available outfit, one setup, one agreed concept and one name use” is a version you can produce. The same distinction applies to photo sets, audio, written responses and live-style requests.

Add a short “not included” line even when there are no extras. It prevents a reasonable-looking idea from becoming an unstated obligation. If exclusivity, a restriction on reuse, an added scene, a different location, an additional edit or a new deadline matters to either person, name it and decide whether it belongs in this version. Do not infer it from a casual phrase such as “just for me.”

Use a separate change-request log

A change request is not a bad customer interaction. It is any request made after the record is accepted that would alter the deliverable, included detail, total, delivery window or production plan. Treat it as a new decision point. Keep the original record intact, then add a short log entry that says what changed and whether version 2 replaces version 1.

CHANGE REQUEST — [REFERENCE ID] — CHANGE 01

Submitted: [date or time].
Requested change: [plain description].
Effect on scope: [no change / added work / removed work / different work].
Effect on total: [unchanged / revised total to be confirmed].
Effect on delivery window: [unchanged / revised window to be confirmed].
Decision: [accepted into version 2 / declined / needs clarification].
Next action: [send version 2 / continue version 1 / ask one question].

If the change does not alter the agreed work, you can record “no scope change” and continue. If it does alter the work, send a fresh quote record with a new version number and the same reference ID. Do not start the changed work while the version is still unclear. That boundary is practical: your production list should show one current version, not several competing requests in the same notes field.

Test the acceptance record with one controlled quote

The following example teaches the record format only. It does not recommend a price, a turnaround time, a package, a policy or an expected result. Imagine a creator receives a completed request for one short custom video with a named greeting, one available outfit and one setup. The creator chooses their own total and window after checking the calendar.

After acceptance, the subscriber asks for a second setup. That is not a note to tuck into the original brief; it is Change 01. The creator checks the added work, responds that it needs a revised version, and sends Version 2 with the changed setup count, the creator-selected revised total and an updated window if needed. The subscriber then accepts Version 2. The production board now points only to Version 2, while Version 1 remains a record of what changed.

These are teaching inputs, not recommended prices, turnaround times, policies or outcomes.

Move accepted work into the production calendar

Acceptance should create a real production task, not just a saved DM. Add the reference ID, current version, deliverable, delivery window, status, source-message location and file-delivery location to your board. A simple status sequence is: awaiting acceptance, accepted, scheduled, in production, quality checked, ready to deliver, delivered or paused. Use the OnlyFans content calendar planning guide when you need to place that work alongside your recurring feed, promotional and batch-production tasks.

Before marking a task in production, compare the board entry against the latest accepted record. Before delivery, compare the final file against the included scope. This is not a claim that a record eliminates errors. It is one repeatable last check: current version, stated deliverable, included detail and destination all match the production task.

Limitations: keep this as an operating record

Limitations: this template is an editorial workflow, not a platform feature or a price calculator. It cannot decide the right price, confirm account tools, make an unclear request producible, or guarantee that a subscriber will accept a version. Its job is narrower: preserve the current quote, its scope and the next operating action.

The record also cannot solve a vague request by itself. If the concept, length, essential detail or delivery expectation remains unclear, return to intake and ask for the missing information. If you do not want to make the work, decline it clearly rather than trying to turn the form into a workaround. Its useful job is smaller: make the agreed version easy to see, accept, schedule and revise.

Use one current version and one next action

A good quote acceptance record reduces the number of decisions you have to reconstruct later. It gives you one current brief, a visible total tied to that brief, a delivery window you selected, and a clear response to a later change. Keep the message short enough to read in a DM and structured enough to copy into your work board.

Create the record after intake, wait for the stated acceptance, schedule the accepted version, and open a change log whenever the requested work moves. That is enough structure to protect your time without turning a custom request into a complicated process.