Getting recaps into the room your table is already in

The recap is not the problem. The delivery is.

Ask a GM why their recaps go unread and you will usually get an answer about writing — too long, too dull, not enough hooks. Sometimes true. But plenty of well-written recaps go unread for a much duller reason: they live somewhere the reader has no habit of going.

Your players have a habit of opening Discord. They opened it to agree on a date, to send a meme, to ask whether the session is still on. That habit is worth more than any amount of craft applied to a document behind a link. Put the recap in the path of an existing habit and the read rate changes before you improve a single sentence.

Post the substance, link for the rest

The most common mistake is posting a bare link with “recap’s up!” attached. That asks the reader to spend a click before they know whether it is worth one, which is a bad trade for a person half-watching their phone. Two people click. They are the two who would have read it anyway.

If you post by hand, put the ~150 words in the message. Let the link carry the long version, the journals, the map — the things a curious player will happily click after the hook has landed. The click should be optional, not the entry fee.

Use the channel they already talk in

The instinct to create #recaps is a tidy instinct and usually the wrong one. A dedicated archive channel has the same problem as the wiki page: it is correct, it is organised, and nobody opens it. Post into the channel where the party actually talks, and split it out later if and only if the volume starts genuinely annoying people.

Write it as though the whole server is reading, because it is

A shared channel usually holds more people than your table — a partner who joined for the memes, a friend between campaigns, the player who left last spring. Anything you would not say in front of all of them does not belong in the recap.

That means GM-only material stays out entirely: the twist you have been building, an NPC’s real motive, the reason the quiet cleric keeps disappearing. Not held back by careful phrasing, not relying on who happens to be in the channel — simply not in the document you are about to post. This is a habit worth having anyway, because the moment a recap becomes automatic, the question “who will see this?” stops having a reliable answer.

Stop doing it by hand

The step that fails is not the writing. It is the copying — the small, forgettable act of moving finished words from where you wrote them into where people read them, at the end of a long evening. It gets skipped on exactly the weeks the campaign most needs it.

Discord solves this with incoming webhooks: a channel gets a URL, any tool can POST to it, and the message appears as though someone sent it. In Discord, that is Server Settings → Integrations → Webhooks → New Webhook, pick the channel, copy the URL. Nothing is installed and no bot joins the server.

Any tool that can make an HTTP request can use it — a script, a Zap, a spreadsheet macro. The point is not the tool. The point is that publishing and delivering become one act instead of two, and the second one stops depending on you remembering it at eleven at night.

Set up Storywright’s Discord notifications

1. As the GM, create an incoming webhook for the channel you chose in Discord. Treat its URL like a password: anyone holding it can post to that channel.
2. In your world’s Settings → Discord notifications, paste the webhook URL, enable notifications, and leave Recap published on. Move focus out of the URL field and wait for the saved confirmation, then use the test button before relying on it for a session.
3. Publish the session’s Previously on… briefing. Storywright sends a short announcement with the session title and a link to the player-facing briefing. The full recap is read in Storywright; its opening paragraphs are not copied into the Discord message.

Write the public briefing for the people who may follow that link. Keep GM notes and undiscovered lore in their private places. A shared Discord channel can include people outside the party, so choose its audience deliberately.

Know whether a recap arrived

New delivery controls are being prepared for a staged rollout separate from the existing webhook setup. When enabled for your world, the session briefing shows whether Discord confirmed the post, whether it is waiting to retry, or whether delivery failed. If a published recap did not arrive, the GM can retry that session’s post without republishing the briefing. An unknown result means Discord may already have a copy; Storywright asks you to acknowledge that duplicate risk before trying again. A sent post is not a read receipt.

When those controls are enabled, a GM using a Storywright-connected assistant can ask for the same session-specific delivery status or request a retry. The MCP tools use the same GM permissions, eligibility checks, and duplicate-risk acknowledgement as the app.

Real account pings will also require a separate opt-in. A player connects their Discord account in Security, allows Discord notifications, chooses to show their name, and explicitly enables linked-account mentions when that option is available. Saving a Discord username alone never enables a real ping. Players can turn their choices off in Preferences without stopping the table’s recap announcement.

Today, setup uses a webhook URL. A channel picker, recap excerpts in the Discord message, per-session threads, and slash commands are separate planned work; they are not part of this setup.