The commitments in the doc that never left the doc

It is the Thursday before a quarterly business review. Priya, who runs customer success at a forty person software company, has two windows open.

On the left is Notion. Specifically, the Accounts database, filtered to her twelve largest customers, each row expanding into a page with the same layout: last QBR notes, an open risks callout, and a section near the bottom headed Commitments where whoever ran the call typed what the company promised. "We'll get SSO in front of engineering this quarter." "Agreed to waive the overage for June while they migrate." "Will send the security questionnaire responses by the 15th." Some have a checkbox. Most are just paragraphs, because the person writing them was typing fast at the end of a call.

On the right is Gmail. Her own inbox, and because she is an admin, the ability to search across the shared support and success aliases. She is looking for a specific thing: did anyone actually tell the customer about the overage waiver, or is it sitting in a doc that only her team has read?

She has a real reason to care. Two months ago a customer escalated because they were charged for something a call note said had been waived. The waiver was real. It was written down. It was never sent. Nobody had lied to anyone, and nobody had a way to notice.

So Priya is doing what people do in this situation. She opens an account page, reads the commitments section, picks out a phrase she can search for, switches to Gmail, types to:contact@customer.com overage into the search bar, scans the results, decides whether anything she sees counts as having communicated it, and moves to the next account. Twelve accounts, maybe forty commitments, most of an afternoon. She will get through it. She will also, quietly, know that her answer is only as good as the phrases she happened to guess.

What Notion shows on its own

Notion is genuinely good at the half of this it owns. The commitments exist because Notion made it easy to write them in the place where the rest of the account context lives. The database gives Priya a filtered view of her twelve accounts, sorted by ARR, with a last-touched date. If the team used checkboxes consistently, she would have a completion property she could group by. Notion's search will find the word "waive" across every page in the workspace, and the API exposes page content as blocks, so the text is retrievable, not trapped.

Where it stops is precise, and it is not a shortcoming: Notion knows what was written in Notion. It has no basis for an opinion about whether a sentence in a doc corresponds to anything that happened outside the doc. A checkbox marked done tells you a human ticked a box. It does not tell you an email went out, and in practice the box is the first thing to go unticked when the week gets busy.

There is a second, subtler stop. The commitments are not a field. They are prose inside a section, written by five different people with five different habits. One wrote "we said we'd waive June overage." Another wrote "billing adjustment agreed, see thread." A third wrote a bulleted list under a heading called Follow ups because that is what the template said last year. Notion can return all of that text. It cannot tell Priya which of those sentences is a promise to a customer, which is an internal to-do, and which is a note about something the customer promised us.

What Gmail shows on its own

Gmail is the record of what left the building. Its search is fast and more capable than most people use: to:, from:, after:, has:attachment, quoted phrases, all of it working over years of mail in a fraction of a second. If Priya knows the exact wording, Gmail will find it. If she knows the customer's domain, she can pull every thread with them and read forward.

Where Gmail stops is the mirror image of Notion's stop. Gmail knows what was sent. It has no idea what was owed. There is no list of promises for it to check against, and no reason there would be: an inbox is organised by conversation and time, not by obligation. Search only works when you already know what you are looking for, which means the recall of Priya's audit is bounded by her ability to guess phrasing. The email that fulfilled the overage commitment may say "I've spoken to our finance team and you won't see that line on the June invoice," which contains neither "waive" nor "overage."

And Gmail cannot rule anything out. A search returning nothing means those words were not used. It does not mean the thing was not communicated.

Why the gap is structural, not a missing feature

Lay the two halves next to each other and the asymmetry is the whole story.

The reason no integration closes this is that only one half of the evidence is a record. The Gmail side is structured: sender, recipients, timestamp, thread. You can count it, join on it, put it in a table. The Notion side is a sentence a human wrote in the last ninety seconds of a call, with no schema and no guarantee of vocabulary. There is nothing to join on. A commitment is not a row with an ID that an email can reference.

This is also where the usual tooling honestly stops, and it is worth being specific rather than dismissive. Zapier, Make and similar automation platforms are excellent at this pair, and they run on triggers: when a Notion page changes, do something; when an email arrives, do something. They move records forward from the moment the trigger fires. That design is exactly wrong for Priya's question, which is entirely about the past, about forty commitments made across the last quarter by people who did not tag them, and about which of those did not produce a corresponding action. No trigger fired for the email that was never sent.

BI tools have a different, equally real limit. Looker Conversational Analytics and Power BI Copilot will both take a question in plain English and answer it well, over databases and modelled sources. But half of Priya's evidence never becomes a modelled source. It is a paragraph in a doc. You could pipe the raw text into a warehouse column, and you would then have a column of paragraphs that the semantic layer has no way to reason about. The evidence is not badly modelled. It is the wrong shape for modelling.

What the join actually requires

Two things, and only one of them is mechanical.

The key is the account, resolved through the customer's email domain. A Notion account page has a domain or a set of contacts on it. A Gmail thread has recipients. That gets you from a commitment to the right slice of mail, roughly a few dozen threads instead of years of inbox. This part is matching, and matching is easy.

The judgement is everything after that. It has three parts, and none of them are lookups.

First, deciding which sentences in the commitments section are actually commitments to the customer. "Will send security questionnaire responses by the 15th" is one. "Check whether their contract auto-renews" is an internal task wearing similar clothes.

Second, deciding whether any message in that slice communicated the thing. Not whether it contains the same words, but whether a customer reading it would understand that the promise had been kept. "You won't see that line on the June invoice" satisfies the waiver commitment. A thread that mentions the invoice in passing does not.

Third, deciding what counts as sufficient. A commitment mentioned in the second paragraph of a long email about something else is technically communicated and practically invisible. A reasonable audit flags that as weak rather than clean.

Each of those is reading. Not matching, not filtering, not a smarter search operator.

Doing it with Skopx

Skopx connects to Notion and Gmail among nearly 1,000 integrations, and the point of connecting both is that a question can cross them. Priya would type something close to what she was already thinking:

Go through the Commitments section on every account page in the Accounts database updated since April 1. For each commitment we made to the customer, check the Gmail threads with that account's domain and tell me which ones were never communicated. Show me the doc line and the email you matched it to.

What comes back is a list, per account, with three states: communicated, with a link to the specific message; not communicated, with the doc line quoted; and ambiguous, with the near-miss thread attached so Priya can decide. Every line cites its source, so her first instinct, to check whether the machine is right, is a click rather than a re-run of the whole afternoon.

Once she has run that twice and trusts the shape of the answer, the natural next step is to stop typing it. She describes the same thing as a console: a table of open commitments across all twelve accounts, columns for account, commitment, date written, who wrote it, and communication status, filterable to the ones with no matching email. That is what Skopx's internal apps are, a working console built from a sentence in chat, reading live from Notion and Gmail each time someone opens it. Add a button on each row that drafts the follow up email to the right contact, and it stays a click a human makes with a confirmation, not something that fires on its own.

Team is $16 per seat per month with 2.3 million AI tokens included. Solo is $5. There are SOC 2 controls in place, and account access follows the permissions of the person asking, so a rep sees their accounts and Priya sees all twelve.

What this does not do

It does not watch. Nothing fires when a commitment is written and goes uncommunicated for a week. There are no scheduled runs, no alerts, no notifications. Somebody has to open the console or ask the question.

It does not store the answer. The console reads Notion and Gmail live and shows you what is there right now. It does not maintain its own commitments table, does not create records, and does not write a status back to the Notion page. If you want a durable system of record for commitments, this is not that, and you should build the field in Notion.

It does not replace the discipline of writing commitments down. If nobody typed it, nothing can find it.

And it does not adjudicate. On the ambiguous cases, and there will be a handful in every run, the answer is a pointer to the thread and a note about why it is uncertain. A person still reads it and decides. That is the correct division of labour, and it is also the honest one: the reason the afternoon was long was never the searching. It was the judgement, and the judgement is still Priya's. What changes is that she spends it on eight uncertain cases instead of on forty guesses at search phrasing.