How Any Group Gets Personal Brand Websites for Its Members: The Request-to-Live-Site System

On July 16, 2026, Jagoda Pasko submitted the first test entry through Sigrun’s Personal Brand Website request form. By the next morning, our agent had read the submission, verified her domain, caught a configuration detail that would have taken down her email, logged her status, and posted the full report to the one Basecamp thread the whole team reads. Nobody scheduled a meeting. Nobody sent a chaser email.

This is the definitive process for running member website requests for any group: a mastermind, a coaching program, a trade association, a sales team. One form, one sheet, one thread, one agent checking daily. We built it live with Sigrun’s SOMBA program, where 86 members already have audit dashboards, and it plugs into the same machinery we use for every site on our fleet.

Why a form beats email

When six workshop attendees emailed us wanting sites in June, every request arrived in a different shape. One had a live Wix site with email on the domain. One had no domain at all. One wasn’t even a site request. Each needed a human to read it, classify it, and reply. That works for six. It does not work for 86, and it does not repeat.

A form forces every request into the same shape, which means an agent can process it. The group’s coordinator owns the form. We own what happens after a row lands in the sheet.

What the form asks, and why every field maps to a build step

The status pipeline

Every request moves through nine stages. The stage name is the status we report, so anyone reading the thread knows exactly where a member stands.

The DNS branch that saves people’s email

Here is the detail the first test caught. Jagoda answered yes to “does your domain already run your email?” Her checks confirmed it: live MX and SPF records at her Polish host. If she had switched her nameservers to ours before anyone copied those mail records over, her email would have stopped working, and she would have found out the hard way.

So the process branches on that one form answer:

• Email on the domain (or any doubt): A-record path. The member points @ and www to our server IP and keeps their existing nameservers. Mail records never move, email never blinks. This is the default, per our one-email-to-live-site SOP.
• No email on the domain: nameserver path. The member points to the four nameservers issued for their site. Each site gets its own set from our DNS, which is why the form must never promise nameservers up front — they do not exist until the site is provisioned.

We keep registrar-specific walkthroughs so members are never guessing: GoDaddy, TransIP, MyDevil, and IONOS, and more as new registrars show up. A registrar we have not documented yet is a signal to write the guide, which is then ready for the next member.

One thread, all status

Every status change gets posted to the group’s single Basecamp thread, the same one the coordinator, the founder, and our team already read. Members are never chased individually, the coordinator never has to ask “where are we on X,” and the whole history is documentation. Any outbound email to a member is staged as a draft for a human to review and send, never fired automatically.

What the first test caught (this is why you test)

Jagoda’s test submission was the model entry: complete bio, a full brand design brief with HEX codes and fonts, five named testimonials, a shared photos folder, a contact email. And the test surfaced two form fixes before a single client touched it:

1. The nameserver precondition was backwards. The form said “you can submit only if you have already added the 4 nameserver records.” But each site’s nameservers are issued after provisioning, and for members with email on their domain, adding them early is exactly the wrong move. The fix: replace the precondition with a simple acknowledgement that the member will point their domain when their instructions arrive.
2. The email question needed teeth. It was collected but nothing branched on it. Now it selects the DNS path, which is the difference between a clean cutover and a member losing their inbox.

Run this for your group

1. Copy the form fields from the table above. Gate it to paid members at whatever level you choose.
2. Responses land in one Google Sheet. Share it with the build team. Add a team-marker column so staff can test with the real pipeline.
3. Pick the one thread where status gets posted. Everything goes there.
4. Have the coordinator submit a test entry first, all the way through to a live site. The test will find your version of the two fixes above.
5. Turn on the daily agent scan: new rows, validation checks, status posts. Ours runs every morning at 4am.
6. Announce to members only after the test entry is live.

The result for each member is not just a website. It is an entity home that feeds their Personal Brand Score, their Quick Audit, and eventually their Knowledge Panel, with an Application Password so their own agents keep it alive. The result for the group is a repeatable machine: the next 85 requests cost the same effort as the first one.

Part of The System. How the first submission was processed: the meta article (a record of one task run; see meta-article writing guide). Related: From One Email to a Live Personal Brand Site, Application Passwords for AI agents, the meta article standard.

Originally published July 16, 2026.