People, not piles: why meeting notes should orbit humans

Chronology is a lie we tell our tools

Open any meeting-notes product and you will find the same information architecture underneath it: a reverse-chronological pile. Monday's standup sits on top of Friday's pipeline review, which sits on top of last month's kickoff. It looks organized. It photographs well in a marketing screenshot. It sorts cleanly, because a timestamp is the one field every recording is guaranteed to have.

It also answers a question almost nobody asks. Think about the last time you opened your notes. Were you looking for "what happened on the 12th"? Or were you five minutes from a call, trying to remember where you left things with the person about to join it? The date is how the software filed the meeting. The person is how you actually think about it.

That gap between how notes are stored and how they are used is not a cosmetic problem. It is the reason most people capture diligently for a month and then quietly stop opening the archive. A pile grows. A pile does not prepare you for anything. When the tool's structure fights the way memory works, the tool becomes another folder you feel guilty about.

The question you actually ask

Picture the minutes before a call with someone named Maya. You are not reconstructing a timeline. You want four concrete things, fast: what the two of you discussed last time, what she owed you, what you owed her, and whether this relationship has been warming up or going quiet. A date-sorted archive makes you assemble all four by hand, skimming six half-remembered transcripts to rebuild a picture you already half-hold in your head.

A page built around Maya just answers it. This is the whole argument in one sentence: notes should be organized around the people in them, because people are the axis you retrieve on. You do not remember conversations by their coordinates in time. You remember them by who was in the room. Software that mirrors that shape disappears into your workflow. Software that fights it makes you do the reconciliation the software was supposed to do.

None of this is a knock on chronology as a fact. Meetings do happen in an order, and sometimes the order matters. The claim is narrower and more useful: chronology is a bad primary key. It should be a column, not the spine.

The person page is the prep document

In Savory, a meeting does not land in one bucket. It files itself under everyone who attended. Record a call with Maya and Devin, and that conversation now lives on Maya's page and on Devin's page at the same time, without you tagging anything. The unit of storage is the meeting; the unit of retrieval is the person; and the same recording can belong to several people at once, exactly the way a real conversation does.

Open a person and you get their whole history in one place: past meetings with their summaries, when you last met, how often you tend to meet, and the items still open between you. The prep document you used to build by hand, the one you would assemble in a notes app the night before a quarterly check-in, now assembles itself continuously, as a side effect of meetings you were already having. You did not do extra work. You did the meeting, and the page kept score.

This is the part that is easy to underrate until you live with it. The value is not that the notes exist. Notes have always existed. The value is that they are pre-sorted into the exact shape you need them in at the exact moment you need them, which is standing outside a room about to walk in.

Cadence: seeing a relationship's rhythm

Once meetings orbit people, a quiet signal becomes available that a pile can never surface: rhythm. Savory looks at the real gaps between your past meetings with a person and sorts the relationship into a plain cadence, weekly, every two weeks, monthly, or occasional. It is computed from your actual calendar history, not a number you set and forget.

The point of a coarse bucket is honesty. Savory is not going to tell you a relationship is "trending down twelve percent this quarter," because that is a precision the data does not support and a promise other tools make and cannot keep. What it will do is let you see, without hunting, that someone you used to meet weekly has slipped to occasional. The judgment about whether that matters stays yours. The software's job is to make the pattern visible, not to nag you about it or invent an urgency it cannot actually measure.

That restraint is a design position. A cadence you can trust at a glance is worth more than a dashboard of arrows you learn to ignore.

The ledger: commitments run both ways

Here is the piece almost every competitor misses, and it follows directly from choosing people as the center of gravity. Commitments are not a personal to-do list. They are a two-sided relationship. In every real working relationship there are things the other person owes you and things you owe them, and the second list is the one that quietly damages trust when it slips.

Savory's per-person ledger splits open items into two columns, "They owe you" and "You owe them." Items come from two places: they are pulled out of a meeting's summary when you generate one, or you add them by hand. Each can carry a due date. Walking into a meeting already knowing both sides of the ledger changes the meeting, because you are not bluffing about the follow-up you forgot, and you are not letting theirs quietly expire either.

Getting the second column right is harder than it looks, and it is worth being precise about how it works. When a summary is generated, Savory resolves each action item to a real person on your device, matching the named owner against the people who were actually in the meeting. An item it can confidently attribute lands in the right direction on the right person's page. An item it cannot pin down stays unassigned rather than guessing, and you can place it with a tap. The reconstruction of "what you owe them" leans on the identity of the meeting itself, so an item you committed to in a specific call surfaces on the page of the person you committed it to. Nothing about that attribution leaves your Mac.

Two honest caveats, because a ledger you cannot trust is worse than none. The automatic extraction only happens when you generate a summary, which is an optional, opt-in step; a meeting you only transcribe will not sprout action items on its own until you ask or add them yourself. And a due date the model reads out of the conversation, something like "by Friday," is written as text you can see, not as a countdown. The moment you want a real overdue or due-this-week signal, you set a date on the item and Savory tracks it from there. The ledger never pretends to know a deadline it was never actually given.

What people-first organization unlocks

The strongest argument for a design choice is not the feature it adds. It is the pile of features that fall out of it for free, the ones you would never bother to build on top of a chronological list because they would feel bolted on.

Search is the clearest example. When people are first-class, you can find a meeting by who was in the room, which is how you actually half-remember it. You do not recall the date of the call where pricing came up. You recall that Devin was on it. Attendee search turns that fragment of memory into the meeting.

Shared history is another. Because the same conversation lives on every attendee's page, a meeting can point back to the last time this topic came up with these same people, so a recurring thread reads as a thread instead of a scatter of disconnected calls. That connection is a natural consequence of filing by person; on a pile it would be a feature nobody ships.

And all of it sits on the same foundation the rest of Savory does. Capture happens on your Mac, transcription runs on device, and the audio is never written to disk. The person page, the cadence, and the ledger are built from notes that never had to leave your machine to become useful. People-first is not only a better retrieval model. It is a better retrieval model that never turned your relationships into someone else's dataset.

Why a pile cannot retrofit this

A fair question: if organizing by person is this useful, why not add a "people view" on top of an existing chronological product? Some have tried. It tends to arrive as a filter, a way to show the subset of the pile that a given person appears in. That is a search result, not a home. It does not accumulate a two-way ledger, it does not compute a cadence you can trust, and it does not make each person a durable place that gets richer every time you meet.

The difference is where the center of gravity lives. If the meeting is the record and the person is a tag, the person will always be a view onto a pile. If the person is the record and the meeting files itself underneath them, the person becomes the thing you actually maintain a relationship with inside the software, which is the thing you maintain a relationship with outside it. You cannot bolt that orientation on afterward. It is a decision you make at the center, and everything good downstream depends on having made it there.

Your meetings already orbit people. Your notes should too.