Nobody logs in to your dashboard
Signals, contacts, contract cycles, bids, profiles, drafts: none of it counts until it lands in the system the sales team already works in. This is that step. It is the least interesting thing we build, and it decides whether anything upstream of it was worth building.
Every workflow we have built ends on the same point. 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 piece is about that step on its own. It is the least interesting thing in the product and it demos badly. I believe it is also the step that decides whether everything before it was worth building.
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 the company runs on it.
Now put a second system next to it, full of better information. People do not use both. In the first couple of weeks somebody copies a few things across by hand, finds it tedious, and stops. After that the good information sits in one system and the decisions get made in the other.
That is how every intelligence product I have seen in this sector has failed, and the quality of the intelligence had little to do with it. The information was fine. It was in the wrong window.
Why it is harder than plumbing
The system of record belongs to somebody else. It does not belong 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. So writing into it is a permissions question and a political one before it is a technical one.
A wrong write is far worse than no write. People underestimate this. A stale dashboard gets ignored, which is a cheap failure. A wrong field in the system of record gets believed. It is quoted in a pipeline review, it drives a forecast, and nobody re-checks it, because the point of a system of record is that you do not have to. If you put a machine-generated claim in there without its source, the whole company ends up relying on something nobody can check.
Duplicates are a commercial problem. 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 started an argument between two reps about whose account it is. So anything writing into that system has to match against what is already there before it writes anything at all.
And no two of these systems are configured alike. The objects, the required fields, the stages and the naming all differ. The mapping is per-customer work, and it does not get much easier the second time.
What the workflow does
It comes down to four rules.
It writes the objects the team already uses: an account, a contact, a task, a note, an opportunity. We do not add a custom object with our name on it in a tab nobody clicks, because that is the same second-window problem inside their own system.
Every written row carries its source. That is the rule everywhere else in the product too, and it matters most here, because this is 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, and anyone can open it. If nobody ever does, the link cost nothing. The first time somebody does, it is what lets them keep trusting the system.
It resolves before it writes. It matches against the existing record, and where there is real ambiguity it asks rather than guesses. Never overwrite something a human typed. A person's edit is a fact about what they know that we do not, and we treat it that way rather than as stale data to correct.
It separates what it does alone from what it proposes. There is a ladder, and it is a real field in the system: some work is done manually by a person, some is drafted and held for review, and some runs automatically without anybody watching.
Which work sits where is the opposite of what gets shown 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. That is where the line goes for good, not a cautious stage on the way to full automation.
The bookkeeping is also the work nobody was ever going to do by hand, which is why automating it is worth more than automating the parts that demo well.
So that is the workflow: write into the objects they already use, source every row, match before writing, and keep the judgment calls with a person.
Your CRM / Task / written back by AquaIntel
What it looks like in practice
This is an illustrative example. It is 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.
If that arrives as 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.
With write-back, 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 first hears about it as a task in the place they were going to look anyway, with the evidence attached.
The measure of this is where the work happens
We have a dashboard. It is good, a lot of work went into it, and the screenshots on this site are mostly of it. But the selling does not happen there.
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 is the argument of this piece. 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 still has a human step in front of it. We said we were not building a tool people have to visit, and this workflow is where that gets tested.
What it cannot do
It cannot rescue a system of record nobody maintains. Write-back adds to 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. That does not fix the trust, and it makes the pile bigger, faster.
So if a vendor's system of record has been left to rot, the right conversation is that this workflow is not their first problem, and buying it now would mean feeding nine workflows into a system nobody uses. It is not a fun conversation. It is cheaper than 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 we are not making that move, now or later. The refusal in the contacts piece stands. The company already owns a system of record and it works. Our information is worth something because 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 right to have one. Sometimes the answer is read-only, or a sandbox, or a queue that a person approves. Each of those is a weaker product than full write-back, and we take it anyway, because the customer's administrator 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.