Every Sage Estimating database starts out tidy. A few years and a few hundred bids later, it can turn into something only one or two people fully understand. The difference between a database that ages well and one that doesn’t usually comes down to decisions made early: what the items represent, how assemblies are used, and how the WBS codes are laid out.
The most useful principle we know is simple. The database should describe how your company builds, not how someone else’s template happens to be organized. A concrete contractor, a home builder and a general contractor doing tenant improvements will all want different structures, even if they start from the same standard database.
Start with how you price work
Before anyone touches an item, it helps to sit down with your senior estimators and walk through a recent bid. Ask a few plain questions:
- At what level of detail do you price labor — by crew, by task, or by unit of installed work?
- Which materials do you buy and track individually, and which do you treat as an allowance?
- How do your project managers and accounting team want costs rolled up once the job is awarded?
- Which scopes do you self-perform, and which always go to subcontractors?
The answers shape everything that follows. If your field tracks costs by phase and your accounting system uses a particular cost code structure, the estimate should be able to produce numbers in the same shape. That is far easier to design in than to retrofit.
Items: the building blocks
Items are the individual cost components in the database — a material, a labor task, an equipment charge, a subcontract allowance. A few habits keep them manageable:
- Use consistent naming. Agree on a pattern for descriptions (material, size, type, then any qualifier) and stick to it. Estimators search by description far more than by item code.
- Be deliberate about units. Decide whether a given item is priced per each, per linear foot, per square foot or per cubic yard, and make sure the productivity rates match that choice.
- Avoid near-duplicates. Several versions of the same item with slightly different prices is one of the most common sources of confusion. When a price changes, update the item rather than creating a new one.
- Keep inactive items out of the way. Rather than deleting items that older estimates still reference, many teams move them into a clearly labeled group so they stop showing up in everyday use.
Assemblies: capturing your methods
Assemblies group items together, often with formulas, so an estimator can answer a few questions — wall height, spacing, thickness — and let the database calculate the related quantities. This is where much of a company’s estimating knowledge ends up living.
Good assemblies reflect how your crews build. If your team always forms, pours and finishes a slab-on-grade in a particular way, the assembly should mirror that sequence and those productivities. We usually recommend building a smaller number of well-tested assemblies for the work you do most, rather than trying to cover every possible condition on day one. You can always add more as patterns emerge.
Formulas deserve extra care. Keep them readable, use variable names that an estimator will recognize, and document any assumptions — waste factors, lap allowances, rounding — somewhere the team can find them.
WBS codes: how the estimate rolls up
Sage Estimating uses work breakdown structure (WBS) codes to organize and summarize an estimate in different ways. One code might follow CSI divisions, another your internal phases, another the location or building area. Deciding which of these you need, and how they line up with your job cost system, is one of the most valuable conversations you can have during setup.
A few practical points:
- Keep the number of WBS levels to what you will report on.
- Assign default codes at the item level wherever possible, so estimators aren’t coding by hand on every bid.
- Agree on who is allowed to add new codes, and how those changes are communicated.
Keeping it maintainable
Because Sage Estimating supports multi-user databases, several estimators can work from the same shared pricing and assemblies. That is a real strength, and it also means changes affect everyone. Most teams benefit from naming one or two people as database owners who review proposed changes, update prices on a regular schedule, and keep a simple log of what changed and why.
It also helps to review the database once or twice a year. Look for items that haven’t been used in a long time, assemblies that estimators routinely override, and prices that have drifted from recent buyout numbers. Small, regular cleanups are much easier than a large rebuild later.
If you’re starting fresh, or wondering whether your current structure still fits, our Sage Estimating page covers how we approach setup and training.
Every company’s database ends up a little different, and that is how it should be. If you’d like a second pair of eyes on yours, we’re happy to talk it through.