Brand identity proposal template

Break the assignment into stages with a purpose, a deliverable, and an approval point. Discovery gathers context; direction establishes the approach; development turns that approach into usable assets; documentation explains how to apply them. Adapt those stages to the engagement rather than suggesting that every business needs the same package.

Record what is excluded from each phase. Brand naming, research recruitment, campaign copy, photography, and website development may need separate expertise or another proposal. Explain when a completed phase is considered approved and how returning to it affects the work. Clear phase boundaries let the client make decisions while they are still useful, instead of reopening foundational questions during final file preparation.

Describe what the workshop is intended to establish and what participants must bring. Ask for existing positioning material, relevant business context, customer knowledge, and the constraints the identity must address. Identify the people who should attend because they can approve decisions, not simply everyone who would like to give an opinion.

Specify the record the client receives afterward, such as a design brief or a summary of agreed priorities. Distinguish facilitating a discussion from conducting original market research. Explain how missing information will be handled and whether unresolved strategy questions require another engagement. A workshop should produce an agreed basis for the design work, not a promise that every competing stakeholder preference will become part of the finished identity.

Explain what a moodboard represents: a proposed visual approach, not a collection of assets ready for the client's commercial use. Discuss the role of reference imagery, type, color, composition, and context. Label third-party references appropriately so nobody mistakes them for original commissioned materials or assumes the client receives rights to reproduce them.

Set expectations for how a direction is chosen and refined. Ask the client to evaluate the relationship to the agreed brief rather than request a collage of every board. Clarify whether another direction is included when the presentation reveals a changed strategic requirement. Save the approved direction and its rationale as a reference for later decisions. It should help the parties judge development work without requiring the client to remember an unrecorded conversation.

Describe the components as a system: logo configurations, color definitions, typography choices, supporting graphics, and agreed applications. List which application files are editable and which are examples for guidance. Identify the platforms or production settings those assets must serve, and confirm whether the client's team can use the software needed for the supplied templates.

Explain licensing dependencies such as typefaces, photography, or illustration commissioned from another creator. State who acquires the licenses and which costs require approval. Distinguish designing a packaging appearance from preparing every production variation, or showing a website concept from building the website. A precise asset list is not an attempt to restrict useful design; it gives the client a dependable handoff and a sensible way to request further work.

Define the guide by the decisions it documents, not merely by its length. It may explain logo use, color specifications, typography, layout principles, imagery, and examples of inappropriate application. Identify the people who will rely on it, because an internal marketing team and an outside supplier may need different levels of practical instruction.

State whether training, consultation, or later updates are included. The guide should correspond to the assets actually delivered, rather than describe a system that has not been built. Clarify whether editable source documents form part of the handoff. Ask the client to check factual information such as business naming and contact details before approval. Treat the document as working guidance for consistent decisions, not a claim that the brand will perform in a particular commercial way.

Present options by describing what becomes possible with each scope. An essential system might address immediate launch needs, while a broader engagement may include more applications or team support. Explain differences in service, deliverables, and dependencies without implying that choosing the smaller scope makes a client less serious about their business.

Quote your own project-specific fees in the actual proposal; do not treat example packages as market benchmarks. Show which options are alternatives and which can be added later. Record exclusions beside the inclusions so an attractive package name does not hide unfinished assumptions. Before sending, check that the client can compare the options using the same approval process and clearly understand what changes when the scope changes.