Pipeline
Fourteen deals, and a trail for every stage they moved through.
This page is not a dashboard — StratOps does not have one. It is an explanation of what a deal actually is inside the record, written against the one pipeline that exists: Jake's own.
Fourteen deals, and every one of them his.
There is no customer list behind this page. StratOps has one user, so the pipeline it tracks is one operator's own work — not a sample account, not a demo tenant seeded to look busy.
14
Deals on record
0
Forecast figures on this page
No probability-weighted total, no projected close date, no win-rate percentage. Those are numbers a CRM usually invents by multiplying a guess by a guess. This one does not print them because nothing computes them.
You mention the call. The deal moves itself.
A deal does not start as a form. It starts as a sentence — you tell Claude who you talked to and what they said, and if that call touches a deal already in the record, the deal moves to its new stage instead of a second one getting created next to it. If it is the first mention, a deal gets opened, tied to the contact and the meeting it came from.
Nothing about the stage advances on its own. A deal does not creep from "proposal" to "won" because a date passed or a task closed. It moves because you said it moved, and only then.
- StageSet from what you said, never inferred from silence.
- ValueStored as whole cents, not a float — so a total can't drift by a fraction of a cent across fourteen rows.
- TrailEvery stage change is logged as its own entry, so "how long has this sat in proposal" stays an answerable question.
- ContactLinked to the person, matched rather than retyped.
From the build notes, not a claim about this page
Moving a deal and logging that it moved are two facts, and early on this system wrote them as two separate database calls. That is exactly the kind of thing that can half-succeed: the stage moves, the trail entry doesn't, and now the record disagrees with itself in a way nothing surfaces. It was found, and fixed, by making both writes happen as one unit — either the deal moves and the trail records it, or neither happens. The same defect was found twice more in other tables before the rule became absolute rather than case-by-case.
Nothing here is watching the pipeline for you.
Nothing runs on a schedule. A deal that has sat in one stage for three months does not get flagged unless you ask about it — there is no background job checking, because none exists. If you want to know what moved this week, that is a question you ask in the same conversation, and the answer is worked out at the moment you ask it, not read off a cached number that could be stale.
There is also no lost-deal graveyard with a reason field StratOps invented for you. If a deal is marked lost, the reason it's lost is whatever you said, or nothing, if you didn't say anything.
Ask about a deal the way you'd ask a person.
Not this page — the conversation. This page exists so you know what's behind the answer before you ask the question.