Handling Custom Content Requests: From Ask to Delivery

A custom request is the one message in an inbox that changes what a conversation is. Up to that point you are selling things that already exist. From that point you are holding an order: a named person, a promised date, and a piece that has no second buyer if anything goes wrong.

Handled well it is the most profitable thing in the thread. Handled loosely it becomes a refund, and a refund on a custom is a total loss, because there is nobody else to sell it to.

What do you do the moment a request arrives?

You write it down, before you answer anything. Not in the thread: on an order line the next shift can read. Five fields, and none of them optional.

Field	What goes in it	Why it exists
What	The piece, in enough detail to shoot from	Kills “that’s not what I asked for”
Price	One number, agreed once	Stops the price reopening after the shoot
Date	The day it will be delivered	The only part the fan can verify
Format	Length, orientation, sound or none	The cheapest dispute to prevent
Excluded	What is explicitly not in it	Where the creator’s limits get recorded

The last row is the one that gets skipped and the one that costs most. A brief with no stated exclusions is a brief where the boundary lives in one person’s memory, and the handover between shifts is exactly where that memory goes missing.

One thing not to do at this stage: agree. Confirming receipt is not accepting the order. “Let me check what’s possible and come back to you today” is a complete answer, and it is the only honest form of delay, provided the answer actually arrives when you said it would.

Which requests do you accept, and which do you turn down?

Put every request through four tests, in this order. The first failure ends it; there is no point pricing something that will never be shot.

1. Will the creator shoot it? She decides, not the inbox. Whoever writes on her behalf takes the brief; only she confirms it gets made.
2. Is it allowed? Platform rules and the law come before commercial judgement, and neither is negotiable in a DM.
3. Does it fit the calendar? If there is no reserved block, there is no date. See planning content production for how that block gets reserved in the first place.
4. Is it worth the disruption? A custom occupies a shoot slot that would otherwise have filled the catalogue. Below a certain price it is a favour, not an order.

Request type	Usual answer	Why
Clear brief, in scope, fits a block	Accept, quote, take payment	The straightforward case
Vague brief, in scope	Ask two questions first	An unclear brief is a dispute with a delay
Out of scope for the creator	Refuse in the first sentence	Nothing here is negotiable
Fits, but under your floor	Counter-offer at the floor	A cheap custom prices every future one
Urgent, no block available	Quote the real date or decline	Never invent a date to hold the sale

Refusing well is its own skill. How to say no without ending the thread is covered in saying no to a fan, and the short version is that a no in the first sentence beats a maybe in any position.

What lead time should you quote?

The one you can hold on a bad week, not the one you can hold on a good one. Build the quote out of four components rather than guessing at a total:

• Shoot slot. The next reserved block, not the next free day.
• Editing. Done in a separate block, and always longer than people estimate.
• Creator review. She sees it before the fan does, every time.
• Buffer. One deliberate margin for the week that goes wrong.

Then quote the sum, once, and put it on the order line. Two rules make the difference between a lead time and a wish. Never shorten a quoted date to close a hesitant fan: you have traded a sale for a likely dispute. And never quote a date that depends on the creator answering a message you have not sent yet.

How do you price and pitch it without breaking the close?

Price it at the top of your own ladder, one rung above catalogue work, because it is produced once and sold once.

What is specific to customs is the wording of the confirmation (the message that carries the PPV), and there is a measured trap in it. A custom is built out of personal detail: what he told you, what he asked for, the thing he mentioned weeks ago. Across 1.5M messages, a personal callback placed at the exact moment of the pitch costs conversion points. It is the most counter-intuitive result in our corpus, and the one placement rule that every chatter’s instinct pushes against. Build the piece out of the detail. Keep it out of the sentence that asks for money.

The two measured closing faults turn up more in custom confirmations than anywhere else, because people write them carefully, and care reads as hesitation. An ellipsis is the worst-performing ending in our corpus, and a closed question at the moment of closing costs several points of conversion. Both are broken down in how to end a sales message. On a custom they carry a second cost: they read as uncertainty about whether the thing will ever be delivered. Confirm with the object, the date and the price, and stop there.

What do you say when you cannot deliver?

You say it on the day it slips, in the first message, and you attach something real. The failure mode is never the delay itself: it is the silence around it, which from the fan’s side is indistinguishable from being ignored after paying.

What happened	What you say	What you do
Shoot missed, will happen	Same day, new date, one apology	Move the block, log the new date
Cannot be made at all	Say so plainly, offer the refund	Refund or replace, his choice
Partly deliverable	Describe exactly what exists	Deliver that, adjust the price
Slipping a second time	Stop rescheduling, offer the refund	Close the order rather than extend it

Three things hold across all four rows.

• Never let a promised date pass without a message.
• Never make a second promise more optimistic than the first.
• Record what was agreed where the next shift will find it. The handover note is the minimum, because a fan re-explaining an order he already paid for is a fan deciding how this ends.