The decision
One sentence. The call itself, written so it can be quoted in a Slack thread or a board deck without further translation.
The Decision Log—so decisions can survive the people who weren’t in the room.
Every Zynkex session creates a Decision Log. This is a running list, one entry for every binding call made in the session. Each entry is written so the reader three months out can understand the decision.
What is in each entry.
The rationale
Two short paragraphs. The reasoning that selected this call over the alternatives, written so a reader who was not in the session can reconstruct the argument.
Alternatives considered
Two to four, each one named and rejected with a one-line reason. The honesty that makes the surviving call defensible later.
Revisit trigger
The specific future condition that would justify re-opening the call. Without it, the Log is a graveyard. With it, it is a living instrument.
The reasoning that backs the Plan.
The Strategy Plan is what Zynkex hands you — the strategic posture, the framing, the recommendation. The Decision Log is the chapter that closes it: every binding call the session made, written with its reasoning attached so the Plan can be defended, revisited, and built on with full access to the original logic.
A Plan without its reasoning is hard to honour as the work continues. A new constraint shows up, an opportunity opens, a junior team member proposes a feature — and the team has to choose: trust the Plan, or improvise. The Log makes the first option possible. The original argument is there, in context, written for a reader who was not in the session.
A real Decision Log, three entries deep.
A short illustrative sample from the Pivot CRM Decision Log. The full Log runs to nine entries; the three shown here give a sense of the format and depth of each.
Decision Log
Illustrative excerpt — entries 01–03 of 09 shown below. Format and depth represent the full Log.
Every binding call made in the Pivot CRM session, recorded with its reasoning, the alternatives considered, and the future condition that would justify re-opening the call.
Entry 01 · Position the rebuild as a churn detector, not a friction scanner
Decision
Pivot 2.0 is sold to the customer-success buyer as the system that surfaces accounts about to leave, not as the system that catalogues friction across the product.
Rationale
The friction-scanner pitch is honest about what the tool does but reaches the buyer who already owns analytics. That buyer says no because friction data is downstream of what they already track. The churn-detector pitch reaches the buyer whose budget is allocated against retention numbers — a different procurement category with an existing line item. Same telemetry under the hood. Different room walks in.
This is positioning as a wedge into a budget the team can win, not a description of the technology. The friction scanner remains the engineering reality; the churn detector is how the company gets paid for it.
Alternatives considered
- Friction scanner across the entire app. Lands on the wrong buyer. Analytics teams already feel covered.
- Reliability monitor / uptime story. Crowded category dominated by Datadog. Wrong defensibility.
- Champion-only sales-led posture. Doubles the sales cycle and undersells the autonomy of the product.
Revisit trigger
If three or more closed-won deals come in describing the value as "we finally see what is breaking" rather than "we keep our biggest accounts," the wedge has shifted and the positioning should follow it.
Entry 02 · Cut the champion-only login from MVP
Decision
Pivot 2.0 will not ship the proposed role-restricted dashboard that limited write access to a designated champion in each account.
Rationale
The champion-login feature was added to mirror enterprise-CRM access patterns and to give procurement an obvious admin story. In practice it doubles onboarding effort and forces every customer to nominate someone for a role they did not ask for. The smaller accounts the early sales motion is built for do not have a designated champion; the larger ones already have SSO and want role mapping through that, not through a Pivot-native admin layer.
Shipping without it lets the team validate the retention insight loop without spending another sprint on auth plumbing. If a Fortune-1000 buyer asks for it during a procurement review, that is the signal to build the SSO-mapped version of it, not the standalone version proposed today.
Alternatives considered
- Build champion login as proposed. Doubles onboarding cost, blocks the retention loop validation.
- Build a lighter "one designated user" version. Still demands a nomination step that small teams resist.
Revisit trigger
A Fortune-1000 procurement review that explicitly requires role-mapped write access, OR three or more deals lost on this objection inside one quarter.
Entry 03 · Ticket volume is not a quality signal
Decision
Stop tracking inbound support ticket volume as a primary success metric. The Strategy Plan measures retention and account expansion. Ticket volume becomes a diagnostic, not a target.
Rationale
Ticket volume is the metric the team has cleanest visibility into, which is exactly why it gets used. But it is the wrong proxy: a falling ticket count can mean the product got better, OR that frustrated users gave up and stopped writing in. Optimising against it would push the team toward decisions that hide problems rather than fix them.
The Strategy Plan replaces it with a paired metric — gross retention rate by cohort + net expansion in the same cohort — both of which require frustrated users to either come back or churn. The pair makes "users stopped writing in" visible as the bad outcome it actually is.
Alternatives considered
- Keep ticket volume as the primary KPI. Survivor-biased. Optimising against it incentivises hiding problems.
- Replace with CSAT score. Same survivor bias. Frustrated leavers do not fill out the form.
- Replace with NPS. Same bias plus a longer feedback loop. Not actionable inside a quarter.
Revisit trigger
If gross retention and net expansion start moving in opposite directions for three consecutive cohorts, the pair is no longer telling a coherent story and the diagnostic set needs a third instrument.
What the Log is not.
Three things look like a Decision Log from a distance. None of them do the same work.
| Artifact | What it captures | What it cannot do |
|---|---|---|
| A meeting recap or chat transcript | What was said, in the order it was said. | Distinguish a binding decision from a passing suggestion. Three months out the reader cannot tell which lines mattered. |
| An AI summary of a conversation | The conversation, shorter. | Reconstruct the argument. The rejected options and the reasoning that selected the winner do not survive a summarisation pass. |
| A roadmap or decision-tracker doc | The decisions, in a list. | Tell the team when a settled call has become unsettled. No revisit trigger, no living instrument. |
| A Zynkex Decision Log | Decision, rationale, rejected alternatives, revisit trigger — for every binding call. | Defended in three months without the original session being in the room. |