An upload field creates work on both sides. Someone must find the right file. Someone else must receive it, locate it and use it for a decision.
Name that decision before adding the field. If a short answer is enough for the first reply, keep the file request for later. Finish this exercise with an attachment decision card: purpose, timing, minimum contents, receiving owner and the evidence still needed.
The menu-layout studio below is fictional. Its files, limits and cases are planning examples. No upload, storage process or review has been implemented or tested.
Decide what the file changes
Complete this sentence:
The reviewer needs [specific contents] to decide [next decision]. Without them, the next step is [honest alternative].
“Useful background” is too broad. Ask whether the same decision could be made from a short description, an existing record or a later conversation. Also check whether the business already has the exact version it needs.
GOV.UK's file-upload guidance advises asking for an upload only when it is critical to delivering the service. For this exercise, treat that as a reason to challenge the request, not a reason to collect every document that might become useful.
Choose omit, request later or request now. Write why. A later request still needs a workable receiving process; moving it into an email does not settle access, handling or responsibility.
Worked example: a menu-layout enquiry
A fictional studio receives a request to reorganize a café's menu. Its first reply checks service fit and asks which menu needs work. A description is enough for that reply. The studio chooses request later and leaves an upload off the initial enquiry form.
After that conversation, the reviewer needs to see the current page layout to discuss the proposed reading order. This is a narrower request than “Upload your business documents.” The proposed artifact is the café's current two-page menu, with unrelated notes removed.
| Decision-card field | Fictional plan |
|---|---|
| Next decision | Identify which parts of the current page order the café wants to change |
| Requested contents | Current two-page menu, showing its existing layout |
| Timing | After the initial service-fit reply |
| Intended format and limit | One PDF, up to 5 MB, subject to receiving-process verification |
| Review owner | Studio enquiry coordinator, then the assigned layout reviewer |
| If no suitable file is available | Continue the conversation and agree another approved way to show the layout |
One PDF and 5 MB are invented planning choices, not universal recommendations or ClickFunnels AI limits. The owner must check that the receiving route can support them before publishing those instructions. A filename alone does not establish that the attachment contains the right menu or version.
Ask for the minimum useful contents
Describe what should appear in the file and what should stay out. For the fictional request, the draft instruction is:
Share the current two-page menu that shows the layout you want to discuss. Remove unrelated customer, staff and account information. If you do not have a suitable file, tell the coordinator before sending a substitute.
That instruction defines the content. Format, number and size instructions belong beside it once verified. Add a clear label for the file control and state whether the attachment is required at that particular step. W3C's form-instruction guidance covers explaining requirements and data formats in ways people can use with the controls.
Avoid “anything relevant.” It transfers the selection problem to the visitor and leaves the reviewer guessing. Avoid requesting access credentials, a private account export or unrelated records to make this example work. Use material the sender is authorized to share through the approved route.
Settle the receiving process before using the request
Give the implementer and operating owner the same card. They need to establish where the file goes, how it stays associated with the correct enquiry and who can retrieve it for the stated purpose.
Record the approved handling rules and their owner, including what to do with an unnecessary or incorrect file. Do not invent a deletion period, security guarantee or scanning feature in the page copy. If those decisions are missing, mark them unresolved and keep the proposed request out of use.
Also decide what happens when the file is unsuitable. A different format, an unreadable document and an unknown transfer result are different conditions. Use specific instructions only when that condition is known. Do not tell someone to compress a file when the actual problem has not been identified.
Keep selection, receipt and review separate
Prepare four checks before implementation. Use a harmless fictional sample and an authorized environment when the checks are eventually run.
Scroll horizontally to compare all columns.
| Case | Planned situation | What needs to be established |
|---|---|---|
| A01 | A suitable PDF is selected | The intended file is associated with the right enquiry, and the assigned reviewer can retrieve and read it |
| A02 | The requester has no suitable file | The stated alternative remains available; the conversation is not falsely described as complete |
| A03 | The requester selects a file outside the agreed rules | The known restriction is explained and a usable next step is available |
| A04 | The transfer result is unknown | The responsible owner can investigate the existing attempt before advising another submission |
Selecting a local file is not evidence of receipt. A receipt message is not evidence that the assigned reviewer can open the correct document. Even a readable file does not prove the layout discussion or requested service has happened.
For each check, record the expected state, observed evidence, enquiry identifier and person who can resolve a mismatch. Keep the status NOT RUN until it is performed. If the evidence ends at receipt, leave reviewer access unknown rather than calling the whole attachment journey passed.
A04 needs particular care. Repeating the request could create another copy without explaining the first attempt. The plan should name who checks the receiving side and what that person needs to identify the attempt. It should not promise automatic duplicate handling.
Hand over one request, not an open collection box
Use the attachment-planning worksheet for one decision and one requested artifact. It includes the filled menu example, four case records and blank space for your own process.
Read the card with the person who will use the file. Can they explain why they need it now, what makes it sufficient and what happens when it is unavailable? Resolve those questions before turning the plan into an upload field or a request message.
For a ClickFunnels AI project, carry the card into the project instructions and consult the agent guide for workflow and access requirements. This worksheet does not establish that uploads, storage or a receiving integration are available in your account. It grants no builder access and sends nothing. The next useful result is a precise request with an owner and explicit implementation checks.