Free naming brief
Business naming brief template with a worked example
A naming brief is a short agreement about what your business name needs to do. Write it before collecting ideas so your team evaluates the same problem. Use the blank template below, then compare it with the fictional example. The download is free and does not require an account.
By Esmii · Practical resources for your naming process
Free download. No sign-up required.
What belongs in a business naming brief?
Keep the brief short enough to read at the start of a naming meeting. Separate requirements that can rule a name out from preferences you can trade off. “Easy to spell when spoken in our sales calls” is testable; “a perfect name everyone loves” is not.
Start with the business as it exists, then identify a realistic expansion you want the name to accommodate. A name does not need to explain every future service. It does need to avoid an obvious limitation you already know matters.
- Audience: who needs to understand and remember the name?
- Offer: what do you help that audience do?
- Positioning: why would someone choose this business over an alternative?
- Tone: choose a few characteristics and explain what each means.
- Scope: which products, locations and languages must the name fit?
- Requirements: list practical constraints separately from nice-to-haves.
- Decision: name the decision owner, contributors and review date.
Copy this naming brief template
Complete the prompts independently first if your co-founders have different views. Compare answers before brainstorming. An unresolved audience or offer is a business question; generating more names will not settle it.
- Our business helps [audience] achieve [outcome] through [offer].
- Customers should associate the name with [characteristics], because [reason].
- The name should not suggest [misleading meaning or unwanted category].
- It must work when [spoken, written or other real customer situation].
- Our launch markets and languages are [list].
- The near-term expansion it should allow is [scope].
- Our must-have requirements are [testable constraints].
- Our preferences, which we can trade off, are [list].
- We will investigate [specific uncertainty] by [method and owner].
- [Decision owner] will decide with input from [contributors] on [review date].
Worked example: a fictional repair business
Imagine a business that repairs household appliances for people living in apartments. Its customers arrange visits by phone and text. It starts in one city and may expand to nearby cities. This is an illustrative brief, not a customer case study or research finding.
Audience and offer: renters and homeowners who need a dependable repair appointment without a complicated booking process. Tone: calm means reassuring, not sleepy; capable means clear and practical, not technical jargon. Avoid a name that sounds like an appliance retailer.
Requirements: listeners should be able to repeat and spell the name during a phone booking. The name must not contain the launch city because nearby locations are planned. The team will review language associations with relevant speakers. A preferred domain spelling is a preference until the team explicitly makes it a requirement.
Decision process: each founder proposes candidates independently. One founder organizes language and spelling observations; another records domain research. The founders review the same shortlist and assign unresolved checks before deciding. Research results remain separate from personal preferences.
Turn the brief into comparison criteria
Translate each requirement into an observation you can record. For the repair example, say a candidate once and ask the listener how they would spell it. Ask what kind of business they expect before explaining the offer. Record the answer rather than changing it into a vague “brand fit” score.
A broad name might allow expansion but explain less at first glance. A descriptive name might be immediately clear but tie you to one service. Write down the trade-off and decide which matters for this business. Do not quietly change the criteria to protect a favorite.
When to revise the brief
Revise it when you learn something that changes the audience, offer or a real requirement. Keep the previous version and note why it changed. Reassess every finalist against the revised brief so one candidate does not receive a special exception.
In Esmii, create a project for the shortlist and use custom checks for the criteria your team agrees on. Record candidate-specific observations in notes and keep team responses separate from checks. The downloaded brief is a standalone document; Esmii does not import it automatically.