Pick the point where the task stopped making sense. What were you trying to do, and what did you actually see?
You can prepare a useful request before you know the cause. The goal is one clear account of the problem, enough context for the right person to investigate, and a specific question that moves the work forward.
This exercise uses a fictional worksheet-link problem. No real customer issue, ClickFunnels AI defect or support response is being reported. Preparing the packet does not send it or give another person access to your project.
Name one task and one observed obstacle
Start with the visitor's task: “Open the current garden-layout worksheet from the page.” Then describe the obstacle: “The file that opens identifies itself as version 2; the page promises version 3.”
That is more useful than “My funnel is broken.” It is also more careful than “The hosting cache is broken,” which guesses a cause.
Mozilla's bug-writing guidance recommends a clear summary, precise reproduction steps and separate expected and actual results. Borrow those reporting principles. Its Firefox-specific instructions and reporting channels are not a setup process for your funnel.
If you have two unrelated obstacles, give each its own record. You can link related records later without making the first request describe every unfinished part of the project.
Write down why you expected a different result
An expectation needs a basis. It could come from the page's visible promise, the agreed project brief or the product's current documentation. Record which one you relied on.
In the fictional case, the page visibly promises worksheet version 3. The example's content owner also supplied version 3 as the intended file. Those assumptions establish the mismatch inside this exercise.
For your own project, “I thought this would send an email” may be an unanswered setup question. If no current plan or supported workflow establishes that email, ask what must be configured before declaring that delivery failed.
Use three fields:
| Field | What belongs here |
|---|---|
| Expected result | The specific result and its source |
| Actual observation | What you saw, including the displayed wording or file identifier |
| Unknown | Cause, wider impact or later outcome you have not established |
A screenshot of a confirmation cannot establish what arrived in an inbox. Keep the evidence attached to the stage it actually shows.
Keep enough context to locate the problem
Record the product name, relevant host and page or project reference. Distinguish an editor, a preview and the public page. A problem seen in one place has not automatically been reproduced in the others.
For ClickFunnels work, use the intended product's own documentation and access path. The product-and-connection guide helps separate a CFAI task from intentional work in an existing ClickFunnels product. A similar product name is not enough to assign a support request.
Add the browser and operating system versions if known, the approximate occurrence time with time zone, and the page or file version. Write unknown for a missing detail. Do not guess a browser version to make the packet look complete.
Keep restricted identifiers in the appropriate private work area. A shareable summary can use a neutral project label and say that the exact reference is available through the team's existing authorized channel.
Work through a fictional request
Here is a prepared example. Every observation and artifact is invented. There is no downloadable sample PDF or actual screenshot attached.
Summary: Garden-layout page opens worksheet v2 while promising v3.
Task: Open the current worksheet from the page's main resource link.
Context: Page draft G3 in an agreed review environment. Desktop browser and operating system versions are unknown and need to be supplied if this becomes a real report. Fictional occurrence: October 10, 2026, at 10:15 in America/Chicago.
Starting state: G3 is open at its introduction. No form, checkout or account action is involved.
Steps recorded in the example:
- Read the text beside “Open the layout worksheet.”
- Activate that link.
- Read the version identifier on the opened file.
Expected: Version 3, matching the page copy and the content owner's intended file.
Fictional actual observation: The opened file identifies itself as version 2.
Repeat history: One occurrence is represented. A second attempt and other browsers are not checked.
Impact observed: The reviewer cannot confirm that this page leads to the intended worksheet. No count of affected visitors or lost enquiries is known.
Prepared evidence list: A cropped image of the link and nearby version promise, plus the file's visible version label. These are suggested evidence types, not files created for this example.
Question for the page owner: Please check which file this link should target, then identify the page version and file to use for a recheck.
The request gives someone a starting point without claiming the cause, assigning blame or predicting how quickly it will be fixed.
Decide whether another attempt is appropriate
You do not need to keep repeating an action to deserve help. First identify what another attempt could do.
Opening a known review file may be a reasonable check. Repeating a form submission, payment, publish action or message send can create additional effects. If the consequences or permission are unclear, stop and report the observation already available. Do not make a new live transaction merely to complete this worksheet.
If a permitted second attempt produces a different result, keep both observations. For example:
First attempt opened version 2. A later permitted attempt opened version 3. The conditions that changed are unknown. No repeatable sequence has been established.
That is an illustrative variation, not another test we performed. It should not become “fixed,” “always broken” or a reliability percentage. Record the times and differences you know; let the investigation establish the cause.
Prepare the smallest useful evidence packet
Include the area needed to show the issue. Remove unrelated customer details and account information from a shareable copy. Check the final attachment itself; changing the filename does not remove sensitive content inside it.
OWASP's logging guidance identifies passwords, access tokens, session identifiers and sensitive personal data as material that should generally not be recorded directly. Apply that caution when choosing what to copy from diagnostic material into a request.
Do not attach passwords, secret keys, complete customer lists or unreviewed logs. A page address can also contain a private token or personal information. Remove those values from the shareable copy and explicitly label the address as redacted; keep the needed original only in its appropriate restricted location.
When removal would hide the essential problem, ask the authorized recipient how to provide the minimum required material through the existing private process. This worksheet does not establish a product's support channel, privacy policy or retention promise.
Ask for a decision, then record the next evidence
End with the smallest useful request: confirm the intended file, explain an undocumented step, investigate the recorded behavior or identify what context is missing.
Use the help-request worksheet to prepare that account. It includes the fictional example, an evidence-sharing check and a place for the eventual response.
A reply saying “please try again” is an instruction, not a verified resolution. When an authorized change or new instruction is available, record its version and a permitted recheck. If you have not repeated the relevant task, leave the result NOT RUN.
For a ClickFunnels AI project, consult /agents for the current workflow and access requirements. Your finished packet describes one obstacle and the next question. It does not promise product access, a support entitlement, a response time or a completed repair.