OnlyFans Custom Content Menu Template and Intake Rules

Direct answer: an OnlyFans custom content menu should tell a subscriber what request categories are open, what each option includes, which details change the scope, how many slots are available, the current turnaround range, and how to submit a complete request. Do not begin with a giant fixed price list. First collect the format, quantity or length, theme, personalisation, add-ons, deadline preference, and anything else needed to decide whether the request fits your page.

The menu below is designed to start a clear conversation. It does not choose your prices or decide the wider role of custom content in your business. Use the separate OnlyFans custom content strategy for the broader offer and fulfilment system, and the OnlyFans pricing strategy guide when you need to set your own numbers. This page owns the menu and intake handoff: request arrives, details become complete, then the creator accepts, clarifies, declines, pauses, or quotes.

Copy this editable custom content menu

Replace every bracket before posting. Delete categories you do not offer. Keep the public-facing menu short enough to scan in one message, then use the intake template in the next section to collect the detail. A category menu is usually easier to maintain than listing every possible combination.

CUSTOM REQUESTS — [OPEN / LIMITED / PAUSED]

I currently take requests for:
• Custom photo sets — choose a [theme / outfit / mood] from my available options
• Custom videos — choose a starting length and approved concept
• Personalised audio or voice notes — choose the style and approximate length
• Written or visual ratings — choose the format and level of detail

Standard scope includes: [one setup], [one approved outfit or theme], [standard editing level], and delivery within my current [X–Y day] turnaround range.

Variables that may change the quote: extra length or images, additional setups, outfit changes, props I do not already own, name use, a detailed script, specialist editing, a shorter deadline, or a request that cannot be reused.

Current capacity: [X custom slots this week / next opening is DATE]. To request one, DM me the word CUSTOM and I'll send the short intake questions. A request is not booked until I confirm the scope, total and delivery window.

This template separates the visible menu from the final quote. That matters because two requests in the same category can involve different quantities, setups, preparation and editing. The menu tells subscribers what is possible; the intake tells you what the individual request actually contains.

Build the menu with a custom-request scope matrix

Use this Custom Request Menu and Intake Matrix behind the public copy. It maps each category to included scope, quote-changing variables, capacity, turnaround and the questions required before a decision. The rows are examples of structure, not recommended prices or a list every creator should offer.

A useful scope line is observable. “Five photos, one available outfit, one setup, standard colour edit” is clearer than “premium custom.” Likewise, capacity should describe the unit that consumes your time. If video editing is the bottleneck, “two video slots” is more useful than “five customs.”

Send these intake questions before quoting

The intake should be short enough to answer in one reply but specific enough to expose missing work. W3C form guidance recommends putting instructions where people need them and stating the expected input clearly. The same usability principle applies in DMs: ask concrete, labelled questions instead of sending “tell me everything you want.”

Custom request intake

Thanks for asking. Send me these details so I can check the request and give you one complete quote:
1. Format: photo set, video, audio, written response, or other?
2. Quantity or length: how many images or approximately how long?
3. Concept: what theme, mood or scenario do you have in mind?
4. Personalisation: should I use a name, phrase, sign or specific detail?
5. Visual details: preferred available outfit, setup, angle or prop?
6. Script: do you have exact lines, an outline, or should I use my normal voice?
7. Delivery preference: standard turnaround, or is there a specific date you are asking about?
8. Reuse expectation: are you requesting a version made for you, or asking that I do not reuse the concept?
9. Must-have and flexible details: what is essential, and what can I adapt?
10. Budget range: what range are you comfortable considering?

Do not treat the answers as automatic approval. Read the full request as one production brief. If the person asks for a specific date, check your actual calendar. If they want a prop, verify that you have it. If a pronunciation or exact phrase matters, repeat it back in writing. If they leave a required field blank, ask one clarification round rather than guessing.

The budget question is optional when your public menu already shows exact starting totals. It is useful for outside-menu requests because it can reveal that the requested scope and the available range do not match. Respond by adjusting scope, not by inventing urgency or silently removing requested details.

Turn the intake into a one-message scope confirmation

Once the request is complete, summarise it before giving the next action. A good confirmation is brief enough to compare against the subscriber's answers and specific enough to become your production note.

Here's the request I have: [FORMAT], approximately [QUANTITY OR LENGTH], with [THEME/CONCEPT], [OUTFIT/SETUP], and [PERSONALISATION]. It includes [INCLUDED SCOPE]. The added variables are [ADD-ONS OR NONE]. My current delivery range for that is [RANGE], with [DATE] as the earliest available slot. The total would be [TOTAL]. If that matches what you want, reply CONFIRM and I'll send the booking step. If anything is wrong, change it now before I schedule the request.

Keep the total tied to a defined scope. If the subscriber later asks for extra length, a second setup or different editing, reopen the confirmation rather than quietly absorbing the change. The page-wide pricing decision belongs in your pricing system; this confirmation simply prevents the quote and the requested work from drifting apart.

Add the confirmed brief to your production board with an owner, status, due range and file location. The broader OnlyFans content calendar guide explains how scheduled content fits together. For custom work, make the status explicit: waiting for details, ready to quote, confirmed, scheduled, in production, ready to deliver, delivered, or stopped.

Use an accept, clarify, decline or pause branch

Every intake needs a next-state rule. Otherwise a menu becomes an open promise and half-complete requests pile up in the inbox. Choose one branch after reviewing the format, scope, capacity and requested timing.

Accept when the scope and slot are clear

Yes, I can take this in my [DATE/WEEK] slot. The confirmed scope is [SUMMARY], the total is [TOTAL], and the current delivery range is [RANGE]. Reply CONFIRM if that matches, and I'll send the booking step.

Clarify when one decision changes the work

I can review this, but I need one choice before I quote it: do you want [OPTION A] or [OPTION B]? That changes [LENGTH/SETUP/EDITING], so I don't want to guess.

Decline when the request is not a fit

Thanks for asking. I'm not taking that request. I can offer [CLEAR ALTERNATIVE FROM YOUR CURRENT MENU] instead, or we can leave it there.

Pause when capacity is the only blocker

That format is usually available, but my current custom slots are full until [DATE/RANGE]. I can message you when the next slot opens, or you can choose [LOWER-SCOPE AVAILABLE OPTION]. I won't book it before confirming the new window with you.

A decline does not need a long explanation. A pause should not pretend a slot exists. A clarification should ask only for the decision that is blocking the quote. These branches keep the inbox moving while leaving the creator in control of what enters the production queue.

Choose public prices, starting prices or quote-only menus

Live creator discussions show genuine disagreement about fixed menus. Some creators value the speed of visible categories and baseline prices; others prefer to quote only after hearing the request because the work varies too much. That community debate is useful evidence that there is no universal menu format.

Use public exact prices only when the included scope is genuinely standard. Use starting prices when one clean base package exists but add-ons vary. Use quote only when most requests are substantially different. You can also mix them: exact totals for a small photo package, a starting level for video, and quote-only for outside-menu concepts.

Whatever model you choose, make the label honest. “From [amount]” needs a real base package someone can buy at that amount. “Quote after intake” should lead to the short questionnaire, not an endless negotiation. Do not change the total merely because you think one subscriber can pay more for the same defined scope. If the scope or service level changes, name the difference.

Run a weekly menu and capacity check

1. Status: change the menu to open, limited or paused based on real capacity.
2. Categories: remove anything you no longer want to offer and add only options you can fulfil.
3. Scope: confirm every included quantity, length, setup and edit level.
4. Variables: list the details that create more production work.
5. Turnaround: update the range from your current queue rather than an old graphic.
6. Intake: check that every question still changes a decision you need to make.
7. Branch: keep current accept, clarify, decline and pause replies ready.
8. Handoff: make sure confirmed requests enter one production board instead of staying only in DMs.

If subscribers repeatedly ask the same missing question, revise the menu. If they abandon the intake at the same field, make that field easier to answer. If a category creates too much back-and-forth, tighten the included scope or move it to quote-only. The goal is not the prettiest graphic; it is a request you can understand, decide and schedule without reconstructing the conversation later.

Sources and editorial limits

The menu fields were compared against current public examples from Jaded MGMT, the Teasely menu builder, and CreatorFlow. The intake presentation follows the practical principle in W3C form instructions: state expected inputs clearly and place help where it is needed.

The fixed-menu versus quote-only section reflects a current creator discussion about not using a public tip menu. That thread is a personal account, not controlled proof of higher earnings or a rule for every page. The Custom Request Menu and Intake Matrix, sample wording, capacity fields and branch rules are a dated SirenCY editorial workflow. Test them against your real request volume and production time; no menu format guarantees orders, income or conversion.