Hello, soulmate! My systems developed from the need to function despite having no natural abilities to remember and organize things. I also tend to take literal notes. Here I'm talking about meeting notes, not notes from texts. I've evolved my system to use minimum tech support because the tech changes from job to job. Now all I need is a document editor and a filesystem.
I'm not saying you should do these things. I'm just offering the palette that I've evolved and saying that this somewhat works for me. Everything here came about as an adaptation in response to the pain of not doing it.
1. I only take verbatim notes in meetings where I'm not in charge of the pacing. Even when doing that, I try to notice the things I'll need later: commitments to actions, unresolved questions, specific decisions. I bold those so they're easily findable.
2. If I'm in charge of the pacing, then I only write down what I need to. Experience has taught me that we meet for different reasons and I try to focus on the things I'll need later: decisions, actions, open questions, key frames of the discussion. For the latter, I'll make grids or lists as a representation of the frame and share my screen so everyone can see and we can build the artifact together.
3. I have found it impossible to say something and take notes on it simultaneously, so when I'm a participant I have to remember to end my thought with "ok, now give me a sec to write that down."
4. Sometimes we're meeting to build something together: a schema, a plan, a proposal. In that case, I'm not taking meeting notes. I'm editing the schema/plan/proposal and keep track of actions and unresolved decisions in the doc. The document is done when there are no more actions left to do and no more decisions to make (or we can live with the unmade decisions).
5. I use a filesystem to organise my meeting notes, and fulltext search over it. One file per meeting generally.
6. These are Word files, ymmv. First thing in the file is title-styled description of the meeting purpose (sometimes just a company name if it's us meeting them). Second thing is list of participants, broken down by company if it's that kind of meeting. Then it's bulleted list notes.
7. The filename is the title and date. I can search filenames by project and see in the list of results what date the meeting happened (may not be last modified timestamp on the file).
8. Can't emphasize enough taking notes with the end in mind. Experience has taught me that there are some things I need to write down: the things I say about how we'll do things that I need to have a record of so I can say "no, we told you this would happen"; product and company names; any actual needs/requirements/problems from customers or staff; any commitments explicitly made or not made (and listen for commitments being glossed over or implied, and ask questions to make them explicit so they can be recorded).
9. If you're calendared/scheduled then book time after meetings to deal with the notes and actions and questions from that meeting. Otherwise you just accumulate open loops that sap your will to live. Share the notes to participants as soon as you can (I often do it at the wrapup of the meeting).
10. I'll assemble notes on product or technical things to understand them. There I look for what problem they try to solve, the moving parts I'd need to know, the key bits of logic, dependencies, etc. These get published on the intranet because if I've had questions, other people will too. They're never perfect, almost always still unresolved questions, but they're good enough to answer a lot of questions for me and others. I book meetings to go through them with people who hold wisdom in that area, and we answer questions and uncover new areas together. I'll screen- or document share so they can see what we're working on. I know these work -- I forget I've written some and I'll have a question, go search the intranet, and discover that I answered that question for myself 18 months ago and present me thanks past me.
11. I can't really help with context switching. As I took more and more notes, I got better at it. The trick is to be listening at the meta level, to recognise things that need to be recorded. Using numbered/bulleted lists keeps the amount of context in my doc almost to zero. If I'm transcribing a meeting, I'm just adding something new. If it's one I'm running then I might have a bulletpoint for Next Steps and record explicit actions there as they're uncovered. Also, see my final para in this post.
12. If you do record Next Steps, say WHO and if possible BY WHEN. And if the WHO is you, add it to your own todo list in the post-meeting time or it'll be forgotten. Any time I have more than one todo list, I've lost. (Not saying I always win even when I have one todo list!)
Meeting notes example: when we meet Quality Foods to talk about integrations on May 1st, I'll make a file called "Quality Foods Integrations 2024-05-01" and it'll start with:
<Title>Quality Foods Integrations 2024-05-01</Title>
Attendees: Nat, Alex (Ontempo), Alice, Bob, Charlie (Quality Foods)
* Looking at two different systems, one for finance and one for marketing.
* Finance = Microsoft Business Central, using a third party specialist to configure it.
* Don't know the integrator yet.
* Marketing = MailMuch.
* <b>No API docs.</b>
* We have BC integration already. MailMuch is new.
* Explained the flow of an integration: scoping, requirements, iterative development. Time and materials.
etc. (<title> and <b> to indicate styling. I'm not actually writing in HTML.)
And finally, a note is not a general purpose winning tool. I still find I've missed things, wish I'd written down things, can't find notes from a meeting I'm sure I was at, etc. You always will. Don't look on perfection as the goal: they should help most of the time, and if there are occasional lacunae that's still better than not having them.