Google Groups за тимски имејл: сваки одговор добија власника и статус

За адресу попут support@ направите групу у Google Groups, укључите историју разговора и функцију Collaborative Inbox, па одредите ко сме да обрађује захтеве. Google-ово упутство за подешавање групе наводи те поставке и услов да пословни или школски налог има омогућен Google Groups for Business. Адреса постаје заједнички ред тек када поруке заиста стижу у групу и чланови имају приступ разговорима.

Затим тим за сваки примљени разговор ручно одређује одговорног члана и бележи исход. Упутство за рад у Collaborative Inbox-у описује преузимање или доделу разговора, претрагу по додељеном члану и статусе решавања. Правило да се пре одговора провери додела, а после завршетка промени статус, помаже малом тиму да уочи захтеве без власника и избегне паралелне одговоре.

Направите групу и сачувајте разговоре

У Google Groups изаберите креирање групе, унесите њено име и имејл адресу, па додајте људе који ће примати и обрађивати захтеве. Проверите стварну адресу приказану после креирања: на пословном налогу она може да садржи додатак у имену који нисте очекивали. Ако купци већ користе објављену адресу support@, само слично име нове групе неће преусмерити постојећу пошту; потребно је проверити куда се поруке на ту адресу достављају.

Власник или менаџер групе треба да укључи историју разговора, а затим у поставци „Enable additional Google Groups features“ изабере „Collaborative Inbox“ и сачува измене. Када је историја искључена, нове поруке се не додају у историју видљиву у Google Groups, што руши заједнички преглед захтева. Ако опција за Collaborative Inbox није доступна на пословном налогу, администратор треба да провери да ли је укључен Google Groups for Business.

За подршку или продају подесите „Who can post“ тако да спољни пошиљаоци могу да пишу групи, ако су они очекивани корисници адресе. Одвојено ограничите „Who can view conversations“ на људе који треба да виде преписку. Укључите и „Allow Email Posting“ ако захтеви стижу имејлом, па пошаљите пробну поруку са адресе ван организације и проверите да ли се појавила као разговор у групи.

Дозволе за доделу и одговор са заједничке адресе

Само чланство не даје сва права за обраду захтева. Члановима који преузимају разговоре, додељују их другима и означавају као завршене потребна је дозвола „Who can moderate metadata“. За означавање разговора као дупликата или као случаја у коме ништа не треба предузети потребна је „Who can moderate content“. Ако особа треба да користи оба исхода, проверите да има и ту другу дозволу.

Ко сме да одговара са адресе групе подешава се посебно, преко „Who can post as group“. Поставка „Default sender“ може да понуди адресу аутора или адресу групе; за одговоре у име подршке групна адреса је логичан избор. Проверите и „Post replies to“, јер та поставка унапред попуњава примаоца при одговору имејлом. Пре стварног одговора погледајте и пошиљаоца и примаоца: заједнички ред захтева сам по себи не одређује како ће изгледати порука коју купац добија.

Једна особа може да управља поставкама, док остали чланови имају само дозволе потребне за свакодневни рад. Када се тиму придружи нови колега, проверите да ли може да види разговоре и ажурира њихову доделу пре него што му доделите захтев. У супротном ће име одговорног стајати уз разговор, али колега неће моћи да га обради кроз договорени ток.

Од пријема поруке до одговорног члана

Рад почиње прегледом недодељених разговора. Члан који ће водити захтев отвара разговор и бира „Take“; ако је за њега надлежан колега, бира „Assign“ и уноси његову имејл адресу. Додељени члан добија аутоматско имејл обавештење. Претрага омогућава приказ разговора додељених мени, било коме или никоме, па је последња категорија корисна за уочавање порука које још немају власника.

Додела се односи на разговор, а не на сваку појединачну поруку у њему. Зато договорите да чланови пре слања одговора погледају ко је задужен и шта је већ написано. Ако власник одсуствује или је захтев прешао у други део посла, додела може да се уклони командом „Drop“, а разговор потом додели другом члану. Тај договор смањује вероватноћу дуплих одговора, али истовремено слање не спречава аутоматски.

Условни пример: порука о повраћају стиже на support@ и остаје недодељена док је дежурни члан не преузме. Он одговара пошиљаоцу и оставља разговор нерешеним ако чека податке потребне за одлуку. Када су радње завршене, означава га као „Complete“. Ако посао преузме колега, мења се додела у групи; приватно прослеђивање поруке без те измене оставило би погрешну особу као видљивог власника.

Ознака описује тему, статус исход

За разврставање укључите „Shared labels“ у поставкама групе. Google-ово упутство за заједничке ознаке објашњава да чланови могу да означе разговор и филтрирају разговоре по ознаци, док ознаку виде сви који имају приступ том разговору. За теме попут продаје и повраћаја користите кратке називе без размака; Google Groups не дозвољава размак у имену ознаке. Ознака је заједничка категорија, па у њу не стављајте приватну белешку.

Статус одговара на друго питање: да ли још постоји посао око разговора. Када су потребне радње завршене, означите „Complete“; „No action needed“ користите када радња није потребна, а „Duplicate“ за поновљени разговор. Већ додељен разговор задржава доделу и после означавања као решеног. Зато име члана и статус треба посматрати одвојено: једно показује одговорност, друго исход.

За преглед активног посла филтрирајте разговоре према „Resolved status“ и изаберите нерешене, па међу њима проверите недодељене и оне чији је власник одсутан. Прочитана порука и даље може да захтева одговор, због чега број непрочитаних није поуздан списак посла. Завршене разговоре не треба брисати ради чистијег приказа: брисање је трајно, док филтер оставља историју доступном тиму.

Граница оваквог радног реда

Google Groups овде даје заједничку адресу, историју, ручну доделу, ознаке и статус разговора. Вредност тих података зависи од тога да ли тим заиста прегледа недодељене разговоре и ажурира исход када заврши посао. За тим коме су потребни аутоматска расподела, рокови одговора или извештаји о учинку, то су посебни захтеви које треба проверити при избору алата: описани ток у Collaborative Inbox-у заснива се на ручном преузимању и праћењу разговора.

Прочитајте и:

• Повезивање на СЕФ API: кључ није довољан док статус не постане активан
• Дуг контекст или RAG: више токена не значи увек бољи одговор
• Сторно или отказивање е‑фактуре: статус одређује прави поступак