Solution 08 · PrivatActions
One board for every open item, live on every device
Whatever arrives by mail, chat, calendar, meeting or assistance system is collected and prioritised in one single place. Every surface reads the same state and changes it through the same interface: the browser on the desk, the phone in your hand, the voice assistant on the line, the automations in the background. A tick is a tick everywhere, in the same moment.
The state lives in a core on your own infrastructure, rather than as a copy on each device. Synchronisation does not disappear because it runs faster. It disappears because there is only one place left where an item gets completed.
Four lists, four versions of the truth
Open items appear in every channel: a mail with a deadline, a question in a chat, a commitment made in a meeting, a follow-up from last quarter. Whoever collects them usually collects them more than once. And as soon as two lists carry the same item, neither of them can be trusted. This is a question of construction rather than discipline: as long as every surface keeps its own copy, reconciliation never ends.
One board: what is due, why, and who is working on it
The surface shows the open items in rank order, with their priority class, the signals that moved them up, and the actions that are booked immediately. Anything another surface is working on right now is visibly locked and cannot be touched here. The header states since when the view has been live on the core.
One state core, many surfaces
The core is a journal: every action is appended once, and the current state of each item follows from the sequence of actions. The surfaces calculate nothing themselves. They show what the core says and report back what someone did.
Live instead of a sync run
The surfaces hold an open connection to the core and receive every change as it happens. A surface that was offline for a while picks up exactly the events it missed, rather than the whole list. The phone buffers actions while out of reach and replays them afterwards, without anything being booked twice.
Locks, deliberately simple
Whoever opens an item borrows it briefly. Other surfaces show it greyed out with a note on where it is being worked on. The loan extends while someone is working and expires on its own when a device dies. Every change is also checked against the version the surface had in view.
Priority you can explain
Class, ranking and signals come from a single rule table. No surface calculates on its own, and the voice assistant reads out the same order that is on the screen. Each item can be unfolded to show which rule applied. Whatever you raise by hand stays up and is never overwritten by a later run.
Projection into your own knowledge store
The core writes every change of status back into your store, in the same format as before: completed with reason and timestamp, an entry in the completion log, a follow-up in the calendar sheet. Existing views and reports keep running, and the history stays where it will still be readable in five years.
Why is this at the top? The answer travels with the item
Prioritisation rarely fails because of the formula. It fails because the formula is calculated in three places in three different ways. In the core it exists once, in a versioned rule table, and it works in three stages.
| Stage | What it sets | What it is built from |
|---|---|---|
| Class | P1 to P4, the broad level of urgency, readable for everyone on the team | Importance of the contact, deadline, an appointment in the next few days, a blocked process. Can be changed by hand, and is then protected from automated runs |
| Ranking | The order within a class | Importance times urgency, lifted when the other side wrote last, dampened when an item has been shown often and never touched |
| Signals | What stands out on top: new and urgent, overdue, follow-up due, aged, cross-check open | One table used by the board, the desktop notification and the voice assistant together. A signal triggers the same thing everywhere |
The core runs inside your network
The open items say what your company is working on right now: which clients are waiting, which deadlines are pressing, where things are stuck. That is one of the densest summaries of a business there is. It does not belong in someone else's service.
| Runs on your own infrastructure | A small service on a server in the house or on a machine at a provider of your choice. No subscription that reads along with the state of your work, and no provider evaluating it. |
| Reachable only inside your private network | The surface cannot be reached from the open internet. Anyone working remotely comes in through the secured path into the company network that laptop and phone use anyway. |
| Content stays in your store | The core carries status, ranking and locks. Text, history and attachments stay where they already are and are never copied into a second database. |
| Every action traceable | The journal records who did what, when and on which surface. Nothing is overwritten, everything can be reversed, and the history of an item stays readable. |
| Nothing disappears by itself | Discarding is an action with a reason and can be taken back. An item may age and move into the grace view, yet it is never deleted automatically. |
| Honest limits | A board does not replace a decision. It makes sure the decision is taken on the right item, and that it has to be taken only once. |
Where the data sits
- State
- Journal and derived view in the service on your infrastructure
- Content
- In your knowledge store, read by the core only
- Write back
- Status, completion log and follow-ups in the familiar format
- Access
- Only from your private network, no path from the open internet
- Audit trail
- Every action with timestamp, surface and reason, reversible
- Language models
- Only where text is drafted, and then through the PrivatPrompt gateway
No additional cloud service between your devices and your open items. If the connection to the outside fails, the board keeps working inside your own network.
As a project in three steps
Clarify sources and rules
Which channels create open items, which of them belong on a shared board, and which rules decide the order? The result is a first version of the priority table, written in words everyone on the team understands and can look up.
Put the core into operation
The service moves onto your infrastructure, reads in the existing items and writes the status back into your store. In this phase it runs alongside the current path, so both states can be compared.
Connect the surfaces
Browser, phone, voice assistant and the existing automations move onto the same core, one after the other. Once they all hang on it, the old reconciliation falls away. The rules are then tuned on real items rather than on paper.
The place where the commitments come together
Meetings produce commitments: PrivatTranscript records them in the minutes, PrivatActions carries them on as open items. The activity cockpit and the digital assistant read the same core instead of keeping lists of their own. And wherever a draft reply comes from an external language model, PrivatPrompt sits in front of it and masks whatever must not leave the house.
Target picture of all solutions →The summary as a PDF
Four lists and one board, the priority rules with follow-ups, the state core with its surfaces, data handling on your own infrastructure and the three-step introduction, compact for the decision paper.
PrivatActions
One tick that counts everywhere: board, priority rules, state core, surfaces and data handling on three pages.
How many lists of open items do you keep in parallel today?
In a first conversation we count the places where a tick is set in your organisation, and clarify which of them could become a single one. No obligation, on equal terms.
Get in touch → All solutions