The request loop

Every piece of client work in your agency, from a typo fix to a full build, moves through the same five-step loop. Learn it once and delivery stops being a scramble and becomes a rhythm.

The loop

• 1. Request. Work enters as a request: the client submits it through their portal (they can even click directly on their own site and leave a visual comment exactly where the problem is), or you create it yourself from a call or email.
• 2. Work on a branch. Your agent makes the changes on a branch: a separate copy of the site's code. The live site is untouched while work happens. Branches are why nothing your agent does can break production.
• 3. Preview. The branch deploys to a private preview link: the full site, with the changes, on a URL you can open on your phone.
• 4. Review and approve. You check the preview against the request (next lesson gives you the checklist). Not right? Send it back with a note and the agent revises. Right? Approve.
• 5. Merge and done. Approval merges the change into the live site, the request closes, and the client sees it done in their portal, under your brand.

Why the loop matters commercially

Look back at your service menu. Care plans promise "small changes handled"; the loop is how that promise costs you minutes instead of evenings. Full management promises "unlimited requests, one at a time"; the loop is what makes unlimited survivable, because each request is a clean cycle with a defined done. You priced these products in Module 6. The loop is why the margin on them is real.

One at a time is a feature

Requests process sequentially per client, and that is a promise worth making out loud. Clients get focus, you get a queue instead of chaos, and "we work through your list one item at a time, usually within a couple of days each" sounds like exactly what it is: a professional operation. Nobody actually needs seven changes simultaneously; they need to trust the list gets worked.

Keep the loop honest

• Everything goes through a request. Work that arrives by text message gets typed into the platform before it gets done. If it is not a request, it does not exist.
• Set expectations on turnaround (a couple of business days for small items) and beat them quietly.
• Let the portal do the status updates. You never want to be the human API between your client and your queue.