Practical guide

Define a service before you automate its delivery

Last materially reviewed 2026-09-19

Quick answerA service needs an output, a boundary and an acceptance rule before it needs a checkout page.
What to know

Setup checklist: start with the deliverable

Describe what the customer receives in a sentence that a producer and client would interpret similarly. “Design support” is too broad; “one approved campaign graphic in the agreed sizes” is more useful. Then specify what starts the work and what ends it. ManyRequests can represent services, but software cannot decide what your agency intended to promise. Set that expectation before translating it into fields, limits or a catalogue entry.

What to know

Put exclusions beside inclusions

For an invented creative package, separate production from strategy, source-file handover, copywriting and paid stock assets. Do not hide important exclusions at the end of an unrelated document. Ask a teammate to read the offer and invent an awkward request. If the team disagrees about whether it is included, revise the service definition rather than expecting a form or automation to make the judgment later.

What to know

Make one acceptance example

A useful acceptance record might say: final version V3, approved by the named client contact, delivered in the agreed dimensions. That is our example, not a required ManyRequests data model or legal contract. A customer saying “looks good” under an earlier version may not settle a later change. Keep the accepted brief and the delivered version connected so both parties can understand what was completed.

What to know

Translate the promise into configuration

Only now choose the service type, request form and operating limits. Use a fictional request to check that the client sees the same promise the team will deliver. If a platform setting cannot express an important boundary, document the manual check and its owner. Do not describe the process as automatic while relying on an unassigned person to prevent overselling or clarify every new request.

Continue when useful

Next: Retainer or project: which unit should the client buy?

Use a retainer for recurring access or capacity; use a project when a defined output and endpoint are the real promise.

Open Retainer or project: which unit should the client buy? →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. ManyRequests service pricing configurations — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
  2. ManyRequests recurring service configuration — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19