Customer temperature: the metric your dashboard does not have

Ask an experienced account manager which of their accounts are at risk and they will tell you in about four seconds, with high accuracy, and be unable to explain how they know.

Ask the health score and it will tell you something different, slower, based mostly on login counts.

The gap between those two answers is the problem worth solving.

What health scores actually measure

Most health scores are built from what the system can count: logins, feature usage, ticket volume, time since last contact, NPS if you collect it.

These are not wrong. They are just heavily weighted towards what is easy to instrument, which correlates with what matters but is not the same thing. A customer can log in daily and be furious. A customer can go quiet for three weeks because everything is working, or because they have started evaluating your competitor, and the login count looks identical.

The deeper issue is that usage tells you about the users. Renewals are decided by the buyer, and the buyer is frequently not a user.

What the account manager is reading

When someone says an account feels cold, they are unconsciously aggregating things the dashboard cannot see:

• The sponsor stopped replying directly and started copying an assistant.
• The last three tickets were raised by someone junior instead of the usual contact.
• A question was asked about the exit clause.
• Nobody from their side came to the last two monthly calls.
• The tone in a ticket thread changed from collaborative to formal.

Every one of these is a real signal. Most of them are also recorded somewhere in your systems already — in the ticket queue, in the escalation history, in the meeting record. They just are not being read together, because they live in different places and nothing correlates them against the customer.

Temperature as a working definition

Treat it as a reading rather than a score. A score implies precision you do not have; a reading implies a direction, which is what you actually want.

Three inputs, all of which you likely already hold:

Responsiveness. How quickly the customer engages with you, compared with their own baseline. Absolute speed is meaningless — some customers were always slow. A customer who used to reply in a day and now takes five is the signal.

Friction. Open escalations, unresolved defects, tickets that have been reopened, anything that has taken longer than promised. Not volume — duration and recurrence.

Direction of contact. Are they coming to you with plans, or only with problems? An account that only generates tickets is in a different state from one that also asks about the roadmap.

None of these require a survey, and all three are visible the moment your support, delivery and customer records sit in one place.

The honest limits

Temperature is a prompt, not a verdict. Its job is to make an account manager look at an account this week rather than next quarter. It should never be presented as a prediction, and it should never be automated into an intervention — an automated "we noticed you've been quiet" email to a customer who is quiet because they are unhappy is worse than silence.

It will also be wrong regularly. That is acceptable if the cost of being wrong is one conversation.

Where PlaNath fits

PlaNath holds the customer, their projects and workplan, their defects, their support tickets and their escalations against a single record. That is the precondition for any honest reading of temperature: the signals are already in your organisation, scattered across systems that do not know about each other.

The claim is narrow and deliberate. PlaNath does not tell you which customers will churn. It makes sure the things your account manager already senses are visible to everyone else too, at the moment they are asked.

You answer for the relationship. PlaNath answers for the picture.