Standard

Tone of Voice i styl

Ton to nie „ładne słowa”. To przewidywalny sposób mówienia o produkcie, ryzykach i zobowiązaniach. Dobrze opisany Tone of Voice daje spójność między zespołami i pozwala zamienić standard na reguły.

Wróć do biblioteki Powiązane: Glosariusz Powiązane: RACI Kontakt

Od „ładnych słów” do standardu egzekwowalnego

W praktyce Tone of Voice jest nie tyle estetyką, co kontraktem komunikacyjnym. Jeżeli nie da się go zamienić na reguły (lint, zamienniki, zakazy, progi ryzyka), to pozostaje deklaracją. Dlatego warto projektować ToV jak system: z definicjami, wyjątkami, wersjonowaniem i śladem audytu.

Zasada operacyjna: ToV opisuje sposób mówienia (ton i forma), ale nie zastępuje zasad merytorycznych (np. cytowania, RAG, bezpieczeństwo). Standard językowy działa najlepiej, gdy jest spięty z źródłami prawdy i kontrolą ryzyka.

Cechy tonu, które da się mierzyć

  • Konkretyzacja obietnic – zamiana „szybko” na SLA, „wkrótce” na termin lub warunek.
  • Stabilność terminologii – jeden słownik pojęć w całej organizacji (SSOT terminów).
  • Redukcja emocjonalności – mniej „uspokajania”, więcej faktów, kroków i kryteriów.
  • Transparentność niepewności – jasne: co wiemy, czego nie wiemy, co sprawdzamy.

Formaty komunikatów i reguły redakcyjne

W Compendium warto utrzymywać formaty „gotowe do egzekucji” – nie jako luźne zalecenia, tylko jako wzorce odpowiedzi i transformacje tekstu. Poniżej przykładowy „szkielet” reguł. 

tone_v2:
  attributes:
    - rzeczowy
    - spokojny
    - precyzyjny
  rules:
    - id: promises.require_sla
      when: contains_promises
      enforce: replace_vague_promises_with_sla
    - id: avoid.magic_words
      list: ["ASAP", "wkrótce", "postaramy się", "na pewno"]
    - id: prefer.terms
      map:
        "ticket": "zgłoszenie"
        "feedback": "informacja zwrotna"
format:
  response:
    template: "Fakt → Krok → Termin/SLA → Ograniczenia → Źródło"

Wdrożenie w narzędziu

  1. Definicja: 3–5 cech tonu + zakazy + preferowane zamienniki.
  2. Przykłady: po 10 „przed/po” z obszarów (Support, Marketing, Legal).
  3. Egzekucja: lint językowy w edytorze + automatyczne poprawki w „trybie sugestii”.
  4. Wyjątki: jawne flagi (np. „komunikat kryzysowy”) i rejestr wyjątków.
  5. Audyt: log „co zmieniono i dlaczego” + powiązanie z wersją polityki.

Najczęstsze błędy

  • Opis tonu bez zamienników i zakazów (brak „policy-as-code”).
  • Jedna polityka na wszystko – bez rozróżnienia ról i kanałów (email / chat / dokumenty).
  • Brak wersjonowania: zmiany „w locie”, bez śladu, bez rollbacku.
Minimalny standard
  • 3–5 cech tonu (np. rzeczowy, spokojny, precyzyjny).
  • Zakazy (slang, puste obietnice, „ASAP”).
  • Preferencje (SLA zamiast ogólników, konkret zamiast metafor).
  • Przykłady: zgodne / niezgodne.
Przykładowe reguły
  • Obietnice muszą być mierzalne. Zamiast „szybko” podaj SLA.
  • Nie zakładaj intencji. Zamiast „na pewno chodzi o…” — dopytaj lub zaznacz warunki.
  • Używaj terminologii produktu. Jeden termin na jedną rzecz (glosariusz).
Policy-as-code (szkic)
tone:
  attributes: ["profesjonalny", "spokojny", "precyzyjny"]
  avoid_terms: ["ASAP", "ticket", "feedback"]
  prefer:
    ASAP: "w ciągu 24 godzin roboczych"
    ticket: "zgłoszenie"
    feedback: "informacja zwrotna"
style:
  promises:
    require_sla: true
To nie jest literatura. To ma być egzekwowalne w narzędziu.