The same work, counted twice
A client asks for a fix on Monday, in an email. On Tuesday someone raises it as a ticket, because that is where engineering work lives. On Wednesday it comes up in a call and lands in the notes as an action item.
One piece of work. Three records. By Thursday two people are doing it, and a third is waiting for it, and nobody is sure which of the three is the real one.
Nobody is being careless
It is tempting to treat this as a discipline problem — if people were tidier, there would be one ticket. That is not what is happening.
Every tool in the stack is correct about its own job. The ticket tracker is the right place for engineering work. The chat message was the fastest way to flag something urgent. The meeting note is an accurate record of what was agreed in the room. Each system is the source of truth for itself, and none of them is wrong.
They are just not the source of truth for the work. That exists across all three, and nothing in the stack is responsible for the whole of it. The duplication is not a failure of the people using the tools. It is what happens when a commitment is larger than any one system that recorded it.
What Servanda does
A commitment is one task, regardless of how many tools raised it.
When the same work arrives from a ticket and from a chat message, it resolves to a single entry, tagged with each source and linked back to each origin. You can see that it came from both. You can jump to either. But there is one owner, one due date, and one state.
And re-syncing does not create a second copy. This sounds like an obvious property until you have used something that gets it wrong — a tool that rediscovers the same ticket every few minutes and quietly grows a list nobody trusts any more. A task list you have to mentally deduplicate while reading it is not doing its job.
What this risks, and it is not nothing
Deciding two records are the same thing is a judgement, and judgement can be wrong in both directions.
Miss a match and you get a duplicate: annoying, visible, easy to fix. Make a match that should not have been made and you get something worse — two real pieces of work collapsed into one, and one of them has now disappeared from the list. Nobody is chasing it, because as far as the system is concerned it is already being handled.
Those two failures are not symmetric, so we do not treat them as if they were. We would rather show you a duplicate than silently merge two commitments that only looked alike. Where a match is uncertain, it stays two tasks and you can merge them yourself.
The general principle: when a system is guessing, it should fail in the direction that a human will notice.
One task is only half of it
Collapsing three records into one task solves the counting problem and creates a new one. If the work came from a ticket, a chat thread and an email, where does the answer go?
Replying in Servanda publishes back to where the request came from — the comment lands on the ticket, the reply goes to the email thread, the response appears in the chat. You answer once, in one place, and the people who asked hear about it where they asked.
Without that, a unified task list just moves the problem. The work would be tidy, and the three people waiting would still be waiting.
What the list is for
A task list should describe reality, not the shape of your tooling. If one thing needs doing, it should appear once — no matter how many systems happened to witness someone agreeing to it.
That is the whole idea. Everything else is detail.