What does a product really cost after the sale?

Before ordering the first substantial production run, the team behind a measurement device faces an awkward decision. Extended diagnostics adds 40 currency units to the hardware cost of each unit. It also requires software and a service tool. On the bill of materials, it looks like an obvious candidate for removal. The service engineer argues that without it, some problems can only be diagnosed during a customer visit.

Both sides may be right. The outcome depends on scale, ticket frequency, the actual effectiveness of diagnostics and the support period. Saying that more expensive hardware will save money on service does not yet justify the decision. We need a model that shows which benefits we pay for upfront, when they should arrive and which remain unproven assumptions.

This article develops that model for one hypothetical device family. All prices, rates and times are teaching assumptions. The currency unit, abbreviated CU, does not represent a particular supplier’s quotation. This is an analysis of a design decision, not a service price list or a report of a BBest24 deployment.

First decide whose costs we are comparing

Post-sale cost has no single natural boundary. The manufacturer pays for support and maintaining updates. The customer may pay for downtime, operator effort and getting a service engineer into the facility. An integrator bears coordination costs. If we compare only the manufacturer’s invoices, a solution that shifts work onto the customer can look cheap even when the overall system becomes more expensive.

Our example compares costs borne by a manufacturer providing five years of support for the same device cohort. All 1000 units are installed at the beginning and remain active for five years. We do not model new annual sales cohorts, replacements that expand the fleet or early retirement. This simplification makes the decision understandable; a real business must account for delivery timing separately.

The comparison includes hardware, additional diagnostic development and support costs that differ between the alternatives. We omit common project, sales, basic firmware maintenance and identical update costs because they do not change the difference. That does not mean they are zero. The chart therefore shows selected lifecycle costs, not a complete product profitability calculation.

Explicit boundaries are consistent with GAO’s approach to cost estimating: define the purpose, scope, technical baseline, assumptions and how actual data will update the estimate. GAO-20-195G, published in 2020, covers a much wider estimating practice. We use its principle of a transparent model without transferring an entire large-program management method to a small project.

Two devices serving the same user need

Variant A has basic diagnostics. It records the last error code and exposes the device’s current state during a customer support call. Variant B also retains restart history, basic supply information and event context. An authorised service engineer can retrieve a diagnostic package. B cannot remotely repair a damaged connector. Its purpose is to distinguish installation, power and software problems before someone travels to the site.

For both variants, we assume 0.2 tickets per device-year, giving 200 tickets annually across 1000 devices. This is an event rate, not the probability that exactly 20% of devices fail. One device can generate several tickets while another generates none. A ticket can arise from configuration, instructions, customer infrastructure or a fault. Calling every ticket a hardware failure would misrepresent equipment reliability.

We assume the following costs for handling one ticket:

The visit cost is additional to remote work and includes only travel and on-site work within the example’s boundaries. We do not charge the same hours twice. The values of 60 and 30 can be interpreted as half an hour and a quarter of an hour at a fully loaded hourly cost of 120 CU. This remains an assumed internal rate, not a market price.

The most optimistic part of the table is not the electronics price. It is the reduction in the share of visits from 50% to 20%. We must demonstrate that reduction using representative cases. Collecting more logs does not guarantee it. The data must survive the failure, reach the right person and support a decision that was previously impossible.

A calculation that can be reproduced

A’s hardware costs 200 CU per unit; B’s costs 240 CU. B also needs 20,000 CU of one-off development and 6 CU per active device-year to maintain its diagnostics. In the model, this covers additional infrastructure and service-tool operation. It is not a cloud quotation or a claim that every security-related cost will fit inside that allowance.

A’s expected ticket cost is 60 + 0.5 × 600 = 360. For B, it is 30 + 0.2 × 600 = 150. The saving is therefore 210 CU per ticket. At 200 tickets annually, that yields 42,000 CU, from which we subtract 6000 CU of additional maintenance. B’s annual operating benefit is 36,000 CU.

However, B initially requires another 1000 × 40 + 20,000 = 60,000 CU. After five years, A’s selected costs total 200,000 + 5 × 72,000 = 560,000. B totals 260,000 + 5 × 36,000 = 440,000. The difference of 120,000 CU favours B under precisely these assumptions.

The lines cross at approximately 1.67 years. This follows from dividing the additional investment of 60,000 by the annual benefit of 36,000. It is a simple, undiscounted payback period with events accruing evenly. The chart does not promise that a particular visit or invoice will occur in that month. Annual billing and uneven ticket arrivals would produce different cash flows.

The calculation follows the formulas and assumptions given above. The same model supplies both figures, so the charts and sensitivity analysis describe the same comparison.

A small production run changes the answer

Now suppose we sell only 100 devices while still paying 20,000 CU for development. The hardware premium becomes 4000, making the additional upfront investment 24,000. Annual operating benefit falls to 3600. Over five years, we recover 18,000, leaving B more expensive by 6000 CU.

The payback period would be approximately 6.67 years, but the support horizon under analysis is five years. We cannot present that figure as payback achieved within this project. Longer support or sharing the tool across products may be reasonable alternatives. They require changing the analysis boundary and allocating shared costs honestly. Adding unsupported future sales is not enough.

For a fleet of N devices, five years and an annual ticket rate p, B’s saving per device is:

5 × (210 × p − 6) − 40 − 20,000 / N

Break-even is approximately 0.086 tickets per device-year for 1000 units and 0.257 for 100 units. In a small production run, extended diagnostics needs substantially more problems to justify itself solely through service savings. This is not an argument for poorer quality. It suggests that the tool may need a less expensive implementation or a different justification.

Even a large fleet cannot rescue an option that produces no operating saving. At 0.02 tickets per device-year, the benefit before maintenance is 210 × 0.02 = 4.2 CU per device, less than the annual diagnostic cost of 6 CU. The additional investment is never recovered in this constant-rate model, regardless of the horizon. Reporting a negative payback period would be an interpretation error, not an attractive result.

What the pilot actually needs to demonstrate

The most valuable experiment is not launching a dashboard with many parameters. It is handling the same set of cases with and without diagnostics. Useful cases include power loss, incorrect configuration, loss of connectivity, a damaged connector, incompatible firmware and an event with no clear cause. Each case needs an expected diagnosis and an acceptable escalation route.

A service engineer should solve cases using data available in the actual product, without hints from the person who induced the fault. Measure active work time, diagnostic correctness, whether a visit is needed and the share of unresolved cases. Dashboard clicks do not measure savings. A faster but incorrect diagnosis can increase downstream cost by causing unnecessary parts shipments.

Laboratory reproductions establish whether diagnostics can distinguish causes. They do not establish how frequently those causes occur in the field. We therefore also need real ticket records, together with the number of active devices and their observation time. Ten tickets among a hundred devices observed for one month represent a different exposure from ten tickets over a year.

Nor should we measure the effect using a simple reduction in visits between successive quarters. Installations, engineer experience, instructions or underlying product quality may have changed. Without a comparable group, record those limitations and examine individual cases. A cautious conclusion that visits were avoided in particular scenarios is more useful than an unsupported promise of a specific percentage reduction across the fleet.

When the tool works but does not change the decision

Consider a less favourable pilot result. Remote work falls to the assumed 30 CU, but 45% of tickets still require a visit rather than 20%. B’s ticket cost becomes 30 + 0.45 × 600 = 300 CU. We save only 60 CU against A. For 1000 devices and 0.2 tickets annually, that produces 12,000 CU of benefit before maintenance and 6000 afterwards.

Over five years, we recover 30,000 of the additional 60,000 CU investment. B remains more expensive by 30,000. The tool can be correctly implemented, convenient and faster while still failing its original economic justification. This matters during acceptance: a list of completed screens cannot substitute for a criterion measuring support effectiveness.

We may also diagnose the cause remotely while the customer’s procedure still requires a visit. The benefit could then be bringing the right spare and avoiding a second trip. The model must change: count visits per ticket, not just the share of tickets involving at least one visit. We cannot claim the full saving from avoiding a first trip and also count that same trip as a saving from better preparation.

This variant suggests a specific pilot acceptance condition. Before testing, agree which activities diagnostics should eliminate and which it should merely shorten. Only then can we determine whether the evidence supports the proposed calculation.

Costs have dependencies that a table can hide

In the basic example, ticket rates and diagnostic effectiveness remain constant. A real product can generate many installation-related tickets, enjoy a quiet operating period and then encounter ageing problems. With such a pattern, the additional investment may pay back earlier or later despite an identical five-year total. Cash planning therefore needs events distributed over time, rather than dividing everything by five.

Some assumptions are correlated. Hard-to-reach facilities may have more expensive visits but weaker connectivity, reducing the availability of remote diagnostics. We should not automatically combine the highest visit cost with the tool’s best effectiveness. A useful scenario describes a coherent environment, such as data access available only during a short maintenance window and a mandatory local operator.

Cost does not always scale linearly. A second data region, another support shift or an additional specialist may become necessary at a particular fleet size. Conversely, a tool licence may serve several device families. The annual allowance of 6 CU per device then needs to be replaced by fixed costs, fleet-dependent costs and capacity thresholds. Charging the first hundred devices for every fixed cost or spreading those costs across uncertain future sales can lead to opposite, equally misleading answers.

Useful sensitivity analysis first changes one unknown to expose the mechanism, then tests several coherent combinations. NASA describes decision analysis as comparing alternatives with explicit criteria and limitations of knowledge. Here, further investigation is most valuable where better evidence could reverse the choice, such as the uncertain visit rate after introducing B.

Diagnostics is itself a product that needs maintenance

A diagnostic package needs format versioning, access control, size limits and retention rules. A service engineer must know whether a missing event means there was no fault, the buffer overflowed or recording failed. Restart history without firmware version and uptime can produce misleading comparisons. Designing these features belongs in the upfront cost; changing them later belongs in maintenance.

There is also a risk of introducing another failure mode. Intensive logging can load storage, communication and processing resources. A remote interface needs updates and limited privileges. If the diagnostic tool requires broad access to a customer’s installation, organisational work may exceed the time saved during diagnosis. We should not automatically price all of this using one rate. First establish whether the option meets operational and security requirements.

An update also involves more than delivering a file. The team must check compatibility with hardware revisions, provide a recovery path, monitor the outcome and support units that remain offline for long periods. A common update mechanism for A and B does not affect our cost difference. If B requires a separate service, another agent or more frequent format changes, those costs stop being common and must return to the calculation.

End of support needs to be treated as a technical scenario. Will the device retain its basic function after the diagnostic service closes? Can the customer export its history? What happens to former service engineers’ permissions and retained packages? Five years in a spreadsheet is not automatically an acceptable support period for every product. Contractual obligations and applicable requirements must be established for the specific market before accepting the cost boundary.

Rare events do not disappear inside an average

Expected ticket cost is useful for comparing alternatives but poorly describes a common cause affecting many devices at once. A defective update might create a thousand tickets in the same week. The constraints then become team capacity, spare availability and recovery time, rather than simply the total number of labour hours.

Describe such a case separately: what happened, how many devices are exposed, how the problem will be detected, how recovery works and which costs remain outside the manufacturer’s control. Do not add an arbitrary risk allowance to every line if the same incident has already been counted as a separate scenario. That creates another form of double counting.

It is also important to distinguish cost savings from released capacity. If an engineer saves ten hours, the team’s payroll may remain unchanged. The benefit may be a shorter queue or the ability to support a larger fleet without recruiting. That has value in a resource model, but it does not necessarily cause an immediate reduction in cash spending equal to ten hourly rates.

A decision record before ordering the production run

Rather than presenting only the 120,000 CU figure, record the decision together with the conditions under which it remains sensible. The following is a useful minimum for a discussion between engineering, service and the product owner.

The ticket register should connect device identity and revision with symptoms, established cause, active working time, visits, parts and repair outcome. Separately record whether diagnostics was available and whether it actually changed the decision. Missing information must remain marked as missing rather than being entered as zero work time or no visit.

In our example, B is justified for 1000 devices under the stated assumptions but not for 100 units over five years. The next sensible step is to verify the reduction in visits and the actual maintenance cost, because those assumptions sustain the advantage. A well-prepared calculation does not end the discussion. It identifies the evidence needed before the organisation turns an attractive promise into a commitment lasting many years.

Sources

• GAO: Cost Estimating and Assessment Guide, GAO-20-195G, published 12 March 2020. Scope, technical baseline, explicit assumptions, sensitivity analysis and updates using actual costs.
• NASA: Systems Engineering Handbook, 6.8 Decision Analysis, criteria for comparing alternatives, uncertainty and documenting decision limitations.

Sources checked on 21 October 2026. Neither source provides the prices or failure rates used in this example. All figures and calculations come from the explicit synthetic model described in the article.