Own project · 2026
A system that gathers the contacts arriving through several channels, holds the status of each, and sends a weekly summary of those who have been waiting too long for a reply.
Requests arrive through a web form, a shared inbox, a messaging app and the phone, and the status of each ends up distributed across people's heads and notebooks. Nothing is lost dramatically. Things are lost quietly, one at a time, and the organisation finds out when somebody stops replying.
Three service tiers instead of one. The jump from "a notebook" to "a CRM" is what makes most small implementations get abandoned: the tool is correct and the adoption is not. The tier with AI-generated summaries is optional and does not condition the rest, so the system is useful on day one without anybody having to trust a model.
A generated summary omitting or distorting a commitment made to a person. A summary that replaces the source is a quiet way to lose the exact words somebody was promised. So the summary always links back to the original message rather than standing in for it, and it is marked as generated. Data is hosted in the EU.
Data minimisation and purpose limitation: contact data is kept for handling the contact, not for building a profile. Transparency about which parts of the view are generated automatically.
What it taught me. The value was not the model but the information architecture. Ordering what already exists solves more than adding intelligence on top of it — and when the ordering is right, the amount of intelligence you need afterwards drops sharply.
This is a queue with ageing, status and an escalation signal: structurally the same object as a support backlog. The lesson scales in both directions — the summary that links to its source is exactly the control a support team needs before letting a model write anything a person will act on.