We actually read these.
Ideas submitted here go to the product team, not into a void. Add yours, vote on others, and comment on what matters to your business.
Talk to our Product Managers live: every other Monday, 1:00–2:00 PM ET → https://www.d-tools.com/cloud-product-office-hours
Integrators routinely sell products that come with a standard set of supporting materials — wiring packages, pre-wire kits, mounting hardware bundles, install material kits — that should travel with the product wherever it's quoted. In D-Tools Cloud today, accessories on a product can only be other Products or Allowances. Packages can't be attached as accessories, so the supporting bundle has to be added as a separate line item every time, or rebuilt as a flat product list, or maintained as a standalone package that someone has to remember to add alongside the parent product.
This breaks the logical link between a product and the materials needed to install it. It also creates ongoing maintenance pain: when the pre-wire package changes, every product that should carry it has to be updated by hand because there's no parent-child relationship to inherit from.
Quote accuracy. Forgotten wiring or install materials show up as missed margin or scope surprises in the field. Making the package travel with the product closes that gap at the catalog level rather than asking every estimator to remember.
Catalog maintenance. Today the same bundle of wire, connectors, and hardware has to be either duplicated as individual accessories on every product or kept as a separate package that lives outside the parent product's accessory list. Either path scales poorly as the catalog grows.
Consistency with how integrators actually sell. AV and low-voltage work is built around "this product plus the stuff that goes with it." Packages are how dealers already model "the stuff that goes with it." Letting a package be an accessory is the natural way to express that relationship.
Foundation for downstream behavior. If a package can be an accessory, then accessory-driven behavior (recommended vs. required, optional sets, alternates) starts to apply to whole bundles instead of one item at a time.
When a package is added as an accessory and the parent product lands on a quote, how should the package's own items present — collapsed under the package name, expanded as individual lines, or configurable per quote/proposal view?
How do package accessories interact with quantity? If the parent product is quantity 3, does the wiring package multiply, or does the package quantity stay 1 because the package itself already includes its own per-unit counts?
How should pricing and labor roll up — does the package's price contribute to the parent product's accessory total the way a product accessory does today, or is it shown separately?
Should the package's own accessories (and labor) come along when the package is attached as an accessory, or is only the package's primary content carried forward?
Are there guardrails we need against nesting depth — for example, blocking a package that already contains a package from being attached as an accessory?
How does this surface in inventory, plan view, and proposal output where accessories are commonly grouped under the parent product?
Exploratory only — not commitments.
Extend the accessory picker on Products and Allowances to include Packages as a valid accessory type, with the same Required / Recommended / Optional behavior accessories already support.
Treat package accessories as a "bundle reference" — adding the parent product to a quote auto-adds the package and its contents, with a UI affordance to expand/collapse the package on the quote and proposal.
Consider whether Allowances and Packages should also be able to carry package accessories, or whether v1 is scoped to Products only.
If full package-as-accessory carries too much scope risk, an intermediate step would be a "linked package" concept — a lightweight pointer that prompts the estimator to add the package without auto-including it.
