Lasku tai kuitti on osa liiketapahtumaa, ei vain kampanjan muunnos. Luotettavan prosessin tulee näyttää, onko dokumentti luotu, mikä valtuutettu kohde on valittu ja mitä vastaavalle viestille tapahtui. Todennus auttaa määrittämään lähettäjän henkilöllisyyden, mutta se ei voi todistaa, että asiakas on vastaanottanut asiakirjan tai toiminut sen perusteella.
Liity yritystapahtumaan postitapahtumaan
Määritä vakaa yritystapahtuman tunniste ja erillinen viestiyrityksen tunniste. Tallenna malliversio, valtuutettu vastaanottajalähde, lähetysreitti ja lopputulos. Pidä laskun sisältö ja taloudelliset tiedot poissa laajoista toimintalokeista. Asiakastuki tarvitsee yleensä tila- ja korrelaatioviitteen, ei rajoittamatonta pääsyä jokaiseen liitteeseen.
Erottele asiakirjan luominen, toimittaminen ESP, vastaanottavan palvelimen hyväksyntä ja asiakkaan kuittaus. SMTP määrittelee siirtovastuun; se ei todista, että lasku on luettu tai toimitettu laillisesti. RFC 5321. Sovellettavat laskutus- ja ilmoitusvelvollisuudet vaativat oman tarkastelun.
Suojaa tapahtumareittiä
Tarkista todellinen Lähettäjä, kirjekuori ja DKIM henkilöllisyyksien allekirjoittaminen lasku- ja kuittimalleihin. Toimittajan yleinen asetusnäyttö ei voi osoittaa, että tietty integraatio käyttää aiottua toimialuetta. Säilytä kontrolloitu lopullinen näyte ja vastaanottavan järjestelmän luotettavat todennustulokset.
Estä kriittinen tapahtumakäsittely joutumasta nälkään kampanjajonojen takia. Googlen henkilökohtaisen Gmail ohjeissa suositellaan viestiluokkien erottamista Lähettäjä-osoitteista ja tarjousten pitäminen poissa kuiteista. Nämä ovat lähetyskäytäntösuosituksia, eivät tae yksittäisestä maineesta tai jonokapasiteetista. Googlen lähettäjän ohjeet.
Yhdistä realistinen erä
Harkitse hypoteettista 1 000 yksilöllisen kuittitapahtuman erää, yksi ensimmäinen yritys tapahtumaa kohden. Ensimmäisessä katkaisussa 970 on vahvistanut vastaanottimen hyväksymisen, 20 on tilapäisesti lykätty ja kymmenellä on lopullinen vika. Oletetaan, että jokainen lykätty tapahtuma saa yhden sallitun lisäyrityksen. Toisella rajalla 15 niistä saavuttaa hyväksynnän ja viisi jää odottamaan. Kumulatiivinen tapahtumatila on 985 hyväksyttyä, viisi odottavaa ja kymmenen epäonnistunutta, yhteensä samat 1 000 tapahtumaa.
Yrityksiä oli 1 020, koska kaikkia 20 lykättyä tapahtumaa yritettiin vielä kerran. Raportointi 985 hyväksyttiin 1 020 yrityksestä, koska yritystapahtuman toimitusnopeus sekoittaisi yksiköitä. Tapahtuman hyväksymisosuus on 98,5 %, kun taas loput tulokset vaativat erillistä käsittelyä. Hyväksyminen ei vieläkään ole todiste postilaatikon sijoittamisesta.
Nämä ovat käsin tehtyjä hypoteettisia tapahtumien laskentoja, eivät suoritettua täsmäytystestiä tai ulkoista lähetystestiä. Rajaus merkitsee raportointiikkunaa, ei kuitti-asiakirjan vanhenemista. Todellisen vertailun tulisi säilyttää sama tapahtumapopulaatio ja raja sekä paljastaa mallin, kohteen tai palveluntarjoajan muutokset. Puuttuvien takaisinsoittojen tulee pysyä tuntemattomina, kunnes ne on sovitettu; virheen puuttuminen ei ole positiivinen toimitustulos.
Käsittele poikkeuksia muuttamatta tapahtumaa
Pysyvien vikojen sattuessa selvitä palautettu syy ja ota yhteyttä hyväksyttyyn kontaktien korjausprosessiin. Älä ohjaa laskua vahvistamattomaan osoitteeseen vain siksi, että joku pyytää sitä. Jos lähetykset ovat epävarmoja, täsmää palveluntarjoajan tietue ennen tapahtuman toistamista. Kuitin uudelleenlähettäminen ei saa luoda uutta laskua tai veloitusta.
Käytä todennettua asiakasportaalia tai muuta valtuutettua jatkuvuuskanavaa, kun liiketoimintaprosessi tukee sitä. Älä liitä arkaluonteisia asiakirjoja improvisoituun varaviestiin vahvistamatta vastaanottajaa ja lupaa. Pitää ennätys joista toimitusyritys liittyy alkuperäiseen liiketapahtumaan.
Päätösraportin tulee näyttää ratkaisemattomat tapahtumat, omistajat ja seuraavat toimet, ei vain yhteenlaskettu vihreä toimitusprosentti. Asiakkaalla, joka odottaa yhtä puuttuvaa kuittia, on väliä, vaikka kokonaishyväksyntäaste olisi korkea.
Anna ratkaisemattomille tapahtumille omistaja
Tallenna jokaiselle odottavalle tai epäonnistuneelle tapahtumalle seuraava sallittu toiminto ja sen omistaja. Hyväksytty tapahtuma ei tarvitse sokeaa uudelleenlähetystä yksinkertaisesti tehdäkseen sen kokonaisraportti vihreämpää. Kaikkien jatkuvuuskanavien on säilytettävä alkuperäinen tapahtuman identiteetti ja vahvistettu vastaanottaja.