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.
Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Standard językowy i ma formę Standard. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal ton i rejestr: profesjonalny, spójny, bez slangu.
  • Zdefiniuj terminologię: preferowane i zakazane terminy (słownik).
  • Określ formaty: akapity, listy, nagłówki, długości, CTA.
  • Zbuduj linter językowy: typowe błędy, skróty, kalki, interpunkcja.
  • Dodaj wyjątki i proces akceptacji odstępstw (rejestr wyjątków).
  • Wdróż w zespole: szablony, szkolenia, przeglądy jakości.

Najczęstsze pułapki

  • „Standard” jako PDF w szufladzie – bez narzędzia egzekucji nic się nie zmienia.
  • Brak słownika terminów – każdy pisze inaczej, rośnie chaos.
  • Zbyt drobiazgowe zasady – ludzie je obchodzą lub ignorują.
  • Brak wyjątku i ścieżki eskalacji – standard blokuje pracę.

Artefakty w Luage

policy:language dictionary templates lint_rules exception_log

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

Szablon do skopiowania

Fragment polityki językowej (skrócony)

language: pl-PL
style:
  tone: "profesjonalny, rzeczowy"
  avoid:
    - "ASAP"
    - "ticket"
  prefer:
    ASAP: "w ciągu 24 godzin roboczych"
    ticket: "zgłoszenie"

Dobrze działa: mało zasad, ale egzekwowanych konsekwentnie w narzędziu i szablonach.

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.