Newsletter publication

This playbook runs when an issue brief or draft document is ready for publication. One case manages a single newsletter issue through asset assembly, link verification, factual claim checks, audience segment selection, editorial sign-off, and confirmed publication or scheduling. It does not manage audience list acquisition, write complete articles from scratch, or send broadcasts without verified sign-off. When destination platform API access is unconfigured, the agent stages the prepared issue bundle and hands off publishing to a designated operator, keeping the run pending manual verification receipt.

• Retrieve the issue draft from Google Docs or the working brief, extracting the working title, proposed subject lines, preview text, body sections, sponsor copy, and call-to-action links. Record the target publication date, intended recipient tier or audience segment, and delivery channel in the run summary.
• Inspect all hyperlinks, image assets, and tracking parameters across the issue copy. Validate that destination URLs resolve, UTM campaign tags match the issue identifier, images include descriptive alternative text, and sponsored placements carry standard disclosure labels. If any asset link is broken, missing, or redirects to an error, pause for missing information.
• Information request. Present the identified broken links, missing asset files, or unverified factual claims to the issue author. Ask for corrected destination URLs, replacement media assets, or supporting references for disputed claims. Once the author supplies the verified assets, resume the pre-publication audit; if the author cannot supply the required materials, keep the issue waiting or refer it to the publication lead for disposition.
• Reconcile factual assertions, statistics, and partner quotes against supplied reference documents or previous issues. Flag any unattributed data points, unconfirmed sponsor deliverables, or missing compliance disclaimers. If a sponsor agreement requires specific ad placement or tracking that cannot be verified, flag the exception before staging.
• Exception. Report the unverified sponsor placement, missing contractual disclaimer, or unresolvable factual contradiction to the publication lead. The lead decides whether to adjust the copy, swap the placement, or hold the issue. If the lead directs an editorial revision, apply the adjustment and return to copy staging; if the lead cancels the issue, move the run to Held or declined with the rationale.
• Assemble the verified copy, formatting, links, and assets into the target publishing platform, such as beehiiv or Ghost, using supported draft staging capabilities. Create a staged draft post, apply the approved subject line, preview snippet, and designated recipient segment, and generate an internal preview link. If a test send is desired, obtain explicit authorization for the specific test recipient addresses before transmitting any test email. Verify that the staged post ID is recorded and matches the run metadata before requesting publication approval.
• Approval. Present the staged issue preview link, final subject line, preview text, target audience segment, and proposed publication or send time to the editorial owner. The owner reviews the complete layout and decides whether to approve publication, request specific text or asset revisions, or hold the issue. If revisions are requested, update the staged draft and present the modified revision for renewed approval.
• Upon receiving explicit approval, initiate the publication or scheduling action in the destination platform for the specified send window. If the publication is scheduled for a future timestamp, record the platform schedule confirmation and keep the case pending in the editorial workflow until the actual send or publication is independently verified, or hand off to an accountable operator with a named follow-up owner without marking it already sent. If immediate broadcast is approved, trigger the send.
• Verify the publication or scheduling status by querying the platform record directly. Confirm that the post status reflects published or scheduled, the post ID matches the staged draft, the email broadcast status confirms delivery to the approved audience segment, and any public web archive URL is generated, distinguishing web post publication from email newsletter transmission. If the platform returns an ambiguous response or network timeout, inspect the existing post and broadcast status before attempting any retry to prevent duplicate sends; if inspection is unavailable, hold the action and alert the publication lead.
• A fictional marketing team at a developer tools company prepared issue #42 in Google Docs with an interview snippet and a promoted sponsor link to an analytics dashboard. During automated asset checks, the tracking URL for the sponsor returned a 404 error, and a cited survey statistic lacked an origin link. The agent raised an information request, and the author supplied the corrected sponsor tracking URL and cited the original whitepaper. After updating the draft and obtaining test recipient sign-off, the staged beehiiv preview and audience segment were submitted to the editorial lead, who approved immediate broadcast. The agent triggered publication, confirmed post ID post_88412 showed published status, verified email send completion to the core subscriber segment, and recorded the public issue URL.
• When the publication status confirms published with verified email delivery to the approved audience, transition the case to Publication confirmed. If the issue is scheduled for a future release date, maintain the run in pending status until delivery is verified or an approved operator handoff receipt is recorded. If the editorial owner holds or cancels the issue, or if unresolved sponsor compliance issues prevent release, record the decision notes and transition to Held or declined.