Which workshop outcomes were ever written down

It is the Tuesday after the roadmap offsite. The product lead has two windows open.

On the left, Miro. A board called "Q3 Roadmap Offsite" with four frames: Problems, Bets, Owners, Parking Lot. Around 140 sticky notes, most of them in someone's handwriting-equivalent scrawl of six words. In the Bets frame there are eleven clusters, each with a rough title someone typed over the top, and a handful of red dot votes stuck to the ones the room liked. Three stickies have a person's initials on them because somebody went round at the end and did the "who owns this" pass.

On the right, Notion. The team wiki. A database called Initiatives, with a Status property, an Owner property, a Target quarter property, and a page body for each row where whoever created it wrote a paragraph or two of context. Twenty-three rows. Nine of them created or edited in the last two weeks.

The question the product lead is trying to answer before the leadership sync at four: of the eleven bets the room agreed on, which ones actually made it into the wiki as something with an owner and a shape, and which ones only exist as a sticky note on a board nobody has opened since Thursday.

This is not a hard question conceptually. It is a question about two piles of text. But answering it means opening the board, reading eleven cluster titles and the stickies under them, then going to Notion and reading twenty-three initiative pages to see whether any of them is the same idea wearing different words. That is forty minutes of squinting, and it has to be redone after every offsite.

What Miro shows on its own

Miro is honest about what it is. It shows you the board.

It will tell you, accurately, that a board exists, when it was last modified, who has touched it, and every object on it: sticky notes with their text and colour and position, frames with their names, connectors, votes from a voting session, comments and their threads. The API exposes all of this. You can pull items by board, filter by type, read the content of each sticky. Voting results come back as counts. If you ran a proper voting session rather than dot stickers, you get a structured result.

Where it stops is one step past the board edge. Miro knows that a sticky in the Bets frame says "kill the legacy importer, move everyone to CSV upload" and that it has four votes. It does not know, and has no way of knowing, whether anybody went and did anything about that afterwards. There is no field on a sticky note for "was this turned into work". Nothing in Miro's data model reaches into your wiki or your tracker to check.

Miro also has no opinion about whether two stickies are the same idea. "Kill the legacy importer" and "importer deprecation" are two unrelated strings to Miro. They are the same bet to a human reading them. That distinction matters enormously for this question and Miro is not the tool that resolves it, nor should it be.

What Notion shows on its own

Notion is the other honest half. It shows you what got written down.

The Initiatives database gives you a clean list: title, status, owner, target quarter, created time, last edited time, and the full page body. You can filter to items created since the offsite date. You can group by owner. You can build a view that shows only the ones with no owner set. Notion databases are genuinely good at this, and the API returns both the properties and the block content of each page, so the paragraph somebody wrote about why this initiative exists is retrievable text, not a black box.

Where Notion stops is symmetrical to where Miro stops. Notion knows there is an initiative called "Importer deprecation, phase 1" created on Friday by Dana. It does not know that this initiative came out of the offsite, or which sticky it corresponds to, or that the room voted for it four times. It also cannot tell you about the seven bets that never became an initiative at all, because from Notion's point of view those things do not exist. The absence is invisible. A database can show you its rows. It cannot show you the rows that were never created.

This is the shape of the problem: each product has half the evidence and neither half is aware that the other half is missing.

Why the gap is structural, not a missing feature

It is tempting to file this as "somebody should build a Miro to Notion integration". Integrations do exist, and they do something real: embed a board in a page, or push a set of stickies into a database as rows. Useful. Not this.

The reason is what each half of the evidence actually is.

Both sides have identifiers. Neither side has an identifier the other side knows about. There is no foreign key between a sticky note and an initiative page, because nobody created one, and nobody created one because the act of turning a workshop idea into a wiki entry is a human retyping the idea in their own words on a Friday afternoon.

So the join is semantic. "Kill the legacy importer, move everyone to CSV upload" and "Importer deprecation, phase 1" are the same bet, and the only thing that establishes that is somebody reading both and recognising it. No amount of matching on strings, dates or owners gets you there reliably, because the person who wrote the wiki entry was not trying to match anything. They were writing an initiative.

This is also why the tools that live next door do not close it. Automation platforms are trigger based: something happens, then records move forward. That is the right architecture for "when a sticky is tagged, create a Notion page", and if you set that up beforehand you get the key you were missing. But it does nothing for the offsite that already happened, because there was no trigger at the time and the question is about what already exists. BI tools have the opposite constraint. They connect to databases and modelled sources, and the Miro half of this evidence is not modelled data. It is a sentence somebody wrote on a coloured square. That is outside what a BI tool can see at all, not something it renders badly.

What the join actually requires

Two things, and only one of them is mechanical.

The mechanical part is scope. You need the board ID and the date of the workshop, and you need the Notion database plus a window: initiatives created or substantially edited since that date, plus any that existed before and were touched afterwards, because some bets land as updates to existing work rather than new rows. That is a filter. It is easy.

The judgement part is the match. For each of the eleven bets, read the cluster title and the stickies under it, then read the twenty-three initiative titles and page bodies, and decide: is this bet represented, partially represented, or absent. Partially represented is the interesting bucket and the one a keyword match will get wrong in both directions. An initiative might carry half the bet. A bet might be split across two initiatives. An initiative might use the exact same words while describing something different, which happens more than you would expect when a team has house vocabulary.

That is reading, not matching. It is the thing a person does in forty minutes and a language model does in one, and it is the entire reason this question does not have a dashboard.

Answering it with Skopx

Skopx connects to nearly 1,000 SaaS tools including Miro and Notion. You ask in chat and it reads across both and answers with citations back to the specific sticky and the specific page.

The realistic sentence:

Take the Miro board "Q3 Roadmap Offsite". For each cluster in the Bets frame, tell me whether there is a matching initiative in the Notion Initiatives database, created or edited since 24 July. Mark each one represented, partial, or nothing written down, and quote the sticky text and the initiative title so I can check.

What comes back is a list of eleven bets, each with a verdict, the evidence on both sides, and the ones with no Notion counterpart called out plainly. Skopx cites the board object and the page it read, so when someone at the four o'clock sync says "no, that one is covered, it is under the platform initiative", you click through and look rather than argue.

If this is a question you ask after every workshop, the same sentence builds a standing console. Skopx's Internal Apps turns a description in chat into a small read-and-act interface: the board's bets down the left, matched initiatives beside them, the unmatched ones in their own section at the top where they are hard to ignore. It reads live from both tools each time you open it. The single action on it is a button next to each unmatched bet that creates a stub initiative in Notion with the sticky text and the vote count in the body, and it asks you to confirm before it writes anything. That is the only write. Everything else on the page is reading.

What this does not do

It does not create anything on its own. There is no scheduled run that sweeps your boards, no alert when a bet goes unwritten for a week, no automatic page creation. The only thing that writes is a button a person presses, once, with a confirmation step in front of it.

It does not fix your Miro hygiene. If the Bets frame is actually a mess of overlapping stickies with no cluster titles, the answer will be vaguer, because the input is vaguer. Boards that were tidied at the end of the session produce sharply better answers than boards abandoned at the whiteboard-photo stage.

The matching is a judgement call and it can be wrong. That is exactly why every line cites the sticky and the page it is based on. Treat the verdict as a first pass by a fast reader who has seen both piles, and check the partial ones yourself. The value is not that a machine decided; it is that forty minutes of cross-reading became a thing you can glance at.

It only sees what your account can see. Private boards you are not on, Notion pages outside your permissions, none of that enters the answer, and no teammate opening the same console sees anything their own access does not allow.

And it does not replace the follow-through conversation. Knowing that four of eleven bets were never written down is not the same as deciding what to do about them. It just means that decision happens on Tuesday with the list in front of you, instead of in November when somebody asks whatever happened to the importer thing.

Skopx is $16 per seat per month on Team, which includes 2.3 million AI tokens per seat, with SOC 2 controls in place. Solo is $5.