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.

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.

How Storywright does it

Storywright takes that webhook URL once, in world settings, and posts the recap the moment you publish a session briefing. The message carries the opening lines and a link that works without an account, so a player who has never signed in can still read it — and the players who have get taken straight to the full briefing.

Two details that matter more than they sound. Private material never goes to the channel: story arcs and lore you have marked private are excluded from what gets posted, because a shared channel is exactly the wrong place to discover a leak. And any player can opt out of having their name forwarded to Discord at all, from their own preferences — their table still gets the recap, it simply does not carry their identity to a third party.