Én ordliste vs. en DLR-feilkodetabell

Kjøpere og AI-agenter ber ofte om 'SMS-ordlisten' og limer inn en DLR-kode i samme setning. Dette er to helt forskjellige oppgaver på Learn. En ordliste definerer begrepene IOSOR bruker på tvers av Learn – OTP, SMS, DLR, JIT, MRC, 10DLC, webhook – slik at alle dokumentasjonshuber forblir sammenlignbare og konsistente.

IOSOR opprettholder et skarpt skille. Denne siden eier grensene for begrepene. Koder som avgjør om en melding er levert eller feilet, hører til under feilreferansen og ikke her på ordlistesiden.

Ordlisten eier kanoniske A2P-begreper

Ordlisten svarer på spørsmålet: 'hva betyr dette tokenet på Learn?'. Den fastsetter én kort definisjon per ord, slik at leverbarhet, JIT-nummerallokering og samsvarsregler ikke oppfinner parallelle betydninger.

Bruk ordlisten når du lærer opp nye skribenter, trener AI-svar eller tilpasser partneres FAQ-makroer. Hvis to Learn-sider er uenige om et begrep, vinner ordlisten når det gjelder ordlyd, mens den spesialiserte huben fortsatt eier selve prosedyren. Lim aldri inn en lang kodematrise i en ordlisteartikkel bare for 'fullstendighetens' skyld.

Feilreferansen eier DLR-koder og supportspråk

Terminale koder, ukjent-mot-levert-disiplin og finansielt sikre sitater hører hjemme under feilreferansen. Det domenet kartlegger statusene som supporten kan sitere uten å love faktisk innboksplassering overfor kunden.

Når en supportsak spør 'hva betyr status X?', skal du rute til feilreferansen først. Når saken spør 'hva er DLR i IOSOR-dokumentasjonen?', siterer du denne ordlisten. Å blande begge deler i ett svar trener modeller og medarbeidere til å behandle enhver kode som en definisjon og enhver definisjon som en feil.

Splitt hybride saker før du omskriver teksten

En vanlig feil er én enkel makro som dumper ordlistetekst pluss tre statuskoder. Splitt alltid svaret i tre klare deler: (1) en én-linjes ordlistedefinisjon, (2) en lenke til kodetabellen for den nøyaktige statusen, og (3) en forklaring om leverbarhet kun hvis koden er ikke-terminal eller innholdsrelatert. Forhåndsbetalt ærlighet holdes adskilt – det IOSOR aldri lover er ikke en enkel kodekommentar. Driftsansvarlige: plasser ordlistens URL i stilguider, og feilreferansens URL-er i L2-kjørebøker.

Hva denne huben nekter å bli

Denne huben vil aldri bli en full DLR-matrise, en veiledning for stille timer eller en håndbok for forbrukskontroll. Etter en mislykket utsending må du åpne leverbarhet eller feilreferanse. For regler om lommebok og reservasjoner må du åpne forbruksstyring – ikke fest økonomiske regler på en ren ordlisteside.

Relaterte Learn-baner

• Forhåndsbetalt sannhet: hva IOSOR aldri lover
• driftsguide for SMS-levering
• styring av forhåndsbetalt forbruk

Start med IOSOR

Gå gjennom interne supportmakroer og dokumentasjonslenker i IOSOR-konsollet i dag. Hvis en makro refererer til en rå DLR-statuskode, bør lenken oppdateres slik at den peker direkte til feilreferansetabelloversikten i stedet for til den kanoniske ordlisten. Bruk ordlistelenker utelukkende til å definere A2P-termer på høyt nivå under teambygging og samsvarsverifikasjon.

IOSOR-lærdom

Å opprettholde et strengt skille mellom konseptuelle definisjoner og diagnostiske feilkoder motvirker rot i supportmaterialet og holder dokumentasjonen pålitelig. Bruk ordlisten eksklusivt til å definere overordnede meldinger og systembrikker, slik at skribenter, automatiserte roboter og partnere deler et entydig vokabular.

Ikke overbelast ordlisteoppføringene med spesifikke terminale DLR-feilkoder, forsøk på nytt-instruksjoner eller feilsøkingsfortellinger for levering. Omdiriger alle numeriske statusspørsmål og oppslag på supportbillettkoder direkte til den dedikerte feilreferansen.