Since you crushed many of our last ones, here is a updated list from our estimators:
1️⃣ Project Organization (Highest Prirorty)
Today: one project = one takeoff.
Real life (negotiated work): one project → many takeoffs across design stages.
Need ability to house multiple takeoffs inside a single project and organize by design stage / progress package.
2️⃣ Breakouts after takeoff is completed
Allow creating/editing breakouts without duplicating takeoff items.
3️⃣ SSO
Getting into zzTakeoff needs to be easy and frictionless.
4️⃣ Navigation inside zzTakeoff (Auto-hyperlinks)
Once hyperlinks are in place, I should be able to navigate drawings and perform takeoff entirely inside zzTakeoff with no second tool.
5️⃣ “Gray folders” in drawing sets on left pane.
Auto-sort drawings by discipline (Architectural, Structural, Civil, etc.)
Also add a custom sort (example Building A, B, C…).
Appreciate how fast you’re moving.
Great list Kyle! I like all of your items above. We are looking for the same thing as well.
COMMENTS ON THE ABOVE 5 POINT (ALL GOOD)
#1 Allowing one project, many versions of the takeoff across design stages - Getting this nailed early would really set zz apart & demonstrate alignment w/ the goals of industry based on real world workflows we struggle with. I'm going to make a couple comments on this one because I have seen a few of the "large shops" make fundamental blunders on their architecture in this regard and it seems they may be too far down the line to do anything about it.
There should always be a current base scenario (which is the current scope / QTO based on the current documents) but it would be great to be able to duplicate any version (past or present) to correct errors / make updates, run alternate scenario's, etc.
*So the 2 subtle topics on this one I see:
1) Versions based on design stage / progress package (minimum)
2) Scenarios
-IMO, the GOAT software approach would be 1 project / 1 set of documents with the ability to have a live takeoff history (not just dead snapshots of the past) by version - design stage / progress package & scenario. It seems, one of the largest issues I have come across with the design of some takeoff tools is they fail to contemplate that the design process is progressive (as per Kyles comments) but not always linear:
-Some time design goes down a path and then backs up (it may get to 80%CD and then have to go back to 50CD% because things change quickly - market, owner requirements, etc).
-Some times there are 3 options on the table, we progress 1 (2 or 3), get to a point, reverse, and go back to a previous or new option.
-Some times parts of the design pull ahead of other parts. We have phased early tender packages our overall design development might be 65%, but the structure might pull head to 95% IFT so we can tendering forming for early cost certainty. After which, the remaining design catches up through progress design updates.
>The current workaround approach in "most" software is to duplicate projects & manage / archive the duplicates. While this does work (and it should be always an option), it gets us back into the OST / Excel sheet mentality where we drift away from managing one central source of truth. Creating duplicate projects means we have to feed the same document in the different projects causing duplicate effort, possible document governance issues, and takeoff version sprawl.
>It would be mush preferred if the software design would clean all of this up & be structured in such a way to HELP us keep everything organized rather than force work arounds that make us more disorganized.
COMMENTS TO OTHER PRIORITIES OF OURS
i. BASICE TAKEOFF
A) Repeating floor handling (reduce takeoff error risk)
Our current workaround applies a custom property (“number of repeating floors”) at the individual takeoff level. This is workable but introduces avoidable human-error risk.
Desired improvement:
Goal: move the multiplier upstream in the hierarchy to improve consistency and reduce QA burden.
ii. RELATED TO ENTERPRISE SET UP AND DOCUMENT GOVERNANCE
B) Role-based permissioning (reduce manual project management)
We currently operate across 9 offices and want to minimize manual user adds/removals at the project level.
Target state:
Goal:
Office/role inheritance should drive baseline visibility, with project-level assignment only where truly required. We want to avoid heavy ongoing manual permission maintenance.
C) Scalable project organization and lifecycle management
At our volume, project discoverability and lifecycle hygiene are critical.
We are looking for robust native support for:
A BuildingConnected-style experience is a useful benchmark, but we are open to zzTakeoff best practices.
Awesome feature list to your both. These are under review as features now, feel free to detail how you think they should work.
Project organization i would like would be by bid date but also be able to either put a priority 1,2, or 3 or a star to projects we want to bid verses projects we use to fill time just to keep bids going out