Loading
Project tools show a board because a board is easy to draw. What determines whether a project makes money is the chain either side of it — what was sold, and what gets billed.
These three follow that chain through the two boundaries where delivery businesses lose margin.
Software fails at boundaries. A feature list cannot show you one; a journey has to.
Project to invoice, scope change to price and plan to staffing are the three places a delivery business leaks: unbilled work, absorbed changes, and dates promised against people who were never available.
All three are joins rather than features. Billing reads delivery, pricing reads the contract, staffing reads leave — none of which a standalone project tool can do, because none of that data is in it.
Scope change is the one most teams know they handle badly. The fix is not a workflow; it is pricing the change before it is built, which is a conversation the record makes possible.
Not because anyone was careless — because the record stopped at the edge of the tool, and somebody had to carry it across by hand.
Who runs Loop →If you bill for time, read project to invoice. It is the chain with the most steps and the most re-keying.
If your margin is unpredictable rather than low, read scope change to price. Absorbed work is usually the explanation.
Only the ones that start at a sale. A project opened by hand runs the rest of the chain identically; the sold scope simply arrives typed rather than derived.
About a week on one live project, from sold scope through logged time to a raised invoice.
The unit changes and the boundaries do not. Sprints read the same tasks the plan does, so time and margin behave the same way.
Between the plan and the invoice. Delivered work is summarised by hand, and the summary is what finance bills from.
Yes. Client visibility is a permission on the same records, not a second portal fed by a copy.
We will run it end to end on your own numbers in half an hour, and tell you honestly which parts Treepie does not improve.