Let Customers Build Their Own Package Before They Ask You for a Price

A better first conversation

A package builder is a guided way to choose parts of an offer. The customer selects a starting package, changes a few options and sees a summary. Depending on the business, that summary could lead to a quote request, an appointment or a properly supported checkout.

For our imagined furniture-rental business, the first version would stop at a planning estimate. The customer could compare four seats with six, see the included pieces and send those choices with the event date. Staff would then confirm availability, access and the final quote.

That gives both sides something specific to discuss. The customer can decide whether the idea is roughly within reach. The business can answer “Can you provide this arrangement on this date?” instead of reconstructing the entire request from a photograph and a vague budget.

It is a plausible benefit, not a guaranteed increase in sales. If people still cannot understand the offer, a more elaborate selection tool may simply give them more places to get stuck.

What changes when the customer adds two chairs?

Use a deliberately small menu. Suppose the starting lounge contains one two-seat loveseat at $200, two armchairs at $90 each and a coffee table at $60. A defined local delivery, setup and collection service adds $140. The planning subtotal is $580 before applicable tax.

These are invented US-dollar prices for one agreed rental period, ground-floor access and a location inside the business’s defined delivery area. They are not market rates. Rugs, flowers and other styling props in a photograph are not included unless the summary lists them.

The useful interaction is the visible difference. Add the chairs and side table; the subtotal rises by $220. Remove them; it returns to $580. The customer should be able to inspect each line and change their mind without starting again.

A sensible default can do more than a huge catalogue. Show a coordinated starting arrangement, explain how many seats it provides and offer only the variations the business can reliably fulfil. Do not make the customer learn every internal product code to create something usable.

Keep the estimate honest

Now the customer says the venue is upstairs, or beyond the local delivery area. The $140 assumption no longer applies. The builder should show the furniture subtotal and flag delivery as “Needs review,” with a short explanation. It should not quietly leave the old total in place or treat an unknown cost as zero.

Likewise, choosing an event date does not prove the furniture is available. A catalogue can describe an item the business owns while that item is already promised elsewhere. In this proposed first version, the page would say that the request does not hold the items or the date.

Keep three things distinct in the interface: the customer’s selected package, the estimate under stated assumptions, and the business’s confirmed offer. Put the qualification beside the number, where it can shape the decision. A long disclaimer after the contact form cannot repair a misleading headline price.

When the request is received, say what happened and what comes next. W3C’s form guidance calls for clear submission feedback and errors that explain how to fix the problem. Here, that means “Request received” when a request was saved—not “Booking confirmed” before the booking process has actually finished. [3] (opens in a new tab)

Keep choosing easier than emailing

A first screen might ask how many seats the customer needs, then show the two suitable arrangements. A second could collect the event date and delivery area. A final summary would bring the pieces, estimate assumptions and unresolved questions together before requesting contact details.

Three screens are not a rule. A short offer may fit comfortably on one page. For a longer flow, W3C recommends logical stages, recognizable optional steps and visible progress. Customers should be able to revisit a completed step without losing their choices. [2] (opens in a new tab)

I would let people see the planning estimate before asking for an email address. Then ask only for the details needed to respond to that request. Save the selected items, quantities and assumptions with it so the customer does not have to type the same information again. State how the contact details will be used.

On a phone, the price summary must stay readable without covering the choices. Use clear text labels alongside photographs, make selected states easy to identify and test the journey with a keyboard. If a choice changes the price or exposes an error, check that the feedback is understandable with assistive technology as well as visually.

Build around the offer you can maintain

Start with one package family that staff already quote consistently. Write down allowed options, quantities, included services and the situations that require a person. If staff cannot agree on those rules, settle that before turning them into a customer-facing tool.

There are several implementation routes. A calculation form can be enough for a simple estimate and request. An existing commerce system may suit a structured catalogue. A custom connection becomes more relevant when pricing, customer records and date-based availability need to work together. The right choice depends on the rules and systems already in use.

For example, WooCommerce’s Composite Products documentation supports a base price, individually priced component selections, or both. It also explains that a base price alone does not change with the configuration. That is a useful reminder to test the pricing model, not just the appearance of the selector. This documentation is not evidence that the extension alone manages rental dates. [1] (opens in a new tab)

The displayed calculation also needs a trusted check when it is submitted. MDN explains that browser validation can be bypassed and must be backed by server validation. For this proposed builder, the server should recheck allowed selections and calculate from current business prices, rather than accepting whatever total the browser sends. [4] (opens in a new tab)

Assign someone to maintain the offer. Changes to prices, service areas, stock or included items need to reach the builder. Preserve what the customer saw with the request, and flag any difference when staff prepare the quote. Integrations, exception handling, accessible interaction and ongoing updates are real cost drivers; the arithmetic is often the smaller part.

The portfolio’s Vanta Booking project includes hosted storefronts, booking checkout and merchant tools for products and availability. Those are relevant pieces of the wider journey. The furniture-package estimator described here is a separate proposed feature, not a capability claimed for that project.

Use it only if the conversation gets better

A builder earns its place when customers regularly choose among repeatable options. If almost every job needs a site visit and a custom scope, a short guided brief may be more honest. If the business sells three fixed packages with few exceptions, a well-written comparison page may already solve the problem.

Try the limited version with real enquiries and compare similar requests from the existing process. Track how many people reach a useful estimate, how many send a qualified request, how many clarification messages staff need and how much time it takes to prepare the confirmed quote.

Also record why the confirmed price differs from the preview. Repeated delivery surprises suggest the assumptions need work. Frequent unavailable-item substitutions point to the availability process. Abandonment at one choice may reveal confusing wording rather than a need for more features. Small samples are signals to investigate, not proof of a conversion lift.

The goal is a customer who can say, “This is roughly what I want, and I understand what still needs confirming.” For the business, that is a much more useful beginning than another message asking for the entire price list.