Brand Voice Guidelines — Webility

Document ID: WBL-INT-BVG-v1.0 Classification: Internal — All Team Members Version: 1.0 Effective Date: [DATE] Owner: [Account Director / Creative Lead]

Purpose: This document defines how Webility communicates — in writing and in speech. It applies to every channel: proposals, client emails, website copy, social media, case studies, and internal communications that clients see.

A strong, consistent voice is a trust signal. When every touchpoint sounds like the same confident, honest team — clients believe it. When communication is inconsistent, it creates doubt.

1. Who We Are (The Foundation)

Before voice, there's character. Our voice comes from who we are:

We are experts, not vendors. We know digital deeply. We have opinions. We share them respectfully, but we don't hide behind vague language to avoid taking a position.

We are honest over comfortable. We'd rather tell a client something is not working than let a bad project continue. We don't use jargon to sound smart — we use clear language to be understood.

We are partners, not service providers. We care about our clients' outcomes, not just task completion. Our communication reflects that investment.

We are calm and capable. We don't panic in front of clients, we don't oversell, and we don't undersell. We're confident because we've done this before — and the work shows it.

2. Brand Voice Attributes

2.1 The Core Four

2.2 Voice Spectrum by Context

Our voice adjusts to the context — confident professionals do this naturally. Formal doesn't mean lifeless; casual doesn't mean sloppy.

3. Writing Principles

3.1 Lead with the Point

Never bury what matters. Start with the most important thing — then support it.

❌ "After a comprehensive review of the requirements and a thorough analysis of several viable approaches, taking into account your technical environment and budget constraints, we have arrived at a recommendation..."

✅ "We recommend Next.js hosted on Vercel. Here's why:"

3.2 Cut Ruthlessly

If a word doesn't add meaning, remove it. Long sentences are usually two short sentences with unnecessary connectors.

Filler phrases to eliminate:

3.3 Be Specific, Not Vague

Specificity is a trust signal. Vagueness is a risk signal.

❌ "We have extensive experience with projects like yours and have delivered strong results for many clients."

✅ "We've built [X] e-commerce sites over [X] years, including two with similar Shopify + ERP integration requirements. Our average mobile Lighthouse score at launch is [X]."

3.4 Active Voice Over Passive

❌ "The proposal has been sent for your review." ✅ "I've sent the proposal. Take as long as you need, but we'd love to hear your thoughts by [date]."

❌ "The site will be tested by our QA team." ✅ "Our QA team will test the site."

3.5 Contractions Are Fine

We use contractions in conversational writing. They make us sound human, not sloppy.

✅ "We've delivered this, we're proud of it, and we think you'll love it." ❌ "We have delivered this, we are proud of it, and we believe you will love it." (stiff; reads like a legal document)

Exception: Contracts, formal legal documents, and regulatory communications should avoid contractions.

3.6 Humor — Use Sparingly and Contextually

Humor is appropriate when:

• It's a casual channel (Slack, informal email)
• It's self-deprecating, not at the client's expense
• The context is clearly lighthearted
• You know the person well enough

Humor is not appropriate when:

• Delivering bad news
• Discussing legal, contractual, or financial matters
• You haven't built a rapport with this specific person
• The client is in a high-stress moment

3.7 Empathy Without Over-Apologizing

Acknowledge difficulty without drowning in it.

❌ "I am so incredibly sorry for this terrible mistake and the inconvenience it may have caused. We feel awful about this situation and completely understand if you are frustrated."

✅ "I understand this delay is frustrating — it affected your timeline and that matters. Here's what happened, here's what we've done to fix it, and here's what we're changing so it doesn't happen again."

4. Words We Use and Words We Avoid

4.1 Webility Language

Words and phrases that sound like us:

• "Here's our recommendation — and here's why"
• "Let's be direct"
• "We built [X] — here's what that means for you"
• "We flagged this early because we'd rather deal with it now than later"
• "The honest answer is..."
• "We've done this before, and we know [specific thing]"

Words that are off-brand:

4.2 Technical Writing

When writing about technical things:

• Define terms the first time, then use them consistently
• Don't condescend: don't over-explain basics to technical audiences; don't assume knowledge from non-technical ones
• Write for the actual reader — a proposal section about security should be written for the CISO, not the CEO; a proposal's executive summary is written for the CEO, not the CISO

5. Channel-Specific Guidelines

5.1 Proposals

Structure comes first. Proposals should be skimmable — a reader who only reads the headings should understand the structure of what's being proposed.

The opener is not about us. The first substantive section of every proposal is about the client's situation, challenge, or opportunity. We come second.

Recommendations are explicit. We don't present "options A, B, and C" and say "the choice is yours." We present our recommendation and explain why. We may include alternatives with rationale for why we didn't choose them.

Exclusions table is mandatory. Every proposal must include an explicit list of what is not included. This prevents misaligned expectations that become contractual disputes.

Avoid proposal templates that look like templates. Replace all placeholder language with content specific to this client. Never submit a proposal with "[CLIENT NAME]" in the wrong field.

5.2 Client Emails

Subject lines: Be specific. "Following up" is not a subject. "Webility | [Project] — Design review feedback requested" is.

One email, one ask. Don't combine multiple asks in a single email if they require separate decisions. Clients miss things in walls of text.

No walls of text. If an email is longer than [250] words, restructure it. Use bullet points. Use a numbered list if there are sequential actions. Consider whether it should be a meeting instead.

End with a clear next step. Every email that requires a response should end with a specific, explicit ask: "Could you confirm by [date] whether you'd like to proceed with Option 1 or Option 2?" Not: "Let me know what you think."

5.3 Deliverable Submissions

Every deliverable submission should include a brief cover note with:

1. What you're submitting (what it is and what phase it represents)
2. Key decisions made and brief rationale (don't make the client guess why things are the way they are)
3. What you'd like them to review specifically
4. Any open questions you need them to answer
5. The review deadline and what "approved" means (it means work advances to next phase)

Template:

Hi [Name],

Attached is [deliverable name] for [Project] — [Phase X] of [X].

What to review: [2–3 sentences on key decisions + specific areas you'd like feedback on]

Open questions: [Any decisions you need the client to make]

Review deadline: [DATE] — feedback by this date keeps us on track for [next milestone date]. If we don't hear back by [DATE], we'll consider this approved and advance to [next phase].

[Name]

5.4 Website Copy

Webility's own website copy follows these rules:

• Headlines are punchy and benefit-led, not feature-led
• First sentence of every section earns the second
• "You" appears more than "we" — write for the reader's situation
• No stock language: "we help businesses achieve their goals" says nothing
• Proof points before claims: "40% more leads. 30% faster site. Zero rebuild-every-2-years cycles."
• CTAs are specific: "See how we work" not "Learn more"

5.5 LinkedIn and Social Media

What we post about:

• Work we're genuinely proud of (with client permission)
• Insights and opinions on digital, AI, or web industry topics
• Behind-the-scenes of how we approach problems
• Results and data (with permission; anonymized if needed)
• Honest takes on industry trends — including contrarian views when we hold them

What we do not post:

• "Excited to announce..." (just announce it)
• "Thrilled and honored to be working with..." (just say what you're doing)
• Engagement bait ("Comment below if you agree!")
• Promotion disguised as advice
• Political opinions or anything that could alienate clients

Post format guidance:

• Hook in the first line — what makes someone stop scrolling?
• No more than 3–4 sentences per paragraph
• End with a clear point or an honest question (not manufactured engagement bait)
• Images and videos always outperform text-only

6. Common Situations — Guidance

Delivering Bad News

Be direct, be fast, and come with a plan.

Structure:

1. State the issue clearly — no softening that obscures the actual problem
2. Explain what caused it (briefly; don't make it an excuse)
3. State the impact (on timeline, cost, quality)
4. State your solution or options
5. Ask for the conversation (don't just dump this in email if it's serious)

✅ "There's an issue I want to flag immediately. [Specific problem]. It happened because [cause]. The impact is [X]. Here's what we propose to resolve it: [options]. I'd like to talk through this — are you free for a call today?"

Saying No to a Client Request

Acknowledge, redirect, don't apologize excessively.

✅ "That's not in the current scope — if you'd like to add it, we'd quote it as a Change Order. It would be [X] and take [Y]. Want me to prepare that?"

Following Up on Overdue Feedback

Be direct, not passive-aggressive.

✅ "Just checking in — we haven't received feedback on the [deliverable] submitted [X] business days ago. We need it by [DATE] to stay on track for your [next milestone]. Can you confirm when we can expect it, or let me know if there's a blocker?"

Webility — WBL-INT-BVG-v1.0 | Brand Voice Guidelines Internal document — not for client distribution.