Should a space-enabled service apply for an ESA proof-of-concept study or a pilot project?

A company should choose between an ESA proof-of-concept study and a pilot project by identifying what remains uncertain about the service. If the concept and market opportunity still need validation, the work differs from testing an integrated offering with customers in its primary market.

ESA's current BASS open-call page makes that distinction. Proof-of-concept studies develop the service concept, engage users and work toward a minimum viable product. Pilot projects integrate, develop and test the application with primary-market customers. The page also limits participation to the relevant subscribing or participating states and directs applicants to esa-star for authoritative conditions. ESA proof-of-concept and pilot call The ESA BASS proposal template review identifies the applicable application documents before a team prepares its submission.

For a civilian environmental reporting service, a proof-of-concept question might concern whether the proposed information helps a customer make a useful decision. The company may need to explore the report format, update frequency and willingness to pay. These are fundamental service-design questions, even if the underlying data processing already works.

A pilot assumes a more developed proposition. The company should be able to explain what will be integrated, which customer workflow will be evaluated and what evidence would support continued use. A demonstration shown to an audience is not equivalent to sustained customer evaluation of a service.

Avoid using technical maturity as the only stage indicator. A sophisticated algorithm may still lack a clear buyer. Conversely, a relatively simple technical approach may support a well-understood service with engaged customers. The proposal should describe both the technical and commercial uncertainties.

Customer participation needs a realistic commitment. Clarify what the customer will provide, who will review the result and what information can be shared. An expression of interest may be a useful starting point, but the project plan should not rely on unconfirmed staff time or data access.

Define the evidence needed at the end of the activity. For concept work, that might be a validated service design and a decision about the first market. For a pilot, it might be a documented evaluation, an identified integration burden and a clearer commercial offer. These outputs should guide the work plan. Expansion through an ESA Growth Project also requires a commercial case for the next customer segment.

The company should also prepare for an outcome that challenges its original assumption. If users do not value the service as expected, the project should still produce information that supports a decision. A proposal framed only around confirming success can miss the value of disciplined learning.

Co-funding, eligibility and application requirements need separate review. The activity label does not establish the company's funding percentage or guarantee acceptance. The relevant delegation and official tender documents determine the conditions for the actual proposal. The ESA BASS co-funding and cash requirement comparison distinguishes an eligible-cost percentage from the company's full cash requirement.

Choose the decision that the activity must unlock

The distinction between a proof of concept and a pilot becomes clearer when the company writes down the decision it cannot yet make. It may not know whether customers value the proposed result, whether the service can be delivered at an acceptable cost or whether an existing prototype fits the customer's workflow. Those uncertainties require different evidence and should not be bundled into one impressive-sounding demonstration.

ESA's current call description connects concept work with reducing uncertainty around the service and market, while pilot work places the offering with customers in its primary market. The distinction is commercial as well as technical. A mature component can still belong inside an uncertain business proposition, while an early service may already have a well-defined customer problem.

Consider a hypothetical company producing satellite-enabled reports about civilian infrastructure maintenance. Its initial uncertainty might be whether maintenance planners can use the report to decide which assets require a closer inspection. The concept activity could examine the report's usefulness, the customer's existing decision process and the cost of producing a repeatable output. Building a complete subscription platform before those questions are answered might add expense without reducing the most important risk.

A pilot becomes a different proposition once the intended users, report and commercial workflow are sufficiently defined. The company would then need access to the customer's real working process, a way to evaluate the service over an appropriate period and agreement on who reviews the result. The proposed activity should make clear what has already been established so that the pilot does not quietly become an open-ended search for a market.

Give customer involvement a specific job

Customer involvement is more useful when it has a defined purpose. A participant might explain the current process, supply feedback on an output, provide staff for an evaluation or assess a commercial offer. These contributions are different, and a general endorsement does not establish that the necessary people or resources will be available.

The company should identify the role that owns the problem and the role that could authorise a purchase. They may sit in different parts of the organisation. A user can provide excellent practical feedback while having no responsibility for budget. A procurement colleague can explain purchasing constraints without being able to validate whether the product solves the user's problem.

In the hypothetical maintenance example, the evaluation could compare the proposed report with the customer's existing planning material. The company would need to know which decisions the report is expected to inform, how ambiguous results will be handled and whether the evaluation creates extra work for the customer's staff. Those questions concern a civilian business process; they do not require claims about unexamined operational performance.

Agree the treatment of an unsuccessful result as well. An evaluation might show that the customer needs information more frequently than the service can economically provide. That finding can justify changing the product or choosing another customer segment. It should not be concealed behind a broad statement that the demonstration was completed successfully.

Budget for learning and for integration separately

Concept uncertainty and integration effort can consume similar amounts of engineering time while producing different outputs. The first changes what the company believes about its business. The second changes how a defined offering works inside a customer's environment. Separating them helps explain the budget and the staff required.

Suppose a hypothetical project allocates one team to investigating customer demand and another to building an interface before the demand work is complete. If the customer segment changes, part of the interface work may become unnecessary. A staged work plan can identify which development tasks are useful under several plausible outcomes and which should wait for a clearer decision.

For a pilot, the corresponding issue is the work that follows the initial connection. Documentation, user preparation, support and handling exceptions can determine whether the customer experiences a usable service. Omitting those costs can make the proposed pilot look inexpensive while leaving the evaluation dependent on unplanned staff effort.

The resulting proposal should connect each work package with the uncertainty it resolves or the integration responsibility it completes. That gives the company a more useful completion standard than a single final presentation. It also makes the next commercial step easier to explain: continue development, refine the first-market offer, pursue a customer purchase or stop work that no longer supports the business case.

The commercial choice is therefore about the next credible step in adoption. Select the route that matches what the company can demonstrate now and what it genuinely needs to learn. That produces a more coherent project than choosing a pilot label before the service concept and customer relationship are ready.