Collecting Input: Plan Sets & Plan Versioning

My thoughts were in another post located in this thread:

Page sorting within jobs - PLEEEZ help! | zzTakeoff

If we get plan versioning right, this becomes a massive quality-of-life upgrade for everyone in the industry because no tool does this even remotely well (except Ediphi). But there are really two completely different worlds we have to solve for.

1. The GC world (my world):

We deal with 30%, 60%, 90% milestone sets where the drawings don’t change incrementally — they evolve dramatically. New sheets appear, sheets disappear, details move, scales shift. In that environment, slip-sheeting and overlays almost break down because the changes are too big.

So GCs need a workflow that treats these major milestones as separate buckets, not incremental revisions. My ideal solution would be to tag each set with a "WBS" and we could filter on and off the sets in the same project and also tie the layers to these sets. When searching the plan sets, the search feature would not look at hidden sheets.

2. The Trade Partner world:

Most subs are working off near-final sets where the design is mostly locked and changes are incremental. That’s where slip-sheeting, overlays, and page-to-page comparisons really shine. Kory's outline fits this perfectly.

Both worlds matter — and we should support both.

The GC version is arguably easier: milestone buckets with clean separation.

The trade partner version needs tight sheet-level revision tracking.

I had a user ask me last week, “Kyle, what’s the best workflow now that I have new drawings?”

Right now, we don’t have a good answer.

If we solve this — for both milestones and incremental updates — it’s a huge win across the board.

From the estimating perspective and my experience as a subcontractor/GC varies slightly.

1. As a subcontractor I've traditionally rec'd plans from planrooms/GC's and for the most part they are finalized and have derived from an ITB from RFC/IFC set and I only anticipate a few addenda/ASI's to change the original set but it's sometimes enough to essentially rework the entire estimate again instead of just tweaking...
2. As a GC the phase of drawings from inhouse or consulted design professionals varies from schematic to IFC SETS and that road is always a roller coaster and never really repeats... What I can say is there a phase set no matter what.
3. The next part of that is the possibilities of addenda, emailed correspondence, subcontractor/trade drawings, RFI responses, or who knows...
4. These "slip sheets" can go by many names beyond the "sheet # & sheet name" such as SKA, SKS, AKE, ASI, etc... Sometimes more frustrating and confusing than just a simple revised or new drawing and require multiple delta cloud identifications 🔥🔥🔥 (rant over)
5. Within this next level of construction documents that may or may not occur there can be 2 levels IMO (I'm sure there is something that is an exception, but in my mind it's as simple as)

• Updated/revised drawing sheets (have already been released with a previous CD phase set)
• This is the more more trickier because identifying the changes that took place are always the task (which has already been made tremendously easier with zzTakeoff's "Overlay" & "Comparative" tools)
• Once the changes have been identified, the next challenge is capturing the scope/QTO's previously captured and what the updated drawing sheets either add/subtract from (this usually requires substantiating to an owner/design team)
• Within this task is being able to build off of the QTO/estimate/scope/template/etc previously used
• New drawing sheets (have not been previously released)
• A new sheet is always easier to look at and perform QTO's/estimate but the task is figuring out how the original scope is now changed/affected by new sheet (this can be easy or a brain drain and just lead to more questions (RFI's) from my experience)
• The phase/stage of construction (Preconstruction, Bidding, Construction) also complicates with more construction language/forms/processes/strategies

I say all this to say I look at sets differently now that I've taken some time on both sides. And the responsible GC with strong resources/management/relationships definitely goes through it heavily.

I've tried 2 different techniques with zzTakeoff in trying to deal with these scenarios (from a GC perspective). Also, I'll say that I was only interested in QTO's/scope and not estimating within zzTakeoff when I tried these two techniques.

• Just created new folders within the same project/estimate and just put all plans (whether changed or unchanged by the design team) in those folders.
• At that time I chose to use a separate construction drawing/document management software tool to flag if and what had changed with each sheet or if it was new to the set which alerted me to focus on those changes within zzTakeoff

• Use the "Layers" tool, which I think was helpful in the approach but I may have not maintained focus to get all the way through

I will say I much more prefer the role of subcontractor for a plan set revision because my focus is only on one trade and the risk is minimal because I'm most likely already under contract and I'm not trying to WIN the project! And it's usually just a matter of a C/O and modifying/adding/deleting QTO's/estimate and writing up C/O or COP

If I could impart any wisdom in the development it would be to make sure every sheet in the project is associated with (and yes, I'm still plugging for labels/metadata/tags/etc, and again I would urge the freedom to create these names on the fly or at the project level as they're not always going to be per the "typical" rules):

• SETS - Construction set that the sheet originated from or is currently on or has been a part of

• REV - What revision is this sheet? I would also notate date, but not as important

• CD TYPE - This one is a little more difficult but I feel is relevant since I've seen an addenda 1,2,3... in precon 60% drawing SET and then an addenda 1 in IFC drawing SET on the same project (hence, the fluid or dynamic labels and giving every construction sheet/document a name and then some)

And now that I've had a chance to finish my thoughts and come back to this post everything @Kyle said (amazing that we essentially said the same things)! Clearly, we've both had very similar exposure to the industry

Looking forward to the next iterations the development team is cooking up!

And now that I've done a bit more research and reading up on posts previous to my exposure with zzTakeoff this post by @john and follow-up comm's is also dead on and it looks like quite a bit of groundwork was thought through!

Great follow-up @Sam - not sure if I'd refer to tab as "Blueprint" but Drawings / Sheets / Documents maybe??? Or as I saw it later in the post "Plans"

But yes, landing on this page should be the first step and the entire project lifecycle reference for ongoing organizing no matter the course of the QTO or estimate - this is the backbone/foundation which all the rest lies on (don't get this right in precon or production it's a fail every time)

As expressed, I really hope for the days when development team has a chance to revisit and polish up markup/organizing/annotation tools - this would essentially reduce most estimators/precon managers that I know from having to rely on 2 software to get through the initial review & QTO stage.

I also do not see the value in side-by-side (my eyes won't focus on 600 side-by-side comparisons multiplied by "x" iterations...)

But, again the thread has some great conversations and strong strategic thought process involved and I love it!

Hi Team,

Thanks for the update, and great to hear that plan versioning is being developed for zzTakeoff. I know some estimators have already shared their thoughts, I haven’t read everything, so I hope not to repeat what’s been mentioned, but I’ve added a few ideas that could help make this feature more effective for us, since we’re the ones uploading and managing the drawings.

1. Simple, Controlled Versioning

• When uploading a new plan or plan set, the system should automatically assign a version number (e.g., Rev 01, Rev 02).
• Allow the uploader to add a short version note (e.g., “Updated structural layout – grid changes”).
• Make it easy to replace or supersede previous versions without losing older ones.

2. Clear Plan Management

• Keep plans grouped by trade or discipline (Civil, Structural, Electrical, etc.) so estimators can manage relevant sets more easily.
• When a new version is uploaded, the old one should be automatically marked as superseded but still viewable if needed.
• A filter or toggle to show only the latest versions would help reduce clutter.

3. Takeoff Consistency

• When a plan is updated, the system should retain takeoff links where possible, or flag takeoffs that may need review.
• A visual indicator (e.g., warning icon or note) when takeoffs were done on an outdated version would be very useful.

4. Comparison Tools

• A side-by-side or overlay view between versions would save time spotting changes that affect quantities.
• Even simple visual differences or highlight options would help identify what’s changed.

5. Audit Trail & Permissions

• Record who uploaded or modified each version, with timestamps and comments.
• Permissions to limit who can upload, delete, or archive plan versions to keep things consistent across teams.

6. Notifications

• Automatic notifications when a new version is uploaded — so estimators know when to check their takeoffs or update estimates.

Summary:

Since estimators are directly responsible for uploading and managing plan sets into the ZZTakeoff, the versioning system should be efficient, intuitive, and transparent, helping us stay organised while maintaining a clear link between drawings, takeoffs, and revisions.

Thank you all for this input. It's very helpful. We plan to have Plan Sets, Versions, Revisions, etc. as you discuss. In time we will also add custom properties on pages which would allow you to sort/group any way you want (same for Projects at the project level, too) in the same way you can now for Takeoffs & Templates.

Suppose there are 2 versions of a particular page, when switching between those versions (visually to view the current or previous version of those pages), which of these scenarios would you expect:

1. The takeoff & annotation data is the same for all versions of the page, and stays visible regardless of which version of the page is being viewed behind it

• This could be problematic if the page sizes are different or scales are different between versions since scale impacts takeoff values.
• If we allow this, if page sizes or scales change, should we just force the user to create a new page instead of a new version?

2. Each version of the page has it's own takeoff & annotation data

• In this scenario, we could track page size & scale separately per version since the takeoff & annotation data is attached to the version (not shared across all versions)
• It would be easy for us to allow moving takeoff & annotation objects from old versions to new versions, but they would be owned by a specific version, and it would be user action to move the data between versions
• If we allow takeoff data to exist on old (non-current) versions of a page, we could allow that and filter it out in reports if you guys want that data to still exist on old versions

I may not be entirely tracking but interpretation would be.

I would want my previous annotations, QTO, and estimates to come forward with new or current set. I'll make the call if it's still relevant or active by deleting hiding, adding, subtracting, or supplementing.

If I were to go through multiple iterations (revs) of a sheet I would like to understand when and why I either zigged/zagged... To add to that I would really appreciate the OLD Rev sheet QTO/estimate/annotations to be frozen/locked so they couldn't be inadvertently tweaked once a CURRENT is placed and previous sheet supercede.

If the scale has changed the user should see that visually (I would assume) and correct on their own pretty quickly. As a failsafe if it can be programmatically triggered that a QTO or estimate has varied from sheet Rev OLD to CURRENT and alert user that would be neat.

I did fail to mention that somehow the most recent or updated sheet should be noted as "CURRENT". With that being said a log similar to the one I believe @Kory posted from I think Procore or Plandgrid would be super swell to understand the history at a glance. I know this is getting more into document management than QTO and estimating but just had to put it out there...

Yes, we will be adding the "Current" or "Latest" label and some kind of "Obsolete" label on the old plan pages.

The real fork in the road is whether takeoff data for a page is shared between all versions of the page or separate per version of the page.

So, if a user switches to viewing an older version would they expect to see their "latest" takeoff data & annotations above that old page, or a completely different set of old takeoff data & annotations.

The more I think about this topic, the more I think simplicity is best, at least for us. The thing that makes our workspace most difficult is clutter. The best way to declutter this left-hand side "Pages" section is to hide what we don't need, old versions.

If I do a takeoff on A101, and then receive A101 rev1, it's simple enough to insert the new A101, move it below the old one, copy the takeoff from A101 original and paste it on A101 rev1, adjust the takeoff, and then hide the original. I don't really want to delete the old one or move it to an archived folder. I'd rather leave it in chronological order with other versions of A101 but hide it to lessen the clutter and still have it available to overlay, refer back to, or revert back to if needed.

I understand doing this process on a 600 page planset through 10 revisions would be extremely time consuming so leveraging AI to do the version naming and sorting would be a great help. Then it would be up to the user to move takeoffs, adjust, and hide.

From there, it would be nice if maybe we don't even delete the old takeoffs so they still live with the plan they are based on. Then build something into the reports and takeoffs tab code so that only takeoffs on pages that are unhidden populate these totals.

The two things I'd like to see come out of this initially would be the ability to hide pages and the ability to hide the original image on overlays, leaving only the overlaid image.

Eyeballs to hide the pages so we can filter out what we want to keep but not see:

Something that allows us to show the overlay image but not the original:

@Kory Thanks for the additional input. Yes, if we allow hiding pages (typically for old versions) we would plan to have a filter in reports (by default) to filter out takeoff data on hidden pages. This would assume that we took the path to allow the old takeoff data & annotations to persist on old pages. We could easily give users tools to move or copy takeoff data to new versions of pages.

@Heber,

When you say "Plan Sets" in your opening that makes me think this question is drilling down into the next level of "Versions." I would want Plan Sets to have their own set of takeoff when going from 30% to 60% for example, and how we transfer the takeoff is probably page-by-page at a time using the split screen feature. Now it sounds like you are talking about if we get a new amendment for the same plan set and need to "slip sheet" the documents. In my opinion I would prefer option 1, adjust to the overlay and keep cranking, now doing this page-by page is horrible and hopefully AI can help with this slip sheeting in the future.

So to answer your question, we need both and depends on if its a major drawing milestone Plan Set or an Amendment to slip sheet.

Love where this is headed. Keep it simple is the goal, because this is not simple.

@heber I can't think of a scenario where I'd want to see current annotations, estimate, or QTO on an old sheet. Especially when I can just take a snap or screen grab of the original everything from the previous version or versions and overlay them on the new. or vice versa

@Chaz Yes. Agreed. Probably good to give the user the option to either copy or move the takeoff data to the new version of the page, and then a way in reports to filter out takeoff data on "old" versions. Then when they modify new takeoff data, it's not impacting takeoffs or annotations on an old version of the page.

We will for sure be using AI to help match up the pages, etc. (maybe not in the first release...first we need to get the data structure correct). AI and lots of fancy tools to match/overlay, etc. will be easy to add after.

Terminology for old page versions: obsolete, archived, old version, hidden?

We could put old versions as child items automatically in the pages tree maybe (automatically added there similar to an overlay - and functions like an automatic overlay that can be turned on/off)? Then if new versions are added, the latest would be the parent automatically, and old versions could be "children" visibly in the UI. Or we could just make an easy toggle between versions somewhere visible when the user is viewing the page.

Archived would be my vote or watermarked version set 😉

At first, I was thinking the parent/child but when I saw @Kory post about simplicity, clutter, and focusing on the MAIN THING my mind went back to the @john @sam thread of having plan/sheet tab for all the history, data, tags, ver, etc and the takeoff tab only have CURRENT set and if overlay needs to be invoked to bring in from sheets tab that's how old sheets or supplemental sheets could get in.