Quick answer: A customer pilot can contain genuine technical experimentation, but putting a prototype into a customer's hands does not make the whole pilot R&D. Technical uncertainty may arise where the deployment is deliberately testing an outcome that cannot be known or determined in advance by a competent professional on the basis of current knowledge, information or experience. Feedback about whether customers like, buy or prefer the product is different: market research, market testing or market development, and sales promotion including consumer surveys, are specifically excluded from being core R&D activities under the current R&DTI rules. business.gov.au
A customer pilot can contain several different activities
Commercial pilots are attractive because they answer several questions at once.
Will the technology operate outside the development environment?
Can it tolerate real workloads?
Will the customer's existing systems interfere with it?
Will users actually adopt it?
Does the customer value the result enough to pay for it?
Those questions may all matter to the business, but they are not the same kind of uncertainty.
Consider a software company placing an early optimisation system with a pilot customer.
The engineering team may genuinely not know whether the system can maintain the required performance when exposed to the customer's unusually variable data, integration constraints and operating conditions.
That is a technical question.
At the same time, the commercial team may want to know whether staff find the interface intuitive, which features customers prefer and whether the product should be sold under one pricing model or another.
Those are commercial or market questions.
The distinction matters because the Australian Government expressly excludes market research, market testing, market development and sales promotion, including consumer surveys, from being core R&D activities. The same guidance recognises that an excluded activity may in some circumstances be considered as a supporting R&D activity where it is directly related to a core R&D activity and, where required, undertaken for the dominant purpose of supporting it. business.gov.au
The useful approach is therefore not to ask:
“Is this customer pilot R&D?”
Ask instead:
“What activities are actually occurring inside this pilot, and what question is each activity intended to answer?”
A single pilot may contain experimental testing, ordinary deployment, customer training, debugging, sales discussions, market research and technical data collection.
Those activities should not be treated as interchangeable simply because they occur during the same project.
Define the technical question before the customer starts using it
The strongest customer-based experiments begin before deployment.
Suppose a company has developed a new software architecture and believes it can maintain acceptable response behaviour under a workload pattern that existing approaches struggle to handle.
The pilot should not merely state:
“Deploy to Customer A and see how it performs.”
That describes an activity, not a research question.
A more useful structure identifies the unresolved technical relationship.
For example:
Can the proposed architecture maintain the required system behaviour under the customer's observed workload variability without the instability seen in the existing approach?
The team can then define the experimental conditions, observations and comparisons required to investigate that question.
Australian Government guidance requires a core R&D activity to involve an outcome that cannot be known or determined in advance on the basis of current knowledge, information or experience, but can only be determined through a systematic progression of work based on principles of established science, proceeding from hypothesis to experiment, observation and evaluation and leading to logical conclusions. The activity must also be conducted for the purpose of generating new knowledge. Routine implementation, standard engineering or simply trying available configurations is not enough merely because the result was uncertain to the particular company. business.gov.au
This becomes particularly important at a customer site because normal service delivery can easily blur into experimentation.
A system outage may require a routine bug fix.
A configuration change may be ordinary commissioning.
A user request may produce a product feature.
An experiment, by contrast, should remain connected to the unresolved technical question.
The commercial setting does not prevent research from occurring.
But it does not remove the need for experimental logic either.
The same principle applies beyond software.
A materials company may provide prototype panels to a customer because the real installation environment exposes the product to conditions that cannot be reproduced adequately in the workshop.
A manufacturer may trial a new process component on a customer's line because interaction with the customer's feedstock is the unresolved technical variable.
A sensing company may deploy equipment into a live facility because the uncertainty concerns signal behaviour under real interference conditions.
In each case, the customer site can serve as the experimental environment where the deployment is deliberately structured to test the unresolved technical question.
The customer relationship itself is not the experiment.
Separate technical evidence from customer feedback
Once the pilot begins, two evidence streams often become mixed together.
The first is technical.
It may include sensor readings, system logs, error behaviour, latency, material performance, reliability observations, operating conditions or measured deviations from a reference configuration.
The second is commercial.
It may include satisfaction scores, feature requests, buying preferences, pricing feedback, adoption behaviour or opinions about usability.
Both may be valuable.
They should not automatically be interpreted in the same way.
Suppose users report that a prototype is “too slow”.
That statement is useful operational information, but it does not yet establish the technical mechanism responsible for the observed behaviour.
The research team may need to compare workload, network conditions, processing stages and system logs before it can identify the actual technical effect.
Likewise, if users strongly prefer a new interface, that does not transform interface preference testing into a technical experiment.
The government's software-sector guidance places the emphasis on the technical hurdle, why existing knowledge or methods could not resolve it, the proposed hypothesis-led approach, what was tested, what data was collected and what conclusions followed. business.gov.au
This suggests a practical documentation rule for customer pilots:
Do not let the customer feedback file become the experimental record.
Maintain a technical record that identifies the hypothesis, version tested, relevant environment, experimental intervention, measurements and evaluation.
Keep commercial feedback where it belongs in the product or market-development process.
The two records can inform each other without being treated as the same activity.
Decide what the pilot needs to establish before rollout
Customer pilots often become difficult to stop because success is defined after the evidence arrives.
A positive testimonial appears.
One site performs well.
The customer agrees to continue.
The project is declared successful.
But none of those facts necessarily answers the original technical question.
Before deployment, management should decide what evidence would justify the next commitment.
If the next decision is whether to fund a broader rollout, the relevant question might be whether performance remains stable across defined operating conditions.
If the next decision is whether to redesign the architecture, the pilot may need to determine which failure mechanism occurs under a particular workload.
If the decision is purely whether customers value the product, that is a commercial validation exercise rather than a technical research question.
This separation can also make the go/no-go decision clearer for a CFO.
A pilot can be commercially encouraging while technically unresolved.
It can also be technically successful while customers show little interest in buying the result.
Those are different findings.
Neither should be used to conceal the other.
Contemporaneous records are particularly important in live pilots because the environment may change while the experiment is running. Current government guidance states that records should be created at the time the activity is conducted and should show what was done, how the work was performed, when it occurred and who carried it out. Examples of records that may demonstrate the systematic progression include experimental plans, records of trial runs and test reports showing results and evaluation. business.gov.au
For a pilot customer, that may mean retaining configuration versions, deployment conditions, test windows, relevant customer-environment characteristics, technical logs, deviations from the test plan and the reasoning behind changes.
The objective is not to turn every customer interaction into research documentation.
It is to keep the technical experiment identifiable inside a much larger commercial relationship.
A useful final question is:
If the customer's name disappeared from the project record, could another competent technical person still understand what hypothesis was tested, what evidence was produced and what conclusion followed?
If the answer is yes, the pilot is much more likely to have preserved the research method rather than merely recording that a customer tried the product.
Conclusion
A customer pilot can host genuine technical experimentation without making the entire customer engagement an R&D activity.
The key is to separate the hypothesis-led technical work from deployment, customer support, market feedback and commercial validation, and to keep the technical evidence identifiable throughout the pilot.
A commercially successful pilot and a technically successful experiment are not the same finding. Good project governance should make it possible to see both clearly.
Sources & Further Reading
Australian Government — Conducting core R&D activities for the R&D Tax Incentive
Australian Government — Excluded R&D activities under the R&D Tax Incentive
Australian Government — Record keeping for the R&D Tax Incentive
Australian Government — Software development sector guide for the R&D Tax Incentive
Federal Register of Legislation — Income Tax Assessment Act 1997
Talk to Ignition Research if a prototype is about to be deployed with a pilot customer and your team needs to separate the technical experiment from ordinary implementation, customer feedback and market validation before the live trial begins. As a Registered Research Service Provider, Ignition Research assists businesses with research question definition, experimental design, technical investigations and contemporaneous supporting records within its registered research fields. business.gov.au
RSP registration confirms that the provider has met the relevant registration requirements for its registered research fields. It does not constitute government endorsement of a project or guarantee R&DTI eligibility.
We do not determine R&DTI eligibility or provide tax advice. The R&D Tax Incentive is a self-assessment program, and companies remain responsible for assessing their activities, expenditure and circumstances and obtaining appropriate tax advice.
Working on a project like this?
Tell us what you're building and the part you're not sure will work. A researcher from our Adelaide team (registered Research Service Provider RSP000047) reads every enquiry and replies within two business days. No documents needed.
