Fathom to Notion

Fathom records the call and writes the summary. Notion is where the work is tracked. promisedby is the step in between: it reads the commitments out of the transcript, shows them to you as a short list, and files the ones you approve into a Notion database as real rows.

What actually gets created

One Notion page per approved action item, in the database you pick. Not a block of meeting notes pasted into a page — individual rows, in the database you already track work in, with your existing properties filled in.

Each row carries:

• The task, phrased as something to do rather than as the sentence someone happened to say.
• An owner, matched against the people in the meeting.
• A due date, when one was actually said out loud.
• The quote it came from, with the speaker's name — so “did we agree to this?” has an answer.

How your Notion properties get filled

Databases are set up differently everywhere, so promisedby reads your schema and guesses a mapping rather than requiring specific column names. The guess is stored and editable — if it picks wrong, you change it once in settings and it stays changed.

Owners are matched by email against the members of your Notion workspace. When someone in the meeting is not a member — an external client, a guest — the task is still created and the owner is reported as skipped rather than silently dropped or assigned to the wrong person. The same applies to a date nobody stated precisely: “early next week” is not a date Notion accepts, so it is left empty instead of invented.

Nothing files itself without you

Every detected item goes into a review queue first. You approve, edit or drop each one, and only then does anything reach Notion. This is deliberate and it is not going to change: language models misread meetings. They miss items, invent detail, and mistake who was speaking. A tool that wrote directly into your tracker would be handing you a cleanup job instead of removing one.

The queue is built for speed rather than thoroughness — it is a short list, keyboard-first, and usually takes about ten seconds for a normal meeting.

Filing twice does not duplicate anything

Tasks that were already filed are recognised and left untouched, so re-running a meeting after fixing one item does not produce a second copy of the other five. If a single task fails — a property that no longer exists, a revoked token — the rest still file, and you are told which one did not and why. Partial success is reported as partial success.

Setting it up

1. Connect Fathom. This registers a webhook, so meetings arrive on their own once a call ends.
2. Connect Notion and pick the database tasks should land in.
3. Check the property mapping it guessed, and adjust it if your database uses unusual column names.
4. Run your next meeting as you already do.

If a meeting is ever missed — a deploy mid-restart, an outage that outlasts Fathom's retries — you can import it by hand from the recordings Fathom already has. Nothing is stranded because a webhook arrived at a bad moment.

What this does not do

Worth being direct about, because the boundary is the product:

• It does not replace Fathom. Keep recording exactly as you do now.
• It does not replace Notion. Tasks land in your database, under your structure.
• It does not sync back. Completing a task in Notion is a Notion concern; promisedby files it and gets out of the way.
• Fathom is currently the only supported source. If you use a different notetaker, tell us — it affects what gets built next.

Your meetings are not training data

Transcript content is processed to produce your tasks and for nothing else. The privacy policy names every provider that touches it.

Tracking work in Linear instead? Fathom to Linear.