Scope, schedule, and close

Cut a deal to a number

The customer has a budget. deal scope says where the money is, one breakdown in full and every other one named in a line, so you can see whether the weight sits in the work, in a role, in a stream, or in recurring cost. Then take the group out and read the deal back.

estii deal scope nd_abc123
estii deal scope nd_abc123 --by role,stream --json
estii deal descope nd_abc123 ft_7 --dry-run
estii deal descope nd_abc123 ft_7 --yes
estii deal show nd_abc123
estii deal rescope nd_abc123 ft_7 --yes

Each group reports what it is worth and what the phase's current scope holds of it, so a group already partly out reads as partial. Descoping takes the line items under an item with it and clears any exclusion they held on their own, which is what makes rescope put back exactly what came out. Where a group id is in more than one phase, name the phase with --phase, or act on all of them at once with --phase all.

Read the delivery side

estii deal schedule nd_abc123

The dates each phase sits on, its duration, how many resources it calls for, and how each role and overhead is allocated across it. The dates are the computed ones, so a phase that starts after a gap or is pinned to its own date reports where it really is rather than where chaining the durations would put it.

See where capacity and revenue land

deal list says where each deal stands. pipeline says what all of them add up to over a window: demand in full-time equivalents, and revenue recognition from the milestones on each deal.

estii pipeline summary
estii pipeline capacity
estii pipeline capacity --group role
estii pipeline capacity --group deal --from 2026-03-02 --months 3
estii pipeline revenue --months 12 -o json

Every series carries three nested bands: confirmed is won work, forecast adds your open deals weighted by probability, and exposure adds them all at full weight. Each reports its own peak, the period the peak falls in, and its total, so a caller and the forecasts page cannot disagree about where the peak sits.

The window resolves rather than refusing. --from snaps back to that week's Monday, --months clamps to 3–12, and the period defaults to weekly at six months or under and monthly above. Every result states the window it actually covered, the rule it bucketed by, when the forecast was built, and whether a deal has changed since.

--deals, --roles, --tags and --status narrow the picture to what they name. There is no exclusion form of any of them.

Capacity here is demand. Estii holds no headcount, so a peak is a concentration of scheduled work rather than a shortfall against a roster.

Pipeline forecasting is a Business feature. On the free plan these commands refuse with the plan required and where to upgrade.

Move a deal

Once you know which deal drives a peak:

estii deal reschedule nd_abc123 +2w --dry-run
estii deal reschedule nd_abc123 +2w --yes
estii pipeline capacity --group deal

reschedule takes a signed offset (+2w, -1m, +10d) or an absolute YYYY-MM-DD date, and resolves either to a Monday. It is not deal set start=: a deal past draft is saved as a version before its dates change, and phases pinned to a fixed date move by the same offset. It reports the new start, whether a version was saved, and which phases moved. An archived or closed deal is refused; restore or redraft it first.

Check a deal before you send it up

estii deal audit nd_abc123
estii deal audit nd_abc123 --all --json

What the deal's own numbers imply, ranked by how likely each finding is to be asked about at approval: cost running ahead of billing and the day the gap peaks, a phase running longer than its work needs and the recurring cost sitting in that window, risk classified onto the thinnest-margin scope, a final payment large enough to fund a dispute. Each finding carries the figures it rests on and the part of the deal to open.

Most deals produce nothing, and that is the point rather than a failure: a review that always finds something is not worth reading by the fourth deal. A quiet deal says so and exits 0, as does one carrying too little to review.

The report always says how many checks passed; --all lists them with the value each outcome rests on. Seeing what passed is what makes what failed worth acting on. The JSON carries every check either way.

See what has moved since you last shared it

estii deal versions nd_abc123
estii deal audit nd_abc123 --since v_xyz789
estii deal audit nd_abc123@v_xyz789

--since reports the deal against a save point: what the price, margin and duration did, then the rules that explain them — a phase that arrived, work added inside the phases already there, the same work priced differently, a discount that moved, the dates sliding under a length that did not change. A move against an automatic snapshot says so, because that is the rate card arriving rather than anyone touching the deal.

<ref>@<version> is the other question: the deal as it stood at that save point, audited on its own terms. Asking both at once is refused rather than guessed at.

Nothing here is stored or scheduled. The findings are recomputed from the deal each time you ask, so they move when it moves, and the app's review panel answers with the same figures in the same order.

Move a deal through approval

estii deal request-approval nd_abc123 --to sam@acme.com --yes
estii deal approve nd_abc123 --probability 80% --yes
estii deal progress nd_abc123 --yes
estii deal close nd_abc123 won --reason "signed SOW" --yes

These are one-way. Re-running a step the deal has already taken is an error rather than a no-op, and amending a close means redraft then closing again. Approving and closing need the manager role. estii deal --help prints the legal transitions from every state.