Paklauskite penkių agentūros darbuotojų, kaip atrodo jų turinio kūrimo procesas, ir sulauksite penkių skirtingų atsakymų, iš kurių trys prieštaraus vieni kitiems. Paprastai tai nėra problema, kol kas nors nesusigadina. Tada visi supranta, kad niekas iš tikrųjų nesusitarė, kur procesas prasideda, kur baigiasi ar kas turėtų pastebėti klaidą viduryje.
Štai visas procesas, nuo pradžios iki galo. Ne kiekvienai agentūrai reikia kiekvieno žingsnio būtent tokia forma, bet jei visiškai praleidžiate vieną iš šių šešių etapų, tikriausiai būtent ten ir slypi jūsų problemų priežastis.
Šeši etapai
Brief, kūrimas, vidinė peržiūra, kliento patvirtinimas, scheduling ir reporting. Būtent tokia tvarka, kiekvieną kartą.
1. Brief (užduoties aprašymas)
Prieš kam nors pradedant rašyti caption, reikia atsakyti į klausimus: kam šis įrašas skirtas, į ką jis kreipiasi ir kaip atrodo galutinis rezultatas? Brief neturi būti ilgas. Kelios eilutės apie tikslą, toną ir bet kokias privalomas detales (nuolaidos kodą, hashtag, teisinę informaciją) apsaugo visus komandos narius nuo spėliojimo.
Praleiskite šį žingsnį ir gausite turinį, sukurtą „pagal nuojautą“, o tai paprastai reiškia du ar tris etapus „tiesą sakant, ar galėtumėte pakeisti…“, kurių penkių minučių brief būtų padėjęs išvengti.
2. Kūrimas
Tekstų autorius arba dizaineris sukuria patį įrašą: tekstą, vaizdą ar vaizdo įrašą, hashtag, nuorodą. Tai vienintelis etapas, kuriame turėtų būti priimami tikri kūrybiniai sprendimai. Viskas po to yra tikrinimas, o ne kūrimas.
Vienas įprotis, kurį verta išsiugdyti: prisekite brief prie paties įrašo, o ne siųskite atskiru el. laišku ar per chat. Kai vėliau gaunamas grįžtamasis ryšys, peržiūrintis asmuo turėtų matyti, ko įrašu buvo siekiama, nereikdamas knistis po senas žinutes.
3. Vidinė peržiūra
Kažkas iš jūsų komandos (ne kūrėjas) patikrina įrašą dar prieš jį pamatant klientui. Brand voice, rašybos klaidos, ar vaizdas atitinka tekstą, ar nuoroda veikia. Čia geriausia tyliai pastebėti gėdingas klaidas, užuot jas parodžius viešai.
Šis etapas skirtas tam, kad bendravimas su klientu nevirstų klaidų medžiokle. Jei klientas pastebi rašybos klaidas, vadinasi, vidinė peržiūra nevyksta arba ji atliekama nepakankamai atidžiai.
4. Kliento patvirtinimas
Klientas (arba asmuo, priimantis galutinį sprendimą) peržiūri paruoštą įrašą ir pasako „taip“, „ne“ arba nurodo, ką pakeisti. Tai turėtų būti greičiausias viso proceso etapas, tačiau daugumai agentūrų jis yra lėčiausias – dažniausiai dėl to, kaip jis suorganizuotas, o ne dėl paties kliento.
Sprendimas beveik visada tas pats: nusiųskite nuorodą, kurią klientas galėtų atidaryti be slaptažodžio, parodykite jam įrašą tokį, koks jis atrodys platformoje, ir leiskite patvirtinti telefonu. Parašėme išsamų gidą, kaip pagreitinti būtent šį etapą, jei čia esate užstrigę.
5. Scheduling (planavimas)
Patvirtintas įrašas keliauja į eilę laukti savo publikavimo laiko. Tai skamba paprastai ir dažniausiai taip ir yra, jei tik planuojama būtent ta versija, kuri buvo patvirtinta. Kopijuojant patvirtintą įrašą į atskirą planavimo įrankį, atsiranda mažų, išvengiamų klaidų: praleistas žodis, blogai apkarpytas paveikslėlis ar neveikianti nuoroda.
6. Reporting (ataskaitos)
Kai įrašas tampa matomas viešai, kas nors patikrina jo rezultatus ir periodiškai pateikia juos klientui. Šis etapas praleidžiamas dažniau nei bet kuris kitas, nes atrodo mažiau skubus nei kitas terminas. Tačiau būtent šis etapas lemia, ar klientas pratęs bendradarbiavimą, todėl jam verta skirti laiko.
Kur procesai stringa?
Kiekvienas etapas savaime veikia puikiai. Problemos atsiranda tarp etapų, kai niekam neaišku, kieno eilė veikti.
Nuo kūrimo iki vidinės peržiūros. Kūrėjas baigia darbą ir… kas toliau? Jei nėra aiškaus signalo („paruošta peržiūrai“), įrašai guli nepaliesti, nes visi mano, kad kas nors kitas juos jau peržiūrėjo.
Nuo vidinės peržiūros iki kliento patvirtinimo. Tai etapas, kuriame gali nutekėti informacija, kurios klientas neturėtų matyti. Klientas pamato vidines diskusijas apie šrifto dydį ar, blogiau, versiją, kurią vidinė peržiūra pažymėjo kaip nepabaigtą. Workflow, kuris atskiria vidinius ir klientams skirtus komentarus, padeda to visiškai išvengti.
Nuo kliento patvirtinimo iki scheduling. Čia atsiranda kopijavimo ir įklijavimo klaidos. Sprendimas – patvirtinimas ir planavimas tame pačiame įrankyje, kad nereikėtų nieko įvedinėti rankiniu būdu.
Paprasti SLA, kurie palaiko procesą
Jums nereikia oficialaus sutarties punkto (nors tai nepakenktų), tiesiog susitarto ritmo, kurio visi laikosi:
- Vidinė peržiūra atliekama per vieną darbo dieną nuo įrašo patekimo į eilę.
- Į kliento patvirtinimo užklausas atsakoma per dvi darbo dienas.
- Viskas, kas nepatvirtinta likus 24 valandoms iki numatyto laiko, perkeliama į kitą laisvą vietą – be išimčių ir be kaltės jausmo.
- Grįžtamasis ryšys pateikiamas vienu kartu, o ne penkiomis atskiromis žinutėmis per tris dienas.
Užrašykite tai ten, kur galėtų matyti tiek jūsų komanda, tiek klientai. SLA, kuris egzistuoja tik jūsų galvoje, nėra tikras SLA – tai tiesiog užprogramuota frustracija.
Kur automatizavimas padeda, o kur ne
Automatizuokite priminimus. Jei įrašas laukia patvirtinimo jau parą, sistema turėtų paraginti peržiūrintįjį asmenį, o ne jūs. Tai vertingiausias automatizavimas visame procese, nes žmonių raginimas yra tas darbas, kurio niekas nemėgsta daryti rankiniu būdu.
Automatizuokite perdavimą. Patvirtinimas turėtų automatiškai reikšti suplanavimą be jokio kopijavimo. Tai panaikina visą kategoriją pokalbių „palaukite, aš ne tai patvirtinau“.
Neautomatizuokite sprendimų. Tai, ką įrašas sako, kaip jis skaitosi, ar juokelis tinkamas – vis dar yra žmogaus darbas. Šablonai ir DI įrankiai gali padėti paruošti juodraštį, bet peržiūros etapai egzistuoja tam, kad kas nors iš tikrųjų pažiūrėtų į turinį prieš jam išeinant kliento vardu.
Šablonai, kuriuos verta turėti po ranka
Keli daugkartinio naudojimo elementai padeda sutaupyti laiko visame procese:
- Brief šablonas: tikslas, auditorija, pagrindinė žinutė, būtini elementai, terminas. Penki laukai, užpildomi per dvi minutes, sutaupo valandą diskusijų vėliau.
- Grįžtamojo ryšio formatas peržiūrai: paprašykite konkrečių pastabų („pakeiskite antraštę į X“), o ne abstrakčių („kažkas čia negerai“). Neaiškus grįžtamasis ryšys yra pagrindinė nereikalingų taisymo etapų priežastis.
- SLA aprašymas naujiems klientams: nustatykite lūkesčius dėl terminų onboarding metu, o ne po trijų savaičių, kai terminas jau praleistas.
Viso proceso sujungimas
Nė vienas iš šių šešių etapų nėra sudėtingas savaime. Sunku yra juos visus įgyvendinti eilės tvarka, kad niekas jų nepraleistų dėl užimtumo. Būtent tam ir skirtas workflow įrankis: jis neatlieka kūrybinio darbo už jus, tiesiog užtikrina, kad brief vestų prie kūrimo, tada prie peržiūros, patvirtinimo ir planavimo – būtent tokia tvarka, be nuolatinės rankinės kontrolės.
Kontentino sujungia visą šią grandinę į vieną srautą: vidinė peržiūra prieš kliento patvirtinimą, kliento patvirtinimas su tiesiogine peržiūra ir patvirtinti įrašai, kurie keliauja tiesiai į tvarkaraštį be perrašymo. Jei norite pamatyti būtent patvirtinimo procesą, tai etapas, kurį dauguma agentūrų pajunta pirmiausia.
Norite, kad visas procesas vyktų vienoje vietoje? Išbandykite nemokamai 14 dienų, nereikia jokios kredito kortelės, arba užsisakykite demo ir mes pritaikysime jūsų dabartinį procesą mūsų įrankyje.
DUK: socialinių tinklų darbo procesas agentūroms
Kokie yra socialinių tinklų workflow etapai?
Šeši etapai iš eilės: brief, kūrimas, vidinė peržiūra, kliento patvirtinimas, scheduling ir reporting. Dauguma proceso problemų kyla praleidus vieną iš jų, ypač brief ir vidinės peržiūros etapus.
Kiek laiko turėtų trukti kliento patvirtinimas?
Dvi darbo dienos yra įprastas ir teisingas standartas. Jei procesas trunka ilgiau, rizikuojate nukrypti nuo planuoto grafiko. Trumpesnis laikas užimtiems klientams gali atrodyti skubotas. Nustatykite šį lūkestį onboarding metu, o ne po pirmo praleisto termino.
Kas labiausiai vilkina socialinių tinklų darbo procesą?
Beveik visada – kliento patvirtinimas. Dažniausiai dėl to, kad peržiūrai reikia prisijungti, siųstis priedus arba naudotis kompiuteriu, o tai neatitinka to, kaip žmonės iš tikrųjų tikrina informaciją darbo dienos metu. Pašalinkite šias kliūtis ir vėlavimai išnyks.
Ar tas pats asmuo turėtų rašyti ir patvirtinti įrašą?
Ne. Jei autorius yra ir vienintelis tikrintojas, klaidos lieka nepastebėtos, kol jas pamato klientas arba, dar blogiau, auditorija. Net ir greitas kolegos žvilgsnis padeda išvengti daugumos klaidų.
Ką turinio kūrimo procese verta automatizuoti?
Priminimus ir perdavimą iš patvirtinimo į planavimo etapą. Ko nereikėtų automatizuoti: sprendimų dėl tono, tikslumo ir turinio kokybės. Automatizavimas turėtų palengvinti administravimą, o ne pakeisti sprendimų priėmimą.
Valdykite visą procesą vienoje vietoje
Nuo brief iki publikavimo be penkių atskirų įrankių. Išbandykite Kontentino nemokamai 14 dienų arba užsisakykite demo ir mes parodysime, kur jūsų dabartiniame procese yra spragų.
