---
name: manage-group-member-website-request
description: "Keep each member’s site request from getting lost."
category: Personal Branding
stage: —
definitive_article: https://blitzmetrics.com/group-website-request-intake/
status: needs-work
---

# Manage a group member website request

Keep each member’s site request from getting lost. This guide tracks the facts, the build and the next person’s action in one record. Start with the real request and the group’s shared intake list.

**The path:** One request → Validated facts → Site playbook → Owner action → Verified result

**Start when:** A verified group member submits a website request into the group’s accepted intake process.

## Inputs

- The original intake entry, group/member identity and accepted eligibility rules.
- Current domain, site goal, language, bio, real photos, permissioned proof and public contact preferences.
- The existing shared request record, original conversation, build owner and actual access to those sources.

## Steps

1. Find or create the single request row in the accepted shared intake. Match the member using the agreed identifier and keep staff tests distinct. Do not build a competing tracker or expose a private form response in a public status page.
2. Validate the intended person, actual controlled domain, current site and goal. Check the source folder can really be read and list missing assets precisely. A submitted form or a paid membership does not prove domain control, deployment access or consent to publish every field.
3. Inspect the domain’s current web and mail dependencies before preparing setup instructions. Record the actual authoritative DNS host separately from the registrar. Preserve mail and verification records; no-email on the form is not by itself permission to change nameservers.
4. Hand the checked packet to [Deliver the requested personal site](https://local-service-spotlight.github.io/task-library/?task=deliver-personal-brand-site-from-request#task-deliver-personal-brand-site-from-request). Retain parent ownership of request status and dependencies. The build task prepares the source-backed preview and exact host-specific action instead of asking the member to guess technical settings.
5. Advance only the stage that evidence supports. The existing pipeline includes received, validated, site provisioned, instructions sent, DNS pointed, propagating, live, credentials issued and content loaded. Keep a preview, provisioning receipt, send receipt and final public check distinct; labels alone do not create these events.
6. Keep status in the group’s existing authorized conversation. Prepare external messages as drafts unless sending is already authorized. Put the next action with the actual member, web function or access owner, and retain failures instead of silently skipping to live.
7. Before calling a member’s site complete, verify the real public domain, HTTPS, intended content and retained dependencies. Provisioning or propagation delay alone does not prove success. Issue any permitted access through the secure existing rail, never in a public report.
8. For a new group setup, use a clearly marked authorized test request through the whole path before announcing readiness. A daily scan needs a real configured job, owner, timezone and observed run; this recipe does not activate one or assume the historical 4 a.m. job still exists.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] One accepted record tracks the right member, domain, assets and exact next owner.
- [ ] Every advanced state has its own evidence; unresolved access and domain dependencies remain open.
- [ ] Only the verified public result is called live or delivered, and public reports reveal no private intake/access details.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional group member supplies a photo folder that the web team cannot open. Her domain also handles email. The request stays validated with two explicit dependencies: readable photos and a reviewed domain plan. The coordinator can see who owns each action without a new tracker or an unsupported promise that the site is live.

### Dated source evidence

The source article’s July 16–17, 2026 Jagoda Pasko test describes discovery of an email/DNS risk. It is retained as a dated source account, not proof of current scheduler operation or a new completed member build.

## Handoff and Content Factory context

[Run the site delivery playbook](https://local-service-spotlight.github.io/task-library/?task=deliver-personal-brand-site-from-request#task-deliver-personal-brand-site-from-request) receives the validated packet. The group’s coordinator and web owner retain the shared status and final acceptance.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/group-website-request-intake/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=manage-group-member-website-request#task-manage-group-member-website-request)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.