Aug 5, 2026 · 4 min read · GameMantra Team
Live-ops handoff notes that actually transfer knowledge
When the person running your events leaves, the calendar survives and the reasoning does not. The reasoning is the part that was doing the work.
Live operations accumulates knowledge that nobody writes down, because it does not feel like knowledge while you have it. Which events underperform in which weeks. Why that reward was reduced last year. Which segment complains about which mechanic. Why the pass renews on a Thursday.
When the person holding that leaves, the calendar and the configs remain. The reasons do not, and their successor spends a year rediscovering them by making the same mistakes.
What survives a handoff on its own
Artefacts survive. The event calendar, the config values, the templates, the dashboards. Anyone can read them.
What they do not carry is why. A config value is a number; it does not say that it was set after a bad week in a specific market. An event on the calendar does not say that it was moved off Fridays because it collided with something. A reward tier does not say it was reduced because the previous level was destabilising the economy.
The result is a specific and predictable failure: the successor optimises. They see an odd value, tidy it, and reintroduce the problem it was solving. They see a gap in the calendar, fill it, and rediscover the collision. Every one of these looks like an improvement when they make it.
This is not a documentation problem in general. It is specifically a problem about decisions that look arbitrary and were not.
The three things worth writing
The first is a list of the deliberate oddities. Every value or scheduling choice that would look wrong to a newcomer, with one sentence about why it is that way. This is short — most games have fewer than twenty — and it prevents almost the entire class of well-intentioned regression.
The second is the calendar's constraints rather than its contents. Not what runs when, but what cannot run when and why. This weekend is avoided because of a platform event. These two never overlap. This one has to end before that one starts. Those rules are what someone needs to schedule competently, and they are usually held entirely in one person's head.
The third is what has been tried and did not work. This is the most valuable and the least written, because failures do not get documented anywhere. A successor with no record of failed attempts will try several of them, and each attempt costs a cycle. A page of "we tried this, here is what happened" saves months.
Writing it while it is still true
The reason handoff documents are bad is that they are written at handoff, when the person is leaving, distracted, and reconstructing reasoning from memory.
The version that works is written continuously in small pieces. When a decision is made that would look odd later, one line goes in the file. When something is tried and fails, one line. This costs a minute at the moment when the reasoning is fresh and free, and produces a document that is accurate rather than reconstructed.
The trigger worth using is the feeling of "we should remember this". That feeling reliably occurs at the moment something non-obvious is decided, and it reliably does not survive the week.
A single file, appended to, in rough chronological order, is enough. Structure can come later if anyone needs it. What matters is that the reasoning exists in writing at all, and organising it is a smaller job than recovering it.
See how we keep operational decisions traceable →
The handoff conversation that is worth having
Even with good notes, there is a category of knowledge that only transfers by talking: judgement about the player base.
How the community reacts to things. Which changes generate noise and which are absorbed quietly. What the tone of communication should be. Whether a particular kind of complaint is a real signal or the usual background.
That does not compress into a document well, and it is what makes the difference between someone who can run the calendar and someone who can operate the game. The transfer happens through overlap — running events together for a period, with the outgoing person explaining their reasoning in real time on live decisions.
Where that overlap is not possible, the substitute is worse but not nothing: a recorded walkthrough of the last several months of decisions, with the reasoning spoken aloud. It takes an hour and it captures the judgement layer that written notes systematically miss, because written notes record what was decided and not the weighing that produced it.
The underlying point is that live operations is largely a body of accumulated judgement about one specific game and its players. Treating it as a set of configs that anyone can pick up is how studios lose a year of learning every time someone changes role.
Share this post
See what this looks like for your game.
SDK for Unity and Unreal. A 20-minute call to walk you through it.