How to handle custom requests from fans without overpromising

The safest way to handle a custom fan request is to pause before promising anything. First decide whether the request fits one clearly described offer. Then capture the minimum brief: what the person wants, the format, timing, revisions, intended use, and any boundaries. The creator or an authorized manager should confirm scope, price, availability, payment path, and acceptance. An AI assistant can recognize the request and prepare a handoff, but it should not negotiate, quote an unapproved price, collect sensitive information, or imply that the work is accepted.

Use the offer-ready test

A custom request is ready for a listing or intake form only when the creator can answer five questions without improvising:

1. What

   What exactly is delivered?

   Name the output, format, length, quality level, and whether the buyer receives a draft, final file, session, message, or physical item.

2. When

   When can it be delivered?

   Use a realistic turnaround range and state what happens if the creator becomes unavailable. Do not promise a date before checking capacity.

3. How

   How is the work requested and paid for?

   Choose one approved intake and checkout path. Keep the social DM for clarification, not for card details or an informal contract.

4. What not

   What will not be accepted?

   List excluded topics, rights, formats, deadlines, personal access, and requests that the creator cannot safely or legally fulfill.

If those answers are still changing from one fan to the next, the offer is not ready. Point the person to a general creator support page or a waitlist instead of selling an undefined promise.

Turn a vague DM into a useful request brief

“Can you make one for me?” is interest, not a complete order. The next step is a short brief that lets the creator judge fit without asking for unnecessary personal information. Use the same fields every time so the creator can compare requests and spot a recurring offer.

A brief is not permission to collect everything a fan may reveal. X's automation rules say to request only the minimum information needed and to explain how private information will be used. That is a good operational rule on any social channel: ask for the job, not a biography.

Example: convert the request before discussing price

The response does not promise that the creator is available, quote a price, or ask the fan to send a card number. It gives one next step and preserves the creator's right to review.

Define the offer before opening the inbox

Creators often think a custom offer is just a price attached to a request. In practice, the price is only one line in a small service agreement. Ko-fi's first-party commission guidance highlights listings, terms, available slots, and order management because each one prevents a different failure.

Price the work that happens after the request

Estimate the time for clarifying the brief, preparing the work, revising it, delivering it, and answering follow-up questions. Include platform and payment costs, taxes where applicable, refunds, and the time the creator spends on requests that are declined. Patreon notes that platform, processing, payout, and other fees can vary by plan, location, payment method, and currency; a headline price is not the same as take-home income.

Do not promise a result the creator cannot substantiate. If a custom service includes a performance, transformation, expert opinion, or brand endorsement, describe the deliverable rather than implying guaranteed results. The FTC's guidance is a useful check: qualifying information should be clear and close to the claim it qualifies.

Keep payment and private details out of casual DMs

A social message is a poor place to improvise a checkout flow. Move payment to the approved destination once the creator confirms that the request is accepted. Stripe's Connect documentation shows that the charge model affects how funds are split, whose account is charged for refunds and chargebacks, and what the customer sees on a receipt. Decide who owns those responsibilities before publishing the offer.

Ask only for information necessary to scope or fulfill the work. A creator may need a preferred name, an output format, or a reference file. They may not need a home address, identity document, account password, payment-card number, private relationship history, or unrelated personal details. Use the creator's privacy notice and the checkout provider's current policy to explain what is collected, why, and how support questions are handled.

For physical goods or services that require an address, explain who receives it and why. For digital delivery, do not collect an address simply because a platform form offers one. A narrow data path is easier to secure, explain, and delete.

Build an inbox workflow that knows when not to answer

Custom requests are a high-value handoff category. They often look friendly and routine, but accepting one can create a deadline, payment obligation, rights question, or personal boundary. The DM priority guide can help place them beside brand, payment, safety, and other owner-only conversations.

X's current automation rules require clear user intent before automated DMs, an easy opt-out, and thoughtful treatment of private information. Instagram's creator-AI guidance likewise makes the AI label and creator visibility part of the user experience and warns that replies may be inaccurate. These are practical reminders to keep automation narrow, visible, and interruptible.

Loresta can help with classification, approved factual answers, and owner handoffs. It should not turn a custom request into an automatic contract. Review the high-volume inbox playbook, set a response mode, and keep an explicit pause path before adding a new request category.

Use a four-state request ledger

1. New

   Intent detected

   Store the original message, creator profile, date, and request category. No acceptance has occurred.

2. Review

   Brief is being checked

   The creator confirms fit, availability, rights, price, and the correct private intake or checkout path.

3. Accepted

   Payment and delivery are defined

   Keep the order or agreement in the approved system and attach the stated deliverable and deadline.

4. Closed

   Delivered, declined, or refunded

   Record the outcome, unresolved issue, and any change needed before opening another slot.

Launch one request type before expanding

Use a small pilot that can teach the creator something without putting a large queue at risk. A seven-day setup is enough to test the promise; the delivery window may be longer.

1. Day 1

   Choose one job

   Pick a request with a repeatable output, a known audience need, and a format the creator already knows how to deliver.

2. Day 2

   Write the terms

   Set scope, price, turnaround, revisions, rights, exclusions, capacity, payment, and refund language. Ask for professional advice where required.

3. Days 3 to 4

   Test the path

   Run one test from DM to intake to payment to delivery. Check what the fan sees, which records are created, and where a creator can pause.

4. Days 5 to 7

   Open a small number of slots

   Track clarification time, accepted requests, declined requests, revisions, delivery time, support questions, refunds, and creator energy.

Use the DM workload calculator for the routine inbox estimate, but evaluate custom work with service metrics: minutes per delivered request, revision rate, on-time delivery, unresolved support, and the percentage of requests that did not fit. If custom work creates more exceptions than value, close the slots and keep the offer as a clear future option rather than forcing automation to rescue it.

Custom work can be a useful part of a creator's monetization plan, but it is not the only path. A digital guide, support option, membership, or fixed product may preserve the same audience interest with less scheduling and personal exposure. Give fans a specific next step while keeping the creator's judgment where it belongs.