How do I describe a Webflow problem in a written request?

Name the page and what failed

A brief for a planned update lists the new copy and the pages to change. This note is for something that already fails. Start with the page and the failure, so the hour is not spent looking for which screen you mean.

Write the path as a visitor would open it. Example: 'On /contact, Send does not finish.' That is a start. 'The site feels off' is not, because it does not name a page or a result.

One problem belongs in one note. If the form fails and a separate heading is also wrong, say whether both are in this request or only the form is. A mixed note gets the first issue fixed and leaves you unsure whether the heading was in scope.

Keep the note in the same thread you already use for the month. A side message that says 'also, the form broke' is easy to miss when another request is open.

Write the steps and the two outcomes

Three facts make the problem checkable. What you did. What you expected. What happened instead. Write them as short lines, in that order. Someone who was not watching you should be able to repeat the visit.

Example: 'I opened /contact on a phone, in Safari. I filled Name and Email with test values and clicked Send. I expected the success message. The button text did not change, and the page stayed put. The same form on a desktop browser shows the success message.'

That example names the page, the device, the expected result, and the actual result. It also says where the problem does not happen. A note that says 'the form is broken' can mean a missing email, a button that does nothing, or a field you could not see. Those are different jobs.

Include only the steps that reach the failure. A history of the whole site is not needed. If a field is required, say whether you filled it. If you were logged out, say that. Leave out guesses about the cause unless you already checked something and want that check recorded.

If the problem is a layout rather than a click, the two outcomes are still the same shape. Example: 'On /pricing, at phone width, the third card sits on top of the footer. I expected the card to sit above the footer with space between them. Desktop shows the cards in a row, and that row can stay.'

Say what fixed looks like

The request is finished when a visitor gets the result you named, not when a setting has been touched. Write that result in the same note. 'Fixed means the success message shows after Send on that phone, and the desktop form still shows it too.'

Do not write 'make it work' as the only outcome. Add the thing you should be able to see or do. For a link, fixed can mean the button opens /contact. For a heading, fixed can mean the approved sentence is the one on the live page.

Say what is out of the request. Example: 'Not in this request: a new form layout, or a new page. The form can keep its fields. It needs to finish the submit on the phone.' A repair that turns into a redesign is a different project. Naming the boundary keeps the hour on the failure.

If you already know a recent edit landed just before the failure, say which request it was. That is context, not a diagnosis. The check is still the steps and the result you want back.

Keep a picture from replacing the note

A screenshot helps when the page has two similar blocks and the path alone does not show which one failed. Mark the block, and say whether the picture is the failure or the result you want. The screenshot guide is that choice.

The picture does not replace the steps. A circled button without the page path, the expected message, and the device still cannot be repeated. Paste the sentences even when the image is attached.

Do not send a recording as the only explanation. Write the same steps the recording would show. The thread should still make sense if the file cannot be opened.

If you are asking for a planned change rather than reporting a failure, use the brief guide. That page is the outcome, the assets, and what done looks like for new work. This page is the visit that already goes wrong.

Mark the request, then keep it in the plan

Put Urgent on the first line only when visitors are blocked and you need the 24 hour review. A typo that is not stopping the page can stay on the standard window, which is a review and pickup within 48 hours. The urgent guide is how to choose the label. Both windows are pickup times, not a promise of when the live page will be finished.

One person should send the note, even if a teammate saw the failure. Two reports of the same form can spend the hours twice. Hand the steps to the person who owns the queue, and send one version.

The Webflow retainer is the monthly plan this kind of note belongs to: $999 per month, including 10 hours of Webflow work. Additional work is $75 per hour and starts only after you approve a written estimate. Unused hours expire at the end of each monthly billing period and do not carry over. Memberships cannot be paused. Communication is written only. There are no calls or meetings. The retainer guide explains which ongoing work those hours cover. Use this page when something on the live site fails and the next step is a written report.