Content

1. Voice and tone

Voice

Copy is direct, calm, helpful, and human. It is not chatty, apologetic, self-promotional, or passive.

Referring to people

Use the specific term, never "user":

• Profile — a workspace's end customers (the people in the audience; the data model). "This profile is opted out of email."
• Member — a person who uses the Customer.io product (a teammate or seat in an account). "Invite a member."
• Person / people — generic references where neither profile nor member is specific. "This message will send to 4,200 people."

"user" may remain only as a raw data-model field name in code — never in UI copy.

Pronouns

Use "you" and "your" to address the person directly. Don't mix "my" and "your" on the same screen. Pick one and use it consistently throughout a flow. Remove possessives when they add no meaning.

Don't start a sentence with "this" or "that" unless the noun immediately follows. It's ambiguous in context and harder to parse.

Tone

Tone adjusts to what the person is experiencing. A person completing their first setup flow needs reassurance. A person facing a destructive action needs precision.

---

2. Capitalization

Use sentence case everywhere (capitalize the first word and proper nouns only). That includes: headings, labels, buttons, tooltips, placeholder text, empty states, error messages, nav items, column headers.

When in doubt, use sentence case. Title case in labels creates inconsistency and adds visual noise: it's harder to scan, harder to localize, and creates a second capitalization system that readers have to learn.

Proper nouns

Always capitalize proper nouns: Customer.io, Liquid (the templating language), and established product, feature, plan, and program names. Keep their capitalization everywhere, including mid-sentence. Examples:

• Customer.io
• Liquid
• Global Styles, Premium, Premium Integrations
• Startup Program, Customer.io Academy
• Community (the Customer.io Community forum, a named surface like Academy)
• AMP (and "AMP for email")
• Slack Agent (a surface-qualified name for the Agent)

Common nouns are not proper nouns and stay lowercase mid-sentence: segment, campaign, broadcast, message, profile, member, automations. Field and preposition words are lowercase too — from address, reply to address, to, from — capitalized only when they start a label (e.g. "From address" as a field label, but "Add a from address" mid-sentence). When a term names a specific product surface, it's a proper noun; when it's a generic concept, it's lowercase.

Product-area and feature names are proper nouns

Sentence case is the default. Beyond Customer.io, product-area and feature names are proper nouns: capitalize them when you're naming the feature or area; use lowercase for the common adjective/noun form. The same word can go either way depending on how it's used — the rule is contextual, not a fixed always-capitalize list.

Rule of thumb: naming the feature or area → capitalize; describing the thing generically → lowercase.

Special cases: the branded phrases with no common-noun form are always fully capitalized — Data Pipelines and Design Studio — as is Customer.io. Every other multi-word area is sentence case (Data index, Email layouts, Inbox preview, Message library, Custom objects).

Product areas that follow this contextual rule (capitalize when naming the feature/area, lowercase as a common noun):

Assets · Broadcasts · Campaigns · Collections · Custom objects · Data index · Data Pipelines (always) · Deliveries · Design Studio (always) · Destinations · Email layouts · Exports · Geofences · Goals · Imports · In-App · Inbox preview · Integrations · Journeys · Message library · Newsletters · Reports · Segments · Snippets · Sources · Transactional · Workspaces

---

3. Punctuation

Periods

Use periods for full, complete sentences. Do not use periods for standalone labels, button text, short and incomplete phrases, nav items, column headers, modal titles, etc. Periods for labels signal that something requires comprehension rather than a quick scan.

Question marks

Question marks are used to seek confirmation from the user for an action that will be performed. They typically denote destructive actions where informing the user helps prevent errors but may be used in other cases such as when asking for feedback.

Exclamation points

Reserve exclamation points for genuine milestones and warm moments — a welcome, a thank-you, a standout positive result — to preserve impact. Don't use them for routine confirmations (like a save) or in errors and warnings. Use at most one per screen.

Ellipses

Ellipses indicate that something is in progress or that more input is needed. There are two valid uses:

Loading and progress states

Use an ellipsis after present participles in loading and progress messages.

Buttons that require additional input

Use an ellipsis (…) when a button opens a dialog or requires additional input before the action completes. It signals "there's more to do before this happens" and removes hesitation from people who aren't sure what will be affected.

Do not use a trailing ellipsis anywhere else in UI text. Placeholders in particular never take one — the field itself is the input, so write "Search", not "Search…".

One ellipsis character

Always use the single ellipsis character (…), never three periods (...). Three periods look like AI-generated filler and don't render as a true ellipsis.

Em dashes and en dashes

Do not use em dashes (—). Em dashes have become strongly associated with AI-generated text and add visual noise in dense interfaces. Restructure the sentence or use a comma instead.

Use an en dash (–) for ranges.

Colons

Use colons to introduce a list or label-value pair. Do not add a space before the colon. Omit the colon when the label and value are visually separated by layout.

Ampersands

Use ampersands (&) in established product names ("Data & Integrations") and in space-constrained UI — labels, tabs, panel titles, nav items, table headers, and tags ("Preview & testing", "Tips & resources"). Write and in prose and full sentences.

Parentheses

Use parentheses to define an acronym or term on first use, and for short qualifiers or scoping ("Forced dark (Outlook)", "(No subject)"). Do not use them for asides or extra thoughts — restructure the sentence instead.

Oxford comma

Always use an oxford comma in lists of three or more.

---

4. Numbers, time, and dates

Numbers

• Use Arabic numerals always, including at the start of a sentence: 4,200 people not Four thousand two hundred people
• Format with commas: 1,200 not 1200
• Abbreviate when space is constrained, consistently within a view: 1.2K, 4.8M

Time

• 12-hour format, lowercase am/pm: 10:30 am, 4:00 pm
• Include time zone whenever relevant: 10:30 am ET
• Use an en dash for time ranges: 9:00 am–5:00 pm

Dates

• Default: July 28, 2025
• Dense data tables only: MM/DD/YYYY

Relative time

Use relative time for timestamps and activity feeds. Use the appropriate unit once it reaches its threshold. Use 1 hour ago instead of 60 minutes ago.

Elapsed time:

• Just now
• 1 minute ago
• X minutes ago
• 1 hour ago
• X hours ago
• 1 day ago
• X days ago
• 1 month ago
• X months ago
• 1 year ago

Remaining time:

• X hours remaining
• X minutes remaining
• X seconds remaining
• About X minutes remaining (use "about" for estimates)

---

5. Buttons and action labels

Rules

• Start with a verb.
• Keep it short and succinct: 1–3 words.
• Be specific enough that the button is self-explanatory without surrounding context.
• Prefer "Cancel" for a plain dismiss, but a specific dismiss verb is better when it clarifies what staying or leaving does ("Keep my account", "Go back"). Never "No", "Never mind", or "Close".
• Use an ellipsis (…) when a button opens a dialog or requires additional input before the action completes (see Ellipses for full details).

Generic verbs like "Submit", "Confirm", and "OK" require people to hold surrounding context to understand what will happen. Specific verbs like "Delete campaign" and "Send newsletter" let people act with confidence. This matters most for destructive actions, where a vague label can have significant consequences.

When using the word "Yes" within a label, pair it with the action that will take place to improve clarity.

Types

---

6. Onboarding

• Lead with the task, not background information.
• One instruction per step.
• Always show progress (step X of Y or equivalent).
• Confirm completion explicitly. Say what was set up and what the person can do now.

---

7. Errors and system feedback

Error states are high-anxiety moments. Vague errors ("Something went wrong") make people feel helpless. Blame-framed errors ("You entered an invalid value") create frustration. A good error message turns a moment of friction into a moment of guidance. It is often the difference between a person recovering independently and submitting a support ticket.

Answer as many of these as possible:

1. What happened? State the problem plainly.
2. Why? Give context when it's honest and useful.
3. What now? Give a specific next step.

Validation errors (inline, adjacent to field)

Frame validation errors as instructions, not accusations.

System errors (something failed)

Permission errors

Payment and account errors

Use passive voice in payment, security, and account errors where active voice would imply blame or cause alarm.

Destructive warnings (before action)

State the consequence. If the action is reversible within a time window, say so. It's more informative and less alarming than stating only that something will be deleted.

Success messages

Confirm what happened. Keep it brief. No editorializing. Reserve positive, warm tone and exclamation points for genuine milestones and warm moments (a welcome, a thank-you) — not routine confirmations.

Rules

• Never use "Oops".
• Never blame the person: "You entered an invalid email" → "Enter a valid email address."
• Never be vague: "Something went wrong" is never acceptable.
• Never use exclamation points in errors.
• Always offer a recovery path when one exists.

---

8. Inclusive language

Language can exclude people in ways that are both immediately obvious to the affected person and invisible to everyone else. For example, "easy" and "simple" invalidate the experience of people who find things hard.

Substitution

Person-first

Use the most specific term available over generic abstractions.

No assumed context

• Always specify time zones when displaying times.
• Avoid idioms that don't translate: "low-hanging fruit", "hit the ground running", "ballpark".
• Use internationally unambiguous date formats when precision matters.
• Don't start a sentence with "this" or "that" unless the noun immediately follows. It's ambiguous and difficult to translate.

No urgency or pressure language

---

9. Accessibility and alt text

Alt text makes images accessible to people who use screen readers and provides context when images don't load. Every informative image needs alt text. Decorative images should use alt="" to hide them from screen readers.

Rules

• Write alt text for all informative images.
• Use alt="" for decorative images.
• Do not start alt text with "Image of". Screen readers already announce it's an image.
• Keep alt text under 140 characters.
• Describe meaning and context, not visual detail.
• Do not repeat the caption in alt text.
• Use the same word choices in alt text as in nearby body text and captions.

Alt text in Customer.io contexts

• Empty state illustrations: If the heading and body copy already convey the message, the illustration is decorative. Use alt="".
• Charts and data visualizations: Describe the key insight, not the structure. "Open rates peaked at 42% in March, driven by the re-engagement campaign." For complex charts, note the general pattern and link to the underlying data.

---

10. AI-specific copy

AI features carry a specific set of trust risks that standard copy rules don't cover. Overclaiming ("optimal", "best") sets expectations the system can't always meet. Describing the technology instead of the outcome makes copy feel like a press release. Presenting AI output as final removes agency. Calling the Agent "a bot" or "a tool" undersells a capability that is core to the platform's value.

Rules

• Lead with the outcome, not the AI. Never use "AI-powered" as a descriptor.
• AI output is always a suggestion until a person acts on it. Never present it as final or authoritative.
• Use hedging language for probabilistic recommendations: "likely", "based on", "suggested".
• Describe what the AI is doing in plain terms, not the technology behind it.
• When the Agent completes a task, confirm what it did and what the person should review.
• The feature is "the Agent" (capitalized, with article). Customer.io speaking about its feature is "our Agent" (capitalized). The person's individual experience is "your agent" or "my agent" (lowercase, with possessive). Never "Agent" alone, "AI Agent", "the bot", "the AI", or "the tool". Surface-qualified names are proper nouns and stay as written ("Slack Agent"); don't rewrite them to "the Agent in Slack".

Naming the Agent

Outcome-first, not AI-first

Confidence and uncertainty

AI in progress

---