Hardware Business Case Template

Give your champion a decision they can carry internally.

A hardware business case should help the customer approve a specific change in their operation. It needs to explain the problem, the evidence, the work required to implement the equipment, and the decision someone is being asked to make.

That is the document I want a champion to carry into the meeting I will never attend.

I came to this work through advanced materials, solar, and hardware commercialization. The questions changed with the product. How does a polymer fit into an existing manufacturing process? What does a solar installation mean for the roof, the utility connection, and the business underneath it? What does the person approving the purchase need to understand before they can take responsibility for it?

Those questions belong in the sales process while the customer can still help answer them.

Start with one live opportunity. Pick a customer who has shown interest and for whom you can name a next decision. The worksheet below will help you build a short brief, mark what is confirmed, and identify what you still need to learn.

Try the three-sentence version first

Put your deck aside and finish these sentences in the customer's language:

1. Today, this process costs us ___ in ___, measured by ___.
2. This equipment would change ___, and the evidence is ___.
3. To proceed, we need ___ to approve ___ by ___.

The first blank might involve time, scrap, downtime, energy use, or another measure the customer actually cares about. You do not need to turn everything into money before you understand the operating problem.

Leave an answer blank when you do not know it. “Higher efficiency” needs a baseline, a process step, and a person who agrees that the improvement matters. The blank tells you what the next customer conversation should accomplish.

Build your business case

Use the seven fields below as a working brief. You can explore a fictional example, write your own answers, mark their evidence status, and export the result. The example illustrates the method; it is not a client case or a claim about typical results.

1. State the decision you need

Write the request before you write the product description. Is the customer deciding whether to run an evaluation, fund a production purchase, approve vendor onboarding, or expand into another site? Each request requires different evidence and different people.

I make a simple distinction in my work: technical proof means the product does what it is supposed to do. Commercial proof means somebody is willing to pay for it. A successful evaluation can supply valuable technical evidence while leaving the commercial decision unresolved.

For example, “Approve a production proposal for the packaging line” is a more useful starting point than “Move forward with our platform.” It gives both sides something to examine. Which line? What scope? Who can approve it? What still needs to happen before the proposal makes sense?

Do not make the request larger than the evidence supports. An evaluation can be the right next step when it answers a defined question.

2. Establish the customer's baseline

Ask the customer to describe the current process and show how they measure it. Then find out who owns the result. A metric used by the engineering team may mean something different to the person running a shift or approving capital.

This is part of what I mean by proof. I want to understand how the equipment affects the buyer's operation, including the bottlenecks above and below the process it changes. Improving one machine's performance is useful when the customer understands what that improvement does to the wider operation.

Record the measurement, its source, and the conditions under which it was collected. A number from one carefully selected demonstration is different from a baseline across normal operating conditions. Both may be useful, but the reader needs to know which they are looking at.

Ask the operating owner to correct this section. A disagreement about the baseline is worth finding now, before it becomes the denominator in every benefit claim in the proposal.

3. Translate the result into an operating change

At SolarCity, I found that the structure of the purchase could make the decision easier to understand. For the East Coast customers I was selling to, a fixed monthly lease was easier to digest than a power purchase agreement whose escalator concerned them. Replacing an existing bill was a familiar decision.

I take a similar approach to explaining hardware. Start with the change the customer understands and cares about. Then show the technical evidence that supports it.

My background includes fine art, and I look at complex technologies through that lens. I want to make the important relationship visible. In a business case, that relationship runs from the product's performance to something that changes in the buyer's world.

For a fictional inspection system, the useful question might be how a reduction in false rejects affects the inspection team's work. The business case would still need to establish the current rate, the test conditions, and whether the improvement holds on the customer's parts. “Better accuracy” alone leaves all of that work to the reader.

4. Separate evidence from assumptions

Mark each answer as confirmed, assumed, or still unknown. Confirmed should mean you can identify the evidence or the customer who verified it. A confident internal opinion belongs in the assumptions column until it has support.

At Voltaic Coatings, I made the mistake of assuming people would want the technology before we had established the demand. We shifted toward finding potential customers and developing the evidence needed to move the research forward. That experience is part of why I want commercial questions exposed early.

A test result does not establish every claim you might want to make from it. If a system performed under controlled conditions, document those conditions. If the production environment differs, identify what still needs to be demonstrated there.

You can keep the brief short without hiding uncertainty. Put the supporting data in an attachment. In the summary, state the claim, what supports it, and the open question. A buyer should be able to distinguish what happened from what you expect to happen.

5. Include the work required to make it useful

At Energy Fox, the conversations around commercial solar included roof longevity, ongoing maintenance, impact on the business, utility interconnection, and structural analysis. Those were part of helping a customer understand a project they might commit to.

The equipment arrives inside an existing operation. Somebody has to make room for it, connect it, learn it, support it, and deal with the consequences if the implementation goes badly. The business case should make that work visible.

Write down the customer's responsibilities alongside yours. Who prepares the site? Who provides the necessary data or access? Who trains the people who will operate it? What has to happen before normal use can begin? Put a name or an unresolved question beside each responsibility.

Then ask about timing. I look for both the customer's purchasing process and the implementation window within their own operating or development schedule. A target close date is much easier to defend when it connects to those facts.

6. Let the customer help define the economics

List the benefits and costs that belong in this customer's decision. Include the equipment, integration, training, support, and internal work that the customer will need to account for. Make the assumptions visible and ask the financial and operating owners to review them.

Be careful with benefits that overlap. If the same improvement saves operator time and increases capacity, the customer needs to establish how that time will actually be used before both become separate financial benefits. Capacity has value in the context of demand and the rest of the operation.

The brief can carry a simple calculation, but its inputs need owners. Write down who supplied each input and which conditions would change it. Let the buyer's team apply its own investment criteria rather than declaring a universal payback threshold for hardware.

Funding also needs a conversation. The group that can pay for an evaluation may not control production spending. Ask which budget would carry the proposed purchase and what the owner needs to see before requesting approval. An unanswered funding question belongs in the next-step list.

7. Name the approval path

Your champion is doing valuable work. Make it easier for them to involve the people whose decisions matter.

Identify the operating owner, financial approver, procurement contact, and any other role whose requirements affect this account. The actual organization matters more than an average buying-committee size. You can use the hardware buying-committee guide to work through the people and their questions.

For each unresolved issue, name the person who can answer it and the next action. “Procurement review” is a starting point. “Our champion will introduce the procurement owner so we can establish the vendor requirements” gives the conversation an owner and a purpose.

Agree on the next decision meeting when there is enough information to do so. The outcome might be a production proposal, a defined further evaluation, or a decision to stop. What matters is knowing what the customer will be able to decide and what evidence they need in the room.

Read the brief with the person who will use it

Send the draft to the champion and ask where it misrepresents the way their company works. Invite the operating owner to correct the baseline, implementation plan, and responsibilities. Ask the financial approver which assumption they would question first.

There is a practical test I like: let the champion explain the proposal back to you without your help. Listen for the parts they can comfortably repeat and the places where they have to invent a connection. Those gaps tell you where to improve the document or deepen discovery.

Keep the technical evidence available. The goal is a concise summary with enough supporting material for each person to inspect what matters to them. You can find the larger sequence in Proof to Pipeline.

The same discipline matters after a successful pilot. If the next phase involves new people, a different budget, or another site, revise the brief with them. The first team's understanding does not automatically transfer to everyone who will inherit the equipment.

Bring one real opportunity

Use the worksheet above on a deal you are actively working. Write what you know, identify the assumptions, and choose one missing answer to pursue with the customer. The result should make your next conversation more specific.

If you want to work through it together, book a Signal Audit. Bring the scope, the buyer's operating problem, the evidence you have, and the decision you are trying to reach. We can examine the gaps in the path to that decision.

For a wider review, the Hardware GTM Diagnostic looks across the buyer, business case, pilot, pipeline, and team. The consulting overview explains how that work fits into an engagement.

Before you add another page to the deck, try the three sentences again. Which one can your buyer now complete with confidence, and which one still requires a conversation?