How to run each part of your OS.

Thirteen operator procedures, grouped by what they do.

Some of these your own team can run today, start to finish, from the SOP alone … those are marked VA-ready. The rest are still run by ContentWorks while the process beds in, marked ContentWorks-run … each one gets documented and handed across the same way the VA-ready ones already have.

Writing a blog article.

Turns a one-line request into a published article, without losing accuracy or tone on the way. Articles are the most requested piece of work on the board, so this is the flow ContentWorks runs end to end from your side of the fence: you ask, you approve, nothing goes live without your yes.

How it runs

What happens, in plain terms

1. A brief gets built … the keyword, the angle, the structure, and real search data behind it, so the article is aimed at something people actually search for.
2. The article gets written against that brief … hook, proof-backed sections, and the questions people actually ask, answered directly.
3. It's checked before you ever see it. Every claim is checked against what your products can actually do, banned terms and medical claims are stripped out, and the writing is scored on whether it's worth publishing at all, not just whether it's technically correct.
4. A hero image gets picked or made to sit at the top of the post.
5. It lands in your review queue as a Google Doc, ready for your comment.
6. Once you approve it, it's checked one more time and moved into WordPress as a draft … never published live automatically.

Turning one article into a full content pack.

Once an article is finished, it doesn't have to stay just an article. This step cascades it into LinkedIn, Instagram, Facebook, TikTok, YouTube and an email teaser, and is honest about which channels are actually worth it for that particular piece.

What happens, in plain terms

1. The article gets scored for how likely it is to generate a genuine enquiry, and for how well it'll travel on social. A weak score means it's honestly told: "not worth spreading everywhere" rather than forced onto every channel regardless.
2. Only the channels worth using get written. If a channel isn't a fit for this particular article, it's skipped and the reason is noted … nothing gets padded out just to fill a slot.
3. Every piece is checked for tone, accuracy and brand fit before anything is saved.
4. A matching image gets made for each Facebook and Instagram post.
5. Facebook and Instagram posts move into the posting queue (see "Posting to Facebook & Instagram" below). LinkedIn, TikTok, YouTube and the email teaser are handed to whoever owns that channel that cycle.

Producing a month of visuals.

Hero images for blog posts, technical diagrams, in-article close-ups, social graphics, and on-brand recreations of a reference photo you've sent over … all built to the same brand rulebook, and every single one looked at by a person before it counts as finished.

What happens, in plain terms

1. Every request starts with the same question: what kind of image is this actually for … a hero, a diagram, a close-up, or a social post? That decides which route it takes.
2. A real product photo is used wherever one exists. A genuine photo of the actual product always beats a generated one, so that's checked first.
3. Where a generated image is needed, the real product is locked in as the reference … it's never redesigned, resized or approximated. If there's no clean product photo to lock against, the job stops and one is requested rather than guessed.
4. Every finished image gets a human eyeball check against the brand rulebook … right product, right setting (a real UK home, not a showroom or spa), no invented glow or sparkle, correct brand colours, and no text baked in where the format calls for text-free.
5. Headlines and overlay text are added afterwards in the brand templates, typed in exactly as briefed … never paraphrased on the fly.

Posting to Facebook & Instagram.

Takes an approved image-and-caption pair from a folder through to a live post on Facebook and Instagram, with a human check at every single stage. The tools get a post queue-ready … nothing goes out on its own.

Step by step

1. Check the content is ready. Every post needs an on-brand, finished image and a caption that reads right for its channel … not a rough draft of either.
2. Run the publisher as a preview first (a "dry run"). It lists exactly what's about to go out and flags anything it's skipping … a video file, a missing image, an empty caption.
3. Run it for real once the preview looks right. This pushes the posts into Facebook and Instagram's drafting queue via Sociamonials.
4. Mind the batch size. Sociamonials only pulls in roughly 10 posts at a time. Push a batch, refresh inside Sociamonials, then push the next batch … don't try to force more through in one go.
5. Log in to Sociamonials and refresh the source for the channel you just pushed. New drafts appear within a few minutes.
6. Check every new draft before it's queued: the caption matches what was approved, it's attached to the right account, and any extra carousel images are added by hand (the feed only carries the main image).
7. Add it to the queue … this is the step that actually sets it live. Nothing before this point has gone out.

If something's wrong

• →A draft doesn't show up after refreshing … give the feed a few minutes and refresh again. Still nothing, flag it to ContentWorks.
• →An item is silently skipped … usually a date issue on the post. Don't try to fix the file by hand … flag it to ContentWorks, there's a tool for that.
• →More than 10 items to push at once … push what fits, refresh, then push the rest. Don't force a bigger batch through.

Running the reviews & reputation engine.

The weekly routine that turns Vidalux's Trustpilot reviews into usable assets … a governed quote bank, brain-correction candidates, a theme report, and draft replies. It is draft-only: nothing is posted to Trustpilot automatically. A person posts every reply. Run weekly, alongside the Monday corrections review.

Cadence

Step by step

1. Pull the week's reviews. A tool fetches recent Trustpilot reviews for vidalux.co.uk. If the live pull can't run, reviews get pasted in or handed over as a CSV instead … the run continues either way.
2. Read what comes out. Four things:
   • Social proof bank … governed, committed customer quotes, safe to reuse in marketing. Customer voice, not product truth: a quote is never cited as a spec or feature.
   • FAQ / knowledge-base candidates … questions and confusions from reviews. Filed only at this stage.
   • Theme report … what's praised, what's complained about, and a marketing-risk list: any review praising a feature the product doesn't have. Those are never quoted.
   • Content angles … article and social ideas grounded in real customer language.
3. Move the human-gated items. Any FAQ or knowledge-base candidate worth actioning gets pasted into the Brain Corrections Log, where it goes through the normal weekly approval loop. Nothing edits the knowledge base straight from a review, and marketing-risk flags never get quoted anywhere.
4. Draft replies for any new negative or notable reviews. Every output is a draft … read it, edit if needed, then post it manually on Trustpilot.
5. Red-flag route. If a review involves injury, a safety hazard, a legal threat, or a money dispute, no reply gets drafted at all … it goes straight to you before anyone replies publicly.

If it "stops" … what it means

• →"The live pull isn't available…" … Reviews get pasted in or handed over as a CSV instead; the run continues. Not an error.
• →"0 new reviews" … Healthy. Nothing new since last run.
• →A review flagged marketing-risk … It praises a feature the product doesn't have. Never banked or quoted.
• →No draft reply, a "Safety Stop" note instead … A red-flag review … injury, safety, legal, money. Comes to you before any public reply.

Pre-flight checklist

• Reviews pulled for the week (or pasted / CSV fallback).
• Any FAQ candidates worth actioning pasted into the Corrections Log.
• Marketing-risk flags noted … none quoted in content.
• Replies drafted, human-reviewed, posted manually.
• Any red-flag routed to you. Nothing auto-posted.

Publishing a blog post to WordPress.

A tool that takes a finished Google Doc and creates a draft blog post on the Vidalux WordPress site … with the images, their alt text, categories, tags, author and meta description all set automatically. Your job is to prepare the Doc correctly. It never publishes live; a person always reviews the draft and hits Publish.

The 3 golden rules

Step by step

1. Write or paste the finished article into a Google Doc.
2. Put the metadata block at the top (copy it from below and fill it in).
3. Put a line containing only --- directly under the block. Everything below --- is the article.
4. Place the images where they should appear in the article, and set each image's alt text (golden rule 1).
5. Don't repeat the article title as the first line of the body … the title comes from the metadata block, so it'd show twice.
6. Make sure the Categories, Tags and Author you typed already exist in WordPress (golden rule 2).
7. Share the Doc, or send the link to whoever runs the publish, with wp publish <doc-link>. Tip: ask for a wp dry-run <doc-link> first … it checks everything and reports problems without creating anything.
8. The result is a draft in WordPress. Open it, give it a final look, then Publish.

The metadata block … copy this to the top of every Doc

Title:
Categories:
Tags:
Author: Andrew Ellis
Slug:
Meta description:
---

• Title … the post headline (required).
• Categories … one or more, separated by commas. Must already exist in WordPress.
• Tags … one or more, separated by commas. Must already exist in WordPress.
• Author … must match a real WordPress user. Default is Andrew Ellis (leave as-is unless told otherwise).
• Slug … the URL ending, lowercase with hyphens (e.g. steam-shower-leaks). Optional … if blank, WordPress makes one from the title.
• Meta description … 1–2 sentences for Google search results (around 155 characters). Use … not three full stops.

Keep the block as plain text (not a heading, not bold).

If it "stops" … what the messages mean

The tool is strict on purpose: if something's missing it stops and lists it, and nothing is uploaded or created. Common ones:

• →"…image(s) missing alt text…" … Open the named image in the Doc, add Alt text → Description, save.
• →"category '<name>'" (missing) … Create that category in WordPress, or fix the spelling in the Doc.
• →"tag '<name>'" (missing) … Create that tag in WordPress, or fix the spelling in the Doc.
• →"author '<name>'" (missing) … Use a real WordPress author name (default: Andrew Ellis).

Quick pre-flight checklist

• Metadata block at the top, then a --- line, then the article.
• Title filled in.
• Categories and Tags exist in WordPress and are spelled correctly.
• Author is a real WordPress user (default: Andrew Ellis).
• Every image has alt text (Description).
• Article title is not repeated as the first body line.
• (Recommended) Ask for a wp dry-run first to catch problems.

Importing product descriptions to WooCommerce.

The publish hop for product-description batches. Runs after the daily approval sweep finds approved rows in a review Sheet. You never touch this part … you approve, ContentWorks imports.

Steps

1. Filter the Sheet to rows marked "Approved? = Y" and "Status = approved". A flagged row without its answer noted goes back to draft … never imported.
2. Export the approved rows to CSV, keeping the batch's original column headers so the import mapping lines up.
3. Run the import in WooCommerce with the saved Vidalux field mapping (Title / Meta Title / Meta Description / Short / Long). Imported as updates by SKU match … never as new products from this flow.
4. Spot-check 2 of the imported pages on the live site: fields landed in the right places, no truncation, £ and UK spelling intact.
5. Mark each imported row "Status = imported", then "live" after the spot-check.
6. Update the board card with how many of the batch imported, and move it to done once the Sheet is fully worked through … it shows in your Shipped list the next morning.

If something's wrong

• →Import errors or mapping drift … nothing gets reverted (imports are per-row updates); the card goes back to Active Build with a note, flagged to Dan.
• →A published page shows a claim you flagged … treated as a live fault: fixed via a new import of the corrected row the same day, and logged to the Brain Corrections Log so the source is patched too.

Rewriting product descriptions.

Produces accurate, on-brand descriptions for every SKU in a catalogue batch … from a raw export through a quality gate to live publication, without changing a single factual detail from your source data.

How it runs

What happens, in plain terms

1. Your export is checked first. Blank prices or missing specs get flagged back to you before anything is written … nothing gets guessed or filled in.
2. A draft description is written for every SKU, using only what's in your data. No dimension, spec or price is ever added that wasn't already in the export.
3. Every SKU goes through a contradiction check against the product knowledge base, then an SEO pass, a de-AI pass, and a brand-compliance check. Nothing skips a step.
4. Drafts land in a review Sheet for your approval, one row per SKU.
5. Nothing publishes until you've approved it. Corrections come back, get incorporated, and go round again if needed.
6. Once approved, it's posted as a WordPress draft for a final check before going live.

Exporting the product feed.

Produces a current, complete CSV of the whole catalogue, so any rewrite, metadata pass or audit runs against real data rather than a stale feed.

Steps

1. Log into WordPress admin on the Vidalux store.
2. Open the CSV Import Suite plugin.
3. Select the export profile that includes every product field … title, meta, descriptions, price, specs, stock code.
4. Run the export and download the CSV.
5. Drop the file into the shared "CW … Vidalux Feeds" Drive folder, with the export date in the filename.

Quality check

Open the file and confirm the row count matches the live catalogue, and the key spec columns (kW, dimensions, jets) aren't blank. Blank spec columns are a known gap in the export … flag them so they're fixed at source before bulk work runs against the file.

The monthly outreach target run.

Produces ranked lists of real, relevant sites worth pitching for a backlink … at least 100 vetted targets a month (July's run landed 176) with a contact route and a pitch angle each, landed in your Sheet, plus a second list of what AI search engines already cite for Vidalux's core searches. And from August, it's two lists each month … UK and US … after you asked us to chase the same searches in bigger markets.

How it runs

What happens, in plain terms

1. Two exports are pulled from Ahrefs … sites that link to your competitors but not to you, and the metrics that prove they're worth pitching. The login for this is held securely by ContentWorks.
2. Every candidate is vetted against a fixed rubric: is the site actually relevant to sauna, steam or home-spa … is it a real site with real traffic and authority … is it clean of link-farm or spam signals. Sites that fail any gate are dropped, and the reason is kept on record, never just deleted.
3. A short, honest list beats a padded one. If the month comes up short of 100, that's said plainly on the card rather than topped up with weak targets.
4. A citation-mining pass runs first each month … checking what ChatGPT, Perplexity, Google AI Overviews and Gemini already cite for searches like "best infrared sauna UK", so genuinely cited sites get prioritised for outreach.
5. Each kept site gets a one-line pitch angle written by hand … never a template blast.
6. UK first, then US, delivered together … two tabs in the Sheet each month, kept separate so you can see the widening, with pitch angles written for each market.
7. The finished lists land in the Sheet, and the delivery is logged so the next month's cadence resets correctly and the work is on record.

Writing & placing a guest post.

Turns one accepted placement … a host site that's said yes to a topic … into a finished, genuinely useful article that earns its Vidalux backlink rather than having one bolted on.

How it runs

What happens, in plain terms

1. The confirmed details are pulled from the Sheet … host site, agreed topic, how many links, and which page they should point to. Nothing gets written until every one of these is actually confirmed, never guessed.
2. Every product claim in the draft is checked against the real product data before the article is written … an unverified claim is left out, not softened into something vaguer that might still be wrong.
3. The finished piece is checked a second time for tone, accuracy and brand fit.
4. A person reads it through to confirm it reads as a genuine contribution to that host's audience, not an advert with a link stapled on.
5. It's sent to the placement contact exactly the way they asked for it … a Doc, an email, their own submission form.
6. The Sheet row is kept current … sent, then placed with the live link once it's confirmed live, or marked dead if the host goes quiet.

The AI email assistant.

The Vidalux AI email assistant lives inside Thunderbird as an add-on called ThunderAI. It reads a customer's email and writes a grounded draft reply, pulled live from the full Vidalux knowledge base … products, warranties, delivery, policies. Nothing is ever sent automatically … a person always reviews and sends.

The 3 golden rules

Day-to-day use

1. Get a grounded draft. Open the customer's email, click the AI button, "Reply to this email". A grounded draft appears in seconds.
2. Refine it by chatting to it. Type a follow-up like "make it warmer" or "mention free UK delivery" and it rewrites the draft, keeping the facts intact. Repeat as many times as needed.
3. Send it. "Use this answer" drops the draft into a normal, editable reply. Make any final tweaks by hand, then send.

When it doesn't know the answer

It defers rather than guesses … something like "let me get a member of the team to confirm." That's correct behaviour: it won't invent a fact the knowledge base doesn't hold. That exact question gets logged and added automatically, so it'll know next time. Handle that one reply yourself in the meantime.

If something looks off

• →Connection error when drafting … the setup needs a quick re-check on that machine. Flag it to ContentWorks.
• →Account setup hangs … a sign-in window is often waiting behind the main one; check for a hidden pop-up.
• →Anything else … flag it to ContentWorks rather than falling back to an older tool … its knowledge won't be current.

Logging a knowledge correction.

Captures every wrong or incomplete answer the AI gives … from an email reply, chatbot, or anywhere else … as a structured correction, reviewed weekly and patched only once a human has approved it. Nothing is ever auto-applied to the knowledge base.

Split ownership

Your part … logging it

1. Spot a wrong or incomplete AI answer.
2. Open the Brain Corrections Log Sheet and add a row: what type of error it is, which product it relates to, what the AI said, what the correct answer actually is, and where you saw it.
3. If you don't know the correct answer yourself, write "Needs Andy" in that field rather than leaving it blank … either way, never leave the row without a note.

ContentWorks' part … reviewing & patching

Every week, unchecked rows are read and turned into draft fixes. Every fix is shown to you for confirmation before it touches the knowledge base … nothing is applied without an explicit yes. A fix is never applied that contradicts something you've previously confirmed, without asking you first.