Collecting Input: Assemblies, Formulas, Items

In my most humble opinion, One major pain in my archaic Old Screen Takeoff, is the lack of customization. I can go deep but only as far as the limits of the app allow me. It sounds like your on the right track. If a user only needs simple assemblies, or "builds" ZZT will work. If they need very complicated builds, it works. Need integration?...it works!

Love this and am excited to see it.

Great post Heber, keep these coming. Fun to get a glimpse into your brain!

Q1: What do you like about your current takeoff software handling of assemblies, formulas, & items.

A1: We use OST, and I love that it doesn’t clutter the system with assemblies, formulas, or items. It keeps takeoff simple.

Then, the other half of my brain— the one that tried to integrate OST with Sage, then again with eTakeoff and Sage—remembers the frustration. Those integrations never really went anywhere, and here we are, still stuck in manual data entry land like its 1990.

Q2. What do you wish was improved about your current takeoff software assemblies, formulas, & items.

A2 Now here comes the fun wishing part.

I was the admin—no handcuffs. I can figure out any software. But the real question is, can the average estimator?

The takeoff tool must let end users (without admin creds) easily create formulas, assemblies, and items. No buried menus, no multi-step setup. I love drag-and-drop interfaces—please don’t make me click through five screens to do something simple! I want to open a web browser on my left screen, drag stuff to the right screen, and—boom!—everything is linked or my items are made, or my formulas are created.

Now, let’s talk integrations—the real game-changer.

We need seamless integration with a next-level, web-based estimating platform like BidBow or Ediphi. Here’s what I really want:

• Open Ediphi or BidBow on my right screen
• Link items from zzTakeoff on my left screen
• Do a takeoff → magically see quantities updating in real-time in the estimating software on my right screen. Walla!
• Hit a button and—like magic—all my items, database configurations, and estimating structures appear, ready to roll, with ZERO setup from an "old admin" like me right in zzTakeoff from Ediphi or BidBow COOL!

One last (but critical) piece: WBS Integration

Your basic example hinted at this, but it’s something we got close to with eTakeoff. WBS integration must be done right, or it’ll be a mess. Here’s the key:

• There needs to be a clear separation between:

1. The Admin Global Database WBS (and items)
2. The Estimate-Specific, Custom One-Off WBS (and items)

If an estimator creates a custom one-off WBS (or item), it should auto-sync into the estimating platform. And vice versa—if I create a custom WBS in zzTakeoff, it should also create itself in the estimating software.

This is going to be hard—but I can’t wait for the nerd calls we will be having coming soon to being to "tinker" to start to head in a better direction than 1990!

I agree with Kyle. Keeping the interface as clean and simple as possible is ideal. I suppose that if it eventually becomes too click heavy, you could add a "pro/advanced" mode of the UI down the line?

Also, I would like to be able to see this platform take over more of the legwork I have to do once I'm done taking things off which I'm normally forced to manually do in Excel.

Here is a mild example: I just used the Extract Schedule tool to pull a plan's footing schedule to do my counts. The schedule contains the L W H of each footing.

Presently, this tool just adds a string of text with these values in the description like this:

When I'm done taking them off, I have to either export the takeoff totals/report into Excel or copy and paste this data into Excel, and then I have to use the text to columns tool in Excel to separate out the 8'-0"x8'-0x"x20" and then another formula to divide 20" by 12, to ultimately end up with a row that looks like this: F8.0 | 8 | 8 | 1.67 | (QTY)

I would want that text string that the tool extracted to actually be used for the takeoff object's properties and use the L W H so that when I go the Reports screen, it can have all of that put together for me.

In other words, as I apply the footing counts to the page, it's building a report with that info. I'll mark all the instances of "F8" and zzTakeoff will be applying the assigned length, width, height columns next to it, even the conversion of inches to feet so that it reads 8.0X8.0X1.67.

If that's asking for too much right now from the schedule extraction tool and this assemblies/formulas functionality, the ability to just put in those properties for the footings so that I don't have to retype them or separate them later in Excel would still save me a ton of time.

And then to take this a further step, I have several calculations (formulas) I need to perform with this data to determine concrete yardage, forming, etc.

If the reports could be tailored to not only apply the count takeoff object's quantity, length, width, and height, but also provide columns for me to have those calculations automatically parsed using the column's assigned formula, with a subtotal at the end of it...then it's conceivable that one day, I would barely even need to use Excel anymore and will be able to put together everything I need straight out of zzTakeoff.

1. What do you like about your current takeoff software handling of assemblies, formulas, & items.

I've used Planswift and Square Takeoff but currently use Prebuilt ML. As a commercial wood framing contractor virtually no estimating software caters to us except Prebuilt ML. It has a "Wall Assembly" as a specific top level assembly that is distinct from a generic linear assembly. This special assembly has wall height, stud spacing, plate quantity and thickness built in so it can generate exact stud lengths. In addition to the assemblies, it has a great layout tool that prints a color coded layout with a legend showing everything you've taken off with an assembly attached. That layout is great for a second review of your work or for field use to find out what goes where.

2. What do you wish was improved about your current takeoff software assemblies, formulas, & items.

Prebuilt ML's user interface is dated and confusing, its database is uneditable, it's language is specific to the Pacific NW and takes some time to get used to if you're unfamiliar with it. It's not web based and requires the typical license release from one computer before you can use it on another. Any changes made to a template are on that one machine only. Mixing Prebuilts layouts and Wall Assembly features with a modern web based tool would be fantastic.

Integration with other 3rd party bidding systems is unimportant for me. WBS would be helpful though to breakout items when necessary.

Thanks for reaching out and seeking feedback, I'm looking forward to seeing what you come up with!

Some thoughts about basic architecture.

I would tend to organize my process into either a QTO or ESTIMATE. The annotating and creating RFI's are part of the job as well and that would be separate but coincide with the QTO, but really a function of PRECON or OPPORTUNITY/PURSUIT.

The QTO would generally be a TYPE or a defined TEMPLATE

TYPE

• The TYPES (area, linear, segment, count) are perfect the way they are - ALWAYS!

TEMPLATES

• Personally, I would prefer to define my own TEMPLATES, even though I've seen many software companies try, succeed, & fail. I think it's specific to the user or company (no need to see MEP TEMPLATES if my company only does earthwork or concrete)
• My definition of TEMPLATE would be a TYPE that I have built in custom calc's, variables, inputs, etc (sim. to PS days)
• For the most part TEMPLATES would be simple and leave the assemblies to do the heavy lifting calcs as details/specifics are discovered or brought into the estimate process.
• These potential TEMPLATES would most likely calculate volume, sfca/vsf, etc for common QTO's like trench excavation, pile cap, etc

I agree with comments above regarding the TYPES/TEMPLATES screen should be simple for performing QTO and studying/annotating plans. Not getting into the estimating portion yet

The next step in my process would be the estimate and I look at these in 2-3 different ways, depending on the information required. These costs, to me, usually fall under the following categories:

• UNIT PRICING
• If I'm looking for quick numbers I will generally look to UNIT PRICING data
• Some examples: 4" SOG - $5.66/sf, Seal & Paint = $2.75/sf, Mass Excavate = 11.50/cy, etc
• The U/P's would be generally fed from a TYPE or TEMPLATE qty but it would be nice to somehow just add some of these U/P items and enter my own "estimated" qty as well, when a QTO doesn't really to the job - If I'm using zzQTO as my estimate tool.
• RESOURCES or ITEMS (MLESO - material, labor, equipment, subcontract, other)
• The next way I would look to an estimate would be the actual cost of RESOURCES. I look to this area for subcontracting and self-perform estimates
• Some examples: Compact Excavator = $1,200/wk, Drywall = $18/sh, Structural Iron Worker = $35/hr, etc)
• ASSEMBLIES
• Combination of RESOURCES or ITEMS. This is where more intense calculations would be done based on project, QTO, etc
• There's a lot of convo on this category from a software development usability side
• OTHER
• If I'm looking at a tool like zzQTO or S***K to do full estimating/proposal I would need some way to see the "other" costs that aren't tied to a TYPE or TEMPLATE (field truck x2 for 13 months, tower crane for 5 mo, PPE supplies * 500, etc. Not sure if I would prioritize this, but this gap has led me to rely on spreadsheet more than all-in-one software in the past.

The ability to organize by WBS, CSI, Uniformat, Company coding or bid packaging is clutch. I would lean to the ability to create as many custom grouping/lists as a user wants for the above estimating or QTO items

Not sure about the integration capabilities but certainly hip to whatever comes out of the valley

Thanks for all the input 🙂 We're working hard on templates, assemblies, formulas, and items as we speak. I think you'll like it.

For the most part PlanSwift’s implementation was pretty good…particularly because of the customization. That said, I think zzTakeoff needs to be strong in a few key areas:

1. Customization

2. Distinction b/w eaches and pieces of material

3. Options to use a basic formula or, in the case of pieces, to use an optimization formula (algorithm) that can generate a list of materials from the cut pieces.

Ideally, everything should be estimated by its usage. Properties of materials should be selected. Afterward, item #s or skus should be matched to the materials per their properties.