White-label automation for agencies: scoping a client workflow before you quote

What the one-page scope contains

1. Trigger: what starts the workflow (a form submission, a new order, a booking, a schedule) and how the data arrives: a webhook, polling, or the source system’s own trigger. Note the expected volume in the client’s own words, for example per day or per week.
2. Systems: name every connected system, the exact account or workspace and the plan it is on. Some API features and limits depend on the plan, so check that the operations you need are available on it before you quote.
3. Field mapping table: one row per field: source field, target property (by internal name, not label), transformation (trim, lowercase, date format, value mapping) and what happens when the field is empty.
4. Deduplication key: which field identifies the same person or record (for example a normalised email for a contact; account for shared or changing addresses), and what an update may overwrite. Decide in advance whether a returning contact keeps its owner and original source.
5. Routing rules: write the conditions as a table, with a default for anything that matches none of them.
6. Failure behaviour: what is retried, where a record goes while the target system is down, who is alerted in which channel, and how a stored record is replayed without creating a duplicate.
7. Acceptance tests: a short list of named cases with expected results: new record, duplicate, invalid input, spam, target system down. The work is done when these pass, not when the workflow “runs”.
8. Out of scope: list what is not included, such as backfilling historical records, extra systems or reporting dashboards.

Access, accounts and ownership

• Agree who owns each account. Credentials should belong to the client’s accounts, or to an account the client controls, not to a freelancer’s personal login.
• Ask for access with the narrowest permissions the workflow needs, for example a private app token or API key limited to the required scopes.
• Decide where the workflow runs: the client’s n8n Cloud account or self-hosted instance; if considering agency hosting, first confirm licensing for that use. This decides who carries the hosting cost, who sees execution data and who can step in when something breaks at night.
• If the workflow processes personal data, assess controller and processor roles according to who determines the purposes and means; the client is not automatically the sole controller. Check applicable GDPR or KVKK obligations, required contracts, subprocessors and data transfers.
• Some setups need the client’s own identity or approval, such as authorising an OAuth connection in the client’s account; provider verification requirements can vary by product and use case. Put these on the client’s task list with dates; they can block the build.
• Check the licences of your tools. Distinguish workflow consulting on a licensed client instance for that client’s internal use from reselling n8n itself. The Sustainable Use License does not authorise selling access to n8n as a hosted or rebranded product; obtain separate commercial permission from n8n for that model. Agency-branded services and documents do not grant rights to rebrand the n8n interface; preserve licence notices. Check the licence text and OEM terms, and confirm unclear hosting models with n8n.

Briefing a design partner instead? See the white-label production brief.

What makes the work grow

Quoting is easier when you know what makes a workflow bigger. Check these before you quote:

• Number of systems and direction: a one-way handoff from a form to a CRM is smaller than a two-way sync between two systems.
• Unknown APIs: a system without a documented API, or one you have not used before, needs a short trial before a fixed quote.
• Data quality: free-text fields, inconsistent dropdown values and duplicates already in the CRM need cleaning rules.
• Historical data: backfilling old records is a separate job with its own rate limits and checks.
• Branching: every routing rule and exception adds test cases.
• Test environment: prefer a separate test environment or synthetic data. If a live test is necessary, agree client authorisation, limits on outgoing messages and side effects, rollback and test-record cleanup beforehand.

Quote a fixed price against the written scope, and handle anything outside it as a separate change request. This helps manage the effect of scope changes on costs and expectations.

Handover under your brand

• A one-page overview: what the workflow does, what triggers it and which systems it touches.
• The field mapping table and routing rules as delivered.
• What an alert looks like and what to do when one arrives.
• If it was in scope, how to change a routing rule or an owner without editing the workflow logic.
• The acceptance test results and the date they were run.

Name workflows, nodes and credentials neutrally (client and purpose), so the documentation reads as your agency’s own.

How we work

We build this kind of single-workflow lead handoff for agencies, white-label, starting from a written scope and agreed acceptance tests; the package is described on the agency partners page. To see how we run our own lead intake, inbox triage and alerts on n8n, read how we run Minimolo on n8n.

Related project and service