Nobody logs in to your dashboard

Every workflow we have built ends on the same sentence wearing different clothes. An alert is not the deliverable. The draft has to land in the tool they already open. The job is not done while somebody still has to read the output and decide what to do about it.

This is that step, finally, on its own. It is the least interesting thing in the product. It demos badly, it photographs worse, and it is the one piece of work that determines whether everything in front of it was worth building at all.

The job, as it exists today

A salesperson's world has a system of record in it, and it is not ours.

It is whatever the company bought — the place where accounts live, where the pipeline is reviewed on a Monday, where a deal has to exist before finance believes in it. Every serious vendor has one and it is the spine of how the company runs.

Now put a second system next to it, full of better information. What happens is not that people use both. What happens is that somebody, in the first fortnight, copies a few things across by hand, feels the friction, and stops. After that the good information sits in one system and the decisions get made in the other.

That is the actual failure mode of every intelligence product I have ever seen in this sector, and it has nothing to do with the quality of the intelligence. The intelligence was fine. It was in the wrong window.

Why it is harder than plumbing

The system of record belongs to somebody else. Not to the rep, and usually not to the person who bought our product. It belongs to whoever administers it — the fields are governed, the objects have owners, and there is a reason for every piece of apparent bureaucracy in there. Writing into that is a permissions question and a political one before it is ever a technical one.

A wrong write is far worse than no write. This is the part people underestimate. A stale dashboard is ignored, which is a cheap failure. A wrong field in the system of record is believed — it gets quoted in a pipeline review, it drives a forecast, and nobody re-checks it, because the whole point of a system of record is that you do not have to. Putting a machine-generated claim in there without provenance is how you poison the well the company drinks from.

Duplicates are a commercial problem, not a hygiene one. In a real sales organization the account record decides who is allowed to sell to whom. Create a second record for a utility that already exists under a slightly different name and you have not made a mess, you have started an argument between two reps about whose account it is. Any system writing into that has to resolve against what is already there before it writes anything at all.

And no two of these systems are configured alike. Not the objects, not the required fields, not the stages, not the naming. The mapping is per-customer work and it does not get much easier the second time.

What the workflow does

It writes the objects the team already uses. An account, a contact, a task, a note, an opportunity. Not a custom object with our name on it that appears in a tab nobody clicks — that is the same failure as the second window, wearing a badge.

Every written row carries its source. The same rule as everywhere else in the product, and it matters most here, because this is the one place where a claim gets stored rather than displayed. A task that says a rehabilitation is coming carries the link to the meeting where it was said. Anyone can open it. If nobody ever does, the link cost nothing; the first time somebody does, it is the difference between a system people trust and one they quietly stop believing.

It resolves before it writes. Match against the existing record, and where there is genuine ambiguity, ask rather than guess. Never overwrite something a human typed. A person's edit is a fact about what they know that we do not; it is not stale data to be corrected.

And it distinguishes what it does alone from what it proposes. There is a ladder, and it is a real field in the system rather than a philosophy: some work is done manually by a person, some is drafted and held for review, and some runs automatically without anybody watching.

What is interesting is which work sits where — and it is the opposite of what gets demonstrated at conferences. The things that run unattended are the boring ones. Logging that an award was made. Attaching a document to the account it belongs to. Updating a contract date. The judgment calls — the outbound, the bid decision, anything that reaches a customer — stay gated behind a person, and that is not a temporary state of caution on the way to full automation. It is where the line goes.

The bookkeeping is also, not coincidentally, the work nobody was ever going to do. That is why automating it is worth more than automating the exciting part.

What it looks like in practice

An illustrative example — not a customer, and not a real utility.

A monitoring run notices that a utility has awarded a rehabilitation contract for a set of pump stations, and that the award names an engineering firm your team has met twice.

The version of this that does not work: a notification. Somebody reads it on a phone, thinks that is useful, and does nothing, because acting on it means opening another system and typing.

The version that works is that by the time anyone reads anything, the account record already shows the award, dated, with the source document attached. A task sits on the right person's list naming the engineering firm as the route in. The contact record for that firm has been linked. None of it required a decision, so none of it waited for one.

The rep's first knowledge of this is not an alert. It is a task in the place they were going to look anyway, with the evidence already attached to it.

The measure of this is where the work happens

We have a dashboard. It is good. A great deal of work went into it, and the screenshots on this site are mostly of it. It is not, however, where the selling happens.

If this workflow is doing its job, the things a rep needs on a Tuesday — the signal, the source it came from, the draft, the task with a date on it — are already waiting in the system they open anyway. The dashboard becomes the place you go to look into something properly, rather than the place you go to find out what changed.

That distinction is the whole of the argument. If the agent is the user, the output has to arrive where the work already is. Output that waits for somebody to come and collect it is output with a human step still bolted to the front of it.

A product that has to be visited is a tool. We said we were not building a tool.

What it cannot do

It cannot rescue a system of record nobody maintains.

Write-back multiplies whatever is already there. Into a well-kept system it adds timely, sourced, useful rows. Into an abandoned one — stale accounts, dead contacts, opportunities that closed two years ago and were never marked — it adds correct information to a place nobody trusts, which does not fix the trust and does make the pile bigger. Faster, and at volume.

So the honest conversation with a vendor whose system of record has been left to rot is that this workflow is not their first problem, and buying it now would be buying a nine-workflow pipeline that terminates in a swamp. It is not a fun conversation to have, and it is cheaper than the alternative, which is being blamed in six months for a mess that was there before we arrived.

And it is not a first step toward becoming the system of record.

Writing into somebody's CRM is one move away from offering to replace it, and that is a move we are not making — not now and not later. The refusal in the contacts piece stands. The company already owns a system of record, it works, and the entire reason our information is worth anything is that it arrives somewhere they already trust, rather than asking them to trust somewhere new.

And being bought is not the same as being allowed in. Write access is granted by somebody who did not choose us, has their own view of what belongs in their system, and is entirely right to have one. Sometimes the answer is read-only, or a sandbox, or a queue that a person approves. Every one of those is a worse product than full write-back and a better outcome than losing the customer's administrator, who will be there long after the pilot.

Related

• The agent is the user — the argument this step completes: the output has to arrive where the work already is.
• Nobody reads the minutes — where the signals that become these actions come from.