Board and supervision Decision list with owner Mandate and quorum

Custom meeting management software development

A meeting is quick to schedule. The real work comes afterwards: which decision was taken exactly, on what grounds, who was entitled to take it, who carries it out, and how you can tell it actually happened. For boards, executive committees, supervisory boards and works councils, this is not administration but the core of accountability. Appfront builds custom meeting management software that combines the agenda and meeting papers into a single bundle, assigns each decision an owner and a deadline, makes minutes verifiably approved, and keeps an archive that can answer a regulator's question without searching through mailboxes.

Free consultation Package or custom?

Meetings are not the subject, decisions are

Collaboration software is about communication: conversations, file sharing, a shared calendar. That helps during the discussion, but it hardly keeps anything that will later carry evidential weight. Agenda management is about finding a time that suits everyone. Meeting management is about something else: the cycle in which a topic is put on the agenda, supplied with papers, leads to a decision, and is then carried out and accounted for. The end product of that cycle is not a meeting that ran smoothly, but a decision that can be traced, with a basis, an authority, an outcome and a record of what was done with it afterwards.

That is why a well-designed system revolves around three linked registers, not around a calendar. The first register holds the agenda items with their papers and their origin. The second holds the decisions, each with an owner, a deadline and a status. The third holds the action points, including those nobody is eager to pick up and which therefore disappear into the body of a report. Anyone who keeps these three separately, in a word-processing document, a spreadsheet and a mailbox, runs into the same problem at every change of board and every question from the auditor: the data exists, but it cannot be queried.

The pattern is remarkably consistent across sectors. A care organisation with an executive board and a supervisory board, a housing association with a supervisory board and an audit committee, an education board with an executive board alongside a works council, a pension fund with bodies that each have their own role, an association with a members' meeting, a municipality with a mayor and aldermen and a council: the vocabulary differs, the underlying objects do not. There is always a body with authority, an agenda item with documents, a decision with an outcome, an action point with an owner, and an archive from which someone must later be able to retrieve something. Whoever sets up a system around those objects rather than around a minutes template keeps it useful as the organisation changes.

Are you in the right place? This page is about the closed side of decision-making: boards, executive committees, supervisory boards, works councils and members' meetings. If your interest is in publicly searchable publication of council and committee papers for residents, you want a council information system. If it concerns documents that must pass through fixed approval steps outside a meeting, then document workflow automation is the better starting point. Many organisations have all three side by side, and the real question is which system is the source of truth for a decision.

The decision is the product

The outcome is not the minutes but the decision record: subject, basis, authority, outcome, owner and deadline, separately retrievable.

Authority belongs to the decision

Who was entitled to decide this, was the quorum met, and did anyone with a conflict of interest take part? These are fields, not sentences in a report.

Confidentiality is the rule

Board papers contain staff matters, tenders and incidents. Access works per document and per role, with a record of who has looked at what.

From meeting bundle to a decision with an owner

Compiling the documents may seem the simplest part of the cycle, yet in practice it is where most of the time disappears. A board secretary collects a management report from finance, an advisory memo from a policy officer, a draft annual report from the auditor, and a memo that is only finished at the last minute. These documents are merged into a bundle, usually a PDF of several hundred pages, and sent by email. Then one document is replaced and a second bundle goes out. From that point on, nobody is certain who is reading which version, and in the meeting it turns out that a member is still looking at the previous memo. It is a small inconvenience with a large consequence, because a decision taken on an outdated document is a decision that has to be made again.

There is a second problem at the front end, and that is the quality of the document itself. An advisory memo that opens with a page of context and only asks for something at the bottom forces the meeting to formulate the decision on the spot. A fixed heading structure solves this: the decision requested, the background, the alternatives considered, the budget implications, the main risks, the advice from finance or legal, and whether the item has already been through a committee. Such mandatory fields shift the discussion from form to substance, and they give the board secretary an objective ground for returning a document. The latter matters more than it sounds, because an agenda clogged with unfinished memos is the most common reason meetings overrun and the difficult items end up at the end.

What solves this is not a faster PDF generator but an agenda item that is an object in its own right. An agenda item has a type, and that type determines what is expected of the meeting: for decision, for discussion, for noting, or for opinion. An item for decision requires an explicitly stated decision requested, worded in the form in which it will later appear in the minutes. That single field often does more for the quality of a meeting than all other functionality combined, because anyone who cannot write the requested decision in one sentence has not yet finished the document. Every document is attached to the agenda item, with a version, an author and a date, so that the bundle reflects the current position and not a snapshot from someone's sent items.

Where those figures come from determines how much manual work is left. Financial reporting sits in the accounting or planning system, absence figures sit with HR, safety or quality reports sit in an incident system, and project progress lives in its own environment. As long as someone retypes those figures into a memo, the pack is a snapshot with a risk of errors and an argument about which version is current. An integration that generates the standing reports from the source, with the cut-off date included, removes that work and that argument. The meeting invitation in participants' calendars belongs to this too: the meeting sits in their mail calendar, with a link to the pack rather than an attachment that is out of date after a single change.

Then there is the decision log. This is the heart of the system and, at the same time, the part that is set up worst in most organisations, because it has become a table at the bottom of the minutes. Each decision should be its own record: the text of the decision, the agenda item and the document it rests on, the body that took it, the date, the outcome, the vote if there was one, a named owner, and a deadline by which they report back. That makes the decision log searchable. You can see which decisions were taken on an investment, which have not yet been carried out, and which have since been amended or withdrawn, with a reference to the decision that now applies.

A decision also rarely stands alone. There is a proposed decision that only becomes final once the works council has given its advice, there is a conditional decision, for example while a financing arrangement is still pending, and there is a decision that amends or withdraws an earlier one. This is exactly where most decision logs break down: the conditional decision remains forever in the status "approved", because nobody recorded when the condition would be met. A decision record with an open condition, a person responsible for fulfilling it, and a date for reporting back closes that gap. And a decision that replaces an earlier one should refer to it visibly, so that someone reading the history of a file two years later does not get stuck on the middle decision.

Action points that survive the meeting

Action points are the simplest feature of a meeting system and the most neglected. They arise during the discussion, they are assigned verbally, they end up in the minutes, and then nothing happens until someone asks about them at the next meeting. The cause is structural: an action point in the minutes has no address. It sits within the running text of a document that is mostly opened to check how something was worded.

In a system, an action point is linked to the agenda item and to the decision it arises from, and it has an owner, a deadline and a status. More important is what happens next. When the next agenda is prepared, the list of outstanding points is included automatically, with a request for a brief update on each. An action point that has already been postponed three times cannot be hidden any longer, because that history stays attached to it. And if an action point is no longer needed, a reason for closing it should be recorded, because letting items quietly disappear is precisely the habit you want to break with such a system.

What meeting management software should be able to do

These components are interlinked. A decision register without an owner becomes an archive in which nothing about implementation can be found, and an action list without a reference to the decision it stems from becomes unreadable after a change of board. Below are the features we most often deliver for governance decision-making, each set up around your own bodies, mandate levels and confidentiality arrangements. We determine together with the board secretary or clerk which fields a decision should carry, as they know which questions are asked in practice about an old decision. The terminology also follows your organisation: advice, approval, adoption and decision are not synonyms, and a system that uses them interchangeably produces a register no one dares rely on.

Agenda item with requested decision

Each item receives a type and, where it concerns decision-making, an explicit requested decision with the documents attached to it. The agenda thereby becomes the working list of the meeting, not merely a timetable.

Bundle per recipient

The bundle is assembled at the moment a person opens it, from the current versions and from the documents that this person is permitted to see. An invitee to a single item does not receive the entire folder.

Decision register

Each decision as its own record with basis, body, outcome, owner, deadline and status, searchable across years and linkable to the decision it amends or withdraws.

Action points with provenance

An action point knows which decision and which agenda item it comes from, who carries it out, and when they report back. Open points carry over to the next agenda, with their own history.

Minutes with adoption

The draft goes to the participants, proposed amendments are kept with the minutes, and the adoption at the next meeting fixes the text with a timestamp and the name of whoever adopted it.

Voting, quorum and proxy

Attendance, proxies and the required majority follow your own rules. The system checks the quorum, records abstentions and keeps track of who did not take part because of a conflict of interest.

Mandate, quorum and the validity of a decision

A decision is not valid because it appears in the minutes, but because it was taken by whoever was authorised to do so, in the manner prescribed by the articles of association and regulations. In many organisations this runs across several layers. The board decides, but for certain categories approval from the supervisory board or the supervisory council is required, and a director acts within a mandate that goes beyond day-to-day business but is not unlimited. A system that only stores decisions then misses half the picture: the board decision and the approval decision should be two records that refer to each other, because without that link it cannot later be seen whether the decision was complete.

In practice, a mandate arrangement works with categories and limits: a type of decision, a value above which another body takes the lead, and sometimes an exception for urgent matters. At many organisations that arrangement sits in a document nobody consults when setting the agenda, and this is exactly where the system should help. Whoever submits an item states what it concerns and its scale, and the system shows which body is competent and whether approval is needed. That prevents the unpleasant scenario in which it only emerges while preparing the annual report that a decision was taken at the wrong level and must be ratified after the fact.

The same applies to the format. Quorum, simple or qualified majority, whether an abstention counts and whether proxy voting is allowed: all of this is set out in your articles of association and regulations, differs per body and can't be pulled from a default setting. Making those rules explicit takes work, and it is exactly the work where a custom setup pays for itself. This also covers decision-making outside meetings. A decision taken in writing or by circulation must be recorded in the same way as a decision taken in the room, including the reason why it couldn't wait and its ratification at the next meeting.

A conflict of interest is the third element. A board member who has a personal interest that conflicts with the organisation's interest does not take part in the deliberation and decision on that item. Since the Wet bestuur en toezicht rechtspersonen (Act on Governance and Supervision of Legal Entities) came into force on 1 July 2021, such a rule also applies to associations and foundations, and the governance codes for housing associations, care organisations and listed companies require it to be recorded. In practice this means a field on the decision: who did not take part, and why. Burying that in a sentence of the minutes means it cannot be demonstrated later without rereading the entire document.

Pay attention here to the difference between bodies and committees. An audit committee, remuneration committee or quality committee prepares and advises, but as a rule does not decide. A system that treats every meeting as a decision-making body creates a register in which advice appears as decisions, and that is harder to explain in a supervisory enquiry than a missing set of minutes. Advice should therefore be attached to the agenda item as advice, with the committee that gave it and the date. The same goes for the situation where a board member is temporarily unable to act or a seat is vacant: since the introduction of the Wet bestuur en toezicht rechtspersonen, the articles of association must include an arrangement for this, and when such a situation arises it is useful if the system can temporarily pass the authority on without anyone having to reconstruct it afterwards.

From draft to approved minutes

Minutes are where an organisation's care becomes visible most quickly. There are two layers: the list of decisions, which is brief and factual, and the report, which sets out the reasoning. The draft goes to the attendees, proposed amendments are recorded in the report rather than in a loose email exchange, and approval at the next meeting is itself a dated decision. Once approved, the text no longer changes: a correction takes the form of a rectification in a subsequent report, with a reference to the passage it replaces. If the meeting is recorded or automatically transcribed, that is a tool and not the minutes, and it needs agreements on the legal basis, informing the attendees, and the point at which the recording is deleted.

Board decision and approval decision that refer to each other
Quorum and majority set up per body, not assumed
Proxies, abstentions and the voting split recorded with the decision
Conflict of interest recorded as a fact, with the reason
Decisions taken outside the meeting, recorded in the same way
Approval of the minutes as a separate, dated decision
Rectification rather than a silent change after approval

Confidential documents, access by role and the archive

Board papers are rarely neutral. A typical bundle contains a personnel matter, a negotiating position, an incident report and a report from the internal audit function. Managing access by folder doesn't work here, because a folder's structure says nothing about the sensitivity of an individual document. What does work is access per document, combined with roles that follow your own structure: a director, a member of the supervisory board, the board secretary, a controller with read access to the financial appendices, and a guest who only attends a single agenda item. The bundle is then assembled per recipient, so that a confidential appendix does not travel along in a file sent to the entire distribution list.

In addition, confidentiality should have an expiry date. A document that is sensitive today often is no longer once a transaction or procedure has concluded, and confidentiality that never lapses makes the classification meaningless over time. So record, for each document, the basis for it, who imposed the confidentiality and the point at which someone reviews whether it is still needed. For public sector organisations there is a second reason for this record: a document that is classified now may later be requested under the Dutch Open Government Act (Wet open overheid), in force since 1 May 2022. Anyone who can then find, for each document, which basis was applied and whether it still holds does not have to start that assessment from scratch.

For the content of the documents themselves, data minimisation is the most sensible design rule. A document in the bundle contains what is needed for the decision requested, not the complete file: at a care institution that often means aggregated figures rather than traceable client data, and at a housing association a case without the tenant's name. Anyone who views a document should be evidenced in an access log, because that is the only way a document that has probably leaked can still be investigated. Retention periods belong in the same set-up: documents may expire while the decision record remains, with a reference that shows the underlying document has been deleted in line with the established period. At public bodies these periods are fixed in selection lists under archival legislation. If the question extends beyond the meeting, a document management system is the place where versions and retention periods belong.

In practice, how well this works depends on how members read the documents. Many board members and supervisory directors work on a tablet and want to keep working without a connection, so whether documents may be stored locally is a real trade-off: it makes reading more pleasant, but it makes the access log less complete. Sign-in ideally runs through the identity provider your organisation already uses, with a second factor for external members who do not have an account in your environment. Personal notes on a document should stay private and be unreadable even to administrators, because a supervisory director who suspects their notes are being read will simply stop making them in the system. And be honest about what a watermark does: it makes a leaked document traceable, but it does not stop anyone photographing a screen.

At the end of the cycle sits the archive, and that is not a side issue but the reason many organisations start on this topic in the first place. The auditor asks for the decisions on an investment, a supervisory board wants to know how a risk was handled and on the basis of which document, and a new member of the supervisory board wants to read the history of a file without having to phone three people. A usable archive delivers that as a coherent whole: the decisions of a period or body, together with the papers they rest on, attendance, the voting record and the moment of adoption. Underneath lies a log that is only ever appended to and never rewritten, so the sequence of events is fixed. If findings and measures also need to be followed up outside the meeting, that connects to custom audit software.

Bundle per recipient Confidentiality with grounds Access log Access by role Immutable decision records Adoption with timestamp Retention periods Export for supervision Single sign-on

When an off-the-shelf package is the better choice

Meeting management is not an empty corner of the software market. Mature board portals exist for supervisory boards and boards of directors, governance modules sit alongside Dutch case management systems, and many organisations already use meeting functionality within their document systems. For a considerable share of readers of this page, such a solution is the wiser route, and we would rather say so now than halfway through a project. If you work in the public sector, the question often overlaps with a broader need, and then a conversation about software for municipalities is a more logical starting point than a standalone meeting system.

If your cycle follows the usual pattern of agenda, bundle, minutes, decision list and action points, with a board and a supervisory body, then you can buy that off the shelf, including maintenance and adjustments for changing regulations. Your effort shifts from building to implementing, and on this subject that is already the hardest part: making the rules explicit and getting the organisation used to the idea that a decision only exists once it has been written down.

Custom development pays off in fewer situations than vendors suggest, but the cases where it does pay off are clear to identify. The first is a decision-making structure that does not fit a standard model: a holding with subsidiary boards, a housing association with committees that hold their own powers, a pension fund with a board alongside bodies with their own role, or an organisation in which a decision passes through more than one approval layer. The second is when the documents must come from your own systems, so that a report is not attached by hand but generated from the source where the figures originate. The third is when the decision register must feed other processes, for example a risk register, the follow-up of audit findings or the monitoring of the projects on which a decision has been taken.

If you choose to build, the most practical approach is to start with one body and one complete cycle, and only then add the other bodies. The hardest part is then not the technology but the agreements underneath it, and those surface immediately in a first cycle. Who may put items on the agenda, and who decides what gets dropped? When does the agenda close, and what happens to an item that arrives late? What does an action point mean when its owner leaves the organisation? May a member add an item during the meeting, and how does it end up in the pack? Questions like these belong in a working session, and they prevent a series of revisions later, because they determine which fields are mandatory and who may take which step.

The downside belongs in the picture too. With a custom build, keeping track of changing codes, legislation and accessibility requirements falls to your own organisation, and in governance that is never a one-off task. The middle road is often the best answer: an existing system for the meeting environment, and custom development for the register of decisions, mandates and action points, linked to your own sources. You will make that choice best by first walking through one real meeting cycle, from the first draft of the agenda to the approval of the minutes, and identifying at each step where things currently go wrong.

If your organisation holds meetings with iBabs, see our page on an iBabs integration.

Package software if your cycle follows the usual pattern
Package software if your meeting discipline still needs to mature
Custom development for multiple bodies and mandate levels
Custom development if the documents come from your own sources
Custom development if the register of decisions feeds other processes
Middle road: an existing package, plus your own register of decisions and action points

Frequently asked questions about board management software

A council information system is the public-facing side: it publishes meetings, documents, motions and decisions for residents. Meeting management software is the internal side and is generally confidential: it bundles documents, records who made which decision and under what mandate, and tracks action points until they are closed. In a municipality the two sit side by side, with the public part of the decision list being published and documents subject to a confidentiality ground not being published.

Because a decision in a text document has no status. You cannot filter on it, attach an owner to it, set a deadline for it, or see whether it has been carried out. Once the decision becomes its own record with a basis, an owner, a deadline and an outcome, you can answer the question that is really asked later: what happened to this decision, and who confirmed it?

Quorum, majority and voting figures follow from your articles of association and regulations, so these rules are configured for each governing body rather than assumed. For each decision, it should be recorded who was present, who held a proxy, how the votes stood and who abstained. If someone with a conflict of interest does not take part in the discussion and the decision-making, that is a recorded fact attached to the decision, not a remark somewhere in the minutes.

By controlling access per role and per document rather than per folder. A board member, a supervisory board member, the secretary and a guest for a single agenda item do not see the same pack. A document with a confidentiality ground carries that ground, a retention period and an access log, and the pack is assembled per recipient, so a confidential attachment does not travel along in a file that goes to everyone.

Often, yes, and for many organisations that is the wiser route. Mature board portals, governance decision-making modules and meeting functionality in case and document management systems all exist. If your meeting process follows the usual pattern of agenda, pack, minutes and action list, you can buy that off the shelf. Custom only becomes interesting when you have your own decision-making structure with multiple bodies and mandate levels, or when the documents have to come from your own systems.

The source code and documentation belong to the client and sit in a repository to which you have access yourself. On handover, a description of the architecture, the data models, the integrations and the deployment is included, so another party can take over without first having to reverse-engineer anything. We work with mainstream technology, because that determines how many parties can take on the maintenance.

Related services

Council Information System

If decision-making needs to be public and searchable for residents, with agendas, motions, votes and recordings of meetings, then a council information system is the right starting point.

Document workflow automation

If documents need to pass through fixed steps of drafting, checking and approval outside the meeting itself, that falls under document workflow automation.

Owners' association software

In an owners' association, decision-making revolves around the members' meeting, with voting shares taken from the deed of division and decisions on maintenance. This all comes together in custom owners' association software.

A closer look at your meeting cycle

Tell us how your agenda comes about, who compiles the pack and what happens to a decision after the minutes have been approved. Also request the action list from a meeting last year and see whether you can tell who the owner was and what the outcome turned out to be. Those two answers usually show whether you can configure an existing package, or whether your decision-making structure calls for custom software.

Book an advisory call info@appfront.nl