Your SBIR/STTR Letter of Support

Your SBIR/STTR Letter of Support

Your TL;DR: A strong SBIR/STTR letter of support should fit on one page, appear on the supporting organization’s letterhead, include a date and signature, and provide specific evidence that strengthens your proposal. The best letters confirm a real need, relationship, resource, role, access point, or commercialization pathway. Generic praise about your company or technology may sound supportive, but it gives reviewers very little they can use.

Your SBIR/STTR Letter of Support Should Prove Something

A letter of support should not read like someone was asked to say nice things about your company.

Yet that is exactly what many SBIR/STTR applicants collect. The letter describes the company as innovative, calls the technology exciting, praises the founders, and closes with enthusiastic support for the application. Everyone involved has been complimentary. Very little has actually been established.

Reviewers do not need another person telling them your technology is promising. They are already reading your proposal to determine that for themselves. A useful letter gives them information they cannot get from your own assertions alone. It confirms that an outside organization, customer, collaborator, research partner, pilot site, or other relevant stakeholder has a real connection to something you are proposing.

EBHC advises applicants to approach letters of support with a simple question: What does this letter prove? If you cannot answer that in a sentence, the letter probably needs more work.

As you review the letters you plan to include, try identifying the exact proposal claim each one independently supports.

Keep the Letter to One Page

A strong letter of support does not need to be long. In most cases, it should be contained to one page and written on the supporting organization’s official letterhead, with a date and a signature from the individual providing the support.

Those basics matter. A letter on organizational letterhead, addressed appropriately, dated, and signed, reads as a deliberate communication from an identifiable stakeholder. An unsigned document that looks like proposal copy-pasted into a template does not carry the same weight.

One page also forces discipline. The writer does not need to summarize your entire company history, explain every feature of the technology, or repeat the technical aims. They need enough context to establish who they are, how they know the company or proposed technology, what they can credibly confirm, and why that information matters to the proposed project.

The GAP appears when applicants use that limited page for praise instead of evidence. A letter may say the technology is groundbreaking, the team is exceptional, and the project deserves funding, while never confirming the customer problem, access to a pilot environment, a collaborator’s role, or a realistic path toward adoption. The applicant has obtained a letter, yet the reviewer has learned almost nothing new.

What Should Actually Be in an SBIR/STTR Letter of Support?

The content will vary depending on who is writing the letter and why that person matters to the proposal. A prospective customer should not sound like a research collaborator, and a pilot site should not be asked to make claims about a commercialization strategy it is not positioned to make.

Still, most useful letters establish several basic things clearly:

  • Who the writer is. Their name, title, organization, and relevant relationship to the problem, market, research, or proposed project.
  • How do they know the applicant or the technology? The letter should provide enough context for the reviewer to understand whether this is an established relationship, a prospective customer conversation, an active collaboration, or another legitimate connection.
  • What problem or need can they confirm? When relevant, the writer can describe the operational, technical, clinical, commercial, or organizational problem from their own perspective.
  • Why is the proposed technology relevant? This should be grounded in the writer’s environment or expertise rather than broad praise.
  • What are they actually willing to do? This may include participating in research, providing expertise, supporting validation, making facilities or equipment available, facilitating appropriate access, considering a future pilot, or engaging in commercialization activities.
  • What conditions matter going forward? A prospective customer or commercialization partner may be able to identify performance expectations, validation requirements, integration considerations, purchasing criteria, or other factors that would influence future adoption.

Not every letter needs every element. Trying to squeeze all of them into one page can make the letter sound manufactured. Choose the details that substantiate the reason that a particular person or organization belongs in the proposal.

Customer Letters Should Sound Like Customers

A customer letter can be especially valuable when it confirms that the problem described in your commercialization plan exists outside your own pitch deck.

Suppose your proposal states that a particular type of organization struggles with an expensive or inefficient process. A prospective customer who works within that environment can describe the problem from firsthand experience. They might explain what they currently use, where existing approaches fall short, what consequences the problem creates, or what they would need to see before evaluating an alternative.

That is substantially more informative than:

“We are excited about this innovative technology and strongly support Company X’s SBIR application.”

The second statement is positive, but positivity is not customer discovery.

A stronger letter might establish that the organization experiences the identified problem, has discussed the proposed solution with the applicant, sees relevance to its operations, and would be interested in evaluating the technology if defined technical or validation milestones are achieved. Those details give the commercialization narrative an external point of reference without asking the writer to make a purchasing commitment they are not prepared to make.

Collaborator Letters Should Confirm the Actual Collaboration

Research and technical collaborators have a different job.

If your proposal depends on another investigator, institution, facility, consultant, or technical partner, their letter should reinforce the role described in the work plan. The reviewer should be able to move between the proposal and the letter without finding two different versions of the relationship.

A collaborator might confirm access to specialized equipment or facilities, describe technical expertise they will contribute, acknowledge their role in a particular task, or explain how their participation supports a project milestone. The level of detail should be appropriate to the actual commitment.

This is also where vague language can create unnecessary uncertainty. If your research plan makes a collaborator sound essential but their letter merely says they are “interested in the project,” the reviewer may reasonably wonder how secure that dependency is.

Pilot and Access Letters Need to Address Access

Access is one of those proposal assumptions that can look simple until somebody asks who actually gave permission.

If your SBIR/STTR project depends on a particular testing environment, user population, dataset, facility, workflow, or implementation setting, the corresponding letter should address the nature of that access as specifically as the relationship allows.

That does not mean overstating what has been approved. A conversation about a potential pilot is not a confirmed pilot. Interest in discussing access is not authorization to use data. A relationship with an organization does not automatically mean participants, facilities, records, or other resources will be available.

Strong letters are precise about the current status. That precision makes the proposal more credible because it shows that the applicant understands the difference between a future possibility and an established commitment.

Commercialization Letters Should Reveal How Adoption Could Happen

Commercialization letters can also do more than express market enthusiasm.

A strategic partner, prospective customer, distributor, manufacturer, licensee, or other market stakeholder may be positioned to confirm something important about how the technology could eventually reach the market. Depending on the relationship, that could include purchasing considerations, integration requirements, distribution capabilities, manufacturing needs, validation expectations, or criteria for moving toward a deeper commercial relationship.

The letter does not need to promise a sale.

In fact, an implausibly strong purchasing commitment at an early stage can raise its own questions. A credible letter reflects where the relationship actually stands. Reviewers benefit from seeing that the applicant has begun learning what must happen between “the technology works” and “someone pays for it.”

If your commercialization letters currently say little beyond “we would be interested in this product,” consider whether the writer could instead explain what would need to be true for that interest to progress.

Do Not Write the Same Letter Five Times

Another common problem appears when every letter in the application follows essentially the same template.

The customer praises the technology. The university collaborator praises the technology. The pilot organization praises the technology. The commercialization partner praises the technology. After four letters, the reviewer has four versions of the same endorsement and still may not know whether the applicant has customers, resources, access, or a credible commercialization relationship.

Each letter should have a distinct purpose.

A customer may validate need. A collaborator may establish research capacity. A pilot partner may substantiate access. A commercialization relationship may provide evidence about market entry or adoption. Collectively, the letters can reinforce different parts of the proposal rather than creating a stack of repetitive endorsements.

This is why EBHC generally recommends deciding what you need a letter to establish before asking someone to write it.

Give the Writer Enough Direction to Be Useful

Even strong partners can produce weak letters when applicants send an email that essentially says, “Could you write us a letter of support?”

Most people do not spend their days reading SBIR/STTR applications. They may have no idea what reviewers need from their letter. Left without guidance, they understandably default to a professional recommendation letter: how they know you, why they think your work is impressive, and why they hope you receive the award.

Give them better direction.

Explain the project briefly, why their perspective is relevant, and what part of the proposal their letter can substantiate. Remind them of any specific discussions, resources, responsibilities, or next steps that accurately reflect the relationship. Providing a suggested structure or draft can also reduce the burden on a busy partner, provided the final language accurately represents what that individual is willing to state.

Never turn that convenience into manufactured evidence. The person signing the letter needs to be able to stand behind every commitment and representation made under their name.

Before You Submit, Give Every Letter a Five-Minute Review

Letters of support often arrive close to the deadline, which makes them easy to upload without much review. Take the extra few minutes.

Confirm that the letter fits on one page, uses the organization’s letterhead, includes a date and signature, identifies the writer and organization clearly, and accurately reflects the relationship described elsewhere in the proposal. Then read it once more with a different question in mind: What did I learn from this letter that makes the proposal more credible?

If the answer is simply that the writer likes your company, you have a cheerleading letter.

If the answer is that a customer confirmed the problem, a collaborator confirmed their role, a partner confirmed access, or a commercialization stakeholder explained what would move the technology closer to adoption, the letter is doing useful work.

Your SBIR/STTR proposal already has plenty of places for you to make the case for your technology. Use letters of support for something more valuable: giving reviewers independent evidence that parts of the execution and commercialization story extend beyond the applicant’s own claims.