Business
Personalization is an operations task, not a campaign
Personalization has to deliver a correct, individual result every time the customer turns up, not once per send. That takes current data, a fallback, a named owner and one measure.
Personalization is an operations task because it has to deliver a correct, individual result every time the customer turns up, not once per send. It needs current data, a fallback for when the data is missing, a named owner and one measure. Miss any of the four and the personalization is a campaign with several variants.
The distinction is worth holding onto because the two things fail in completely different ways, and because it is the most common way a digitization project ends up being called an automation project.
What separates a campaign from an operations task?
A campaign runs for a bounded period against a list. An operations task runs every time an event occurs, for years, without anyone deciding it should run that day.
| Campaign | Operations task | |
|---|---|---|
| When it runs | For a bounded period, decided by a person | Every time the customer turns up |
| What fails | One send goes badly | Every single customer gets the wrong result until somebody notices |
| Who owns it | The project, until it ends | Somebody named, permanently |
| How it is measured | Open rate and clicks, once | Share of requests that got the right individual answer |
| When data is missing | The send is postponed | The system needs an answer ready in under a second |
The last row decides whether the personalization holds up. A campaign can wait for data. An operations task cannot.
What does it cost to deliver personalization every night?
It costs a fallback for every field you personalize on, and an owner who answers when the fallback kicks in. Apps AS has built this itself, and the clearest example in our own archive is Goodnight AI.
Goodnight AI generated a new chapter of a bedtime story every night, adapted to the individual child. Parents picked the main character, the topic and the visual style, and could change the story as it went. ChatGPT wrote the text, Stable Diffusion made the illustrations, and the whole thing ran on AppCloud, our own low-code platform.
The personalization there was no campaign with variants. It was a delivery with a deadline every single evening, for every single child. A child who did not get their chapter at seven o'clock did not get a worse version. The child got nothing, and went to bed without the story.
Goodnight AI is no longer in operation. Why the product was closed is not recorded on the case page, and is not guessed at here.
What happens when the data is missing?
This is where personalization as an operations task is actually tested, and it is the part most teams skip in planning.
Write down three things for every field you personalize on:
- What the system says when the field is empty. Not an empty string, and not somebody else's first name. A wording that is correct without the detail.
- How old a data point may be before it counts as empty. An address from last year is not current data. Without a limit, the system uses it anyway.
- Who gets told when the fallback fires more often than a threshold you have set. Without that third point you will never notice that the personalization has stopped working, because it keeps delivering something.
The third point is what separates operations from luck.
A personalization system falling back to the default text for ninety percent of customers looks perfectly healthy in every piece of operational monitoring.
Who owns the personalization after launch?
Personalization needs a named owner because the rules rot faster than the code. A segment stops existing, a category is renamed, an integration starts returning empty fields after a vendor upgrade. None of those raise an error.
Ownership belongs with whoever owns the process, not with whoever built the system. In Munin, our own customer platform, it is expressed as a setting: you decide which workflows run unattended, which escalate, and which wait for approval. That setting is no technical detail. It is the name of whoever is accountable when the personalization gets it wrong.
What to measure
Measure the share of requests that got a correct individual answer, and the share that fell back to the default. Two numbers, same denominator.
Open rate and clicks measure the campaign. They say nothing about whether the personalization worked for customer number fourteen thousand last night. Which tasks are worth handing to a system at all is worked through in How Will Agentic AI Improve My Business?, and what it costs to test this on products we own ourselves is covered in What building our own products teaches us.
Write the fallback before you write the rule
Do you have personalization heading into production? Write down what the system says when the data field is empty, for every field you personalize on, and send the list to hello@apps.no. We will tell you which of those fields we would drop from the personalization entirely.
About this article. Written by Kjell Rune Monsø, partner at Apps. Anchor article for the pillar From digitization to automation. The details about Goodnight AI, AppCloud and Munin come from Apps AS' own case pages, read on 22 September 2026. Why Goodnight AI and AppCloud were closed is not documented on those pages, and is not guessed at here. The article uses no customer figures.
FAQ
- How many fields should we personalize on to begin with?
- One, and preferably the one that changes what the customer actually does. Every field you add is another fallback, another data source that can go stale and another way to be wrong. Most teams personalizing on six fields could drop five without anyone noticing, and would then have a system they could actually operate.
- Can we personalize without collecting more personal data?
- Yes, and that is often the better route. Behavior in your own service, what the customer just looked at, where they are in a flow, and what happened last time are data you already hold and that are current by definition. Purchased segment data is the opposite: older, less precise and more expensive to defend.
- How often should the rules be reviewed?
- On a fixed schedule rather than as needed, because rules do not announce when they stop being true. A review every six months against real numbers is enough for most teams: how often each rule matched, how often the fallback fired, and whether the segments still exist. Rules that have matched nobody in six months get deleted.
- What do we do if the personalization makes the experience worse?
- Turn it off for that field and keep the measurement running. A default everyone gets beats an individual message that is wrong, because wrong personalization signals that you thought you knew something about the customer and were mistaken. That is a more expensive error than not personalizing at all.
- Do we need an agent to run personalization?
- No. Most useful personalization is rules plus current data, and rules are cheaper to operate and easier to explain than a model. An agent earns its place when the content genuinely has to be generated per customer rather than picked from variants you wrote in advance.
