Håndter 50 Google Business-lokationer uden et regneark

Regnearket starter godt. Én fane pr. region, en kolonne til butikskoden, en til Google-bedømmelsen, en tredje til "profil komplet?". Nogen tilføjer betinget formatering, og det ligner et system. Et halvt år senere har det fyrre kolonner, tre personer ejer forskellige kopier, og ingen kan sige, om rækken for butik 1042 afspejler Google eller det, en leder skrev i marts.

Det, der går i stykker, er ikke dataindtastning. Det er tillid. Et regneark registrerer, hvad nogen troede i et øjeblik; en profil ændrer sig, når Google anvender en redigering, når en butik lukker, når en anmeldelse forsvinder. Ved halvtreds lokationer bliver kløften mellem arket og opslagene et job, ingen blev ansat til.

Hvad er håndtering af Google Business Profile for flere lokationer?

Den definition er bevidst kedelig: ingen rangeringsløfte, for værdien er ikke en bedre kortposition. Det er at vide på en mandag, hvilken butik der er i stykker, og hvem der retter den.

Hvor regnearket knækker

1. Der er ingen delt identitet. Ét ark siger "Manchester Arndale", et andet "M42", Google har sit eget opslag. I det øjeblik en person skal oversætte mellem tre navne, kan en række opdateres korrekt og stadig pege på den forkerte butik.
2. Arket er et øjebliksbillede, ikke en tilstand. Google anvender en brugerforeslået redigering, en lokation lukker, en helligdagsopdatering lander på 30 butikker. Arket beholder sidste måneds svar, indtil nogen husker at spørge.
3. Anmeldelser passer ikke i celler. Den anonymiserede demokonto med 23 lokationer har 9.749 anmeldelser. Du kan ikke lægge et svar, dets sprog, alder og lokation i et regneark og stadig se, hvad der skal besvares i dag.
4. Adgang er alt eller intet. Del filen, og en regionschef ser hver region, inklusive butikkerne, de ikke driver. Begræns den, og hovedkontoret mister den visning, det har brug for.
5. Det forsvinder med én person. Filen ligger i nogens Drive med deres navngivning og deres farveregler. Når de går, går processen.

Regnearket var ikke en fejl. Det var rigtigt til fem lokationer og en rimelig bro til femten. Ved halvtreds er det en anden, unøjagtig kopi af Google, og at vedligeholde en kopi er ikke styring.

Butikskoden er den eneste join-nøgle

Enhver virksomhed med flere enheder har allerede et nummer, som økonomi, logistik og POS-systemet er enige om. Brug det. En butikskode overlever et rebrand, en adressekorrektion og et lederskift. Googles opslagsnavn gør ikke.

Tre regler holder den nyttig:

• Én kode pr. handelslokation. En lukket butik beholder sin kode, men skifter status; koden genbruges aldrig til et nyt sted, ellers hæfter historikken på det forkerte.
• Koden vises i hver visning. Lokationsliste, anmeldelsesrække, rapport, eksport, supportbillet. Hvis et team skal søge på navn, er koden dekoration.
• Koden er ikke Googles navn. Læg ikke "1042" i det offentlige virksomhedsnavn for at gøre matchning lettere. Det offentlige opslag følger Googles navneregler; koden hører i din interne post og, hvor det findes, i Googles egne lokationsetiketter.

Butikskoder gør massearbejde sikkert. "Opdater disse 12" er en liste, du kan tjekke; "opdater den nordlige region" er et filter, der kan indeholde en butik, som flyttede i sidste uge.

23 placeringer på én liste: butikskode, by og distrikt, bedømmelse og status. Anonymiseret demokonto.

En ugentlig rytme, der overlever en dårlig uge

Kadencen betyder mere end værktøjet. En rytme, der afhænger af, at nogen finder tid, fejler i den uge en butik oversvømmes, eller en leder stopper. Brug korte, faste blokke med én ejer hver.

Den ugentlige kø bærer vægten. I produktet er det handlingslisten: punkter Rangeret efter risiko, hver linket til den anmeldelse eller det felt, den kom fra, så en leder ikke starter med at browse halvtreds lokationer. Ubesvarede negative først, derefter ændringer Google markerede, derefter dage hvor en lokation samlede en klynge 5-stjernede anmeldelser, som Google ofte fjerner. Rækkefølgen er meningen; linkene er beviset.

To detaljer gør rytmen ærlig. Først, køen er delt: hovedkontor og regionschef ser samme liste, filtreret forskelligt. Dernæst, den ryddes, ikke gennemgås. Et ugentligt møde, der slutter med "vi bør se på dem", har ikke flyttet noget.

Oversigten: gennemsnitsbedømmelse, anmeldelser i denne måned, svarprocent og anmeldelsesvolumen. Anonymiseret demokonto.

Masseopdateringer og overdragelsesproblemet

Hvornår en masseopdatering er rigtig

Masse er rigtigt, når ændringen er identisk, verificerbar og reversibel. Helligdagsåbningstider for en gruppe butikker. En ny ydelseslinje, som hver filial nu tilbyder. En rettet website-URL. En beskrivelsesændring godkendt af brandet. I hvert tilfælde hører samme tekst mange steder, og det eneste spørgsmål er, om den landede.

Tre vaner holder det sikkert:

• Vælg lokationerne eksplicit via butikskode, aldrig "alle" som standard.
• Tjek antallet før publicering, og vid hvilke butikker der bevidst er udeladt.
• Kør profilauditet igen bagefter. En masseopdatering, der fejlede på fire butikker, skal se ud som fire fund, ikke en succesmeddelelse.

Hvornår en masseopdatering er farlig

Identitetsfelter er ikke massefelter. Navn, primær kategori og adresse afgør, hvad opslaget er; en forkert masseredigering der kan udløse en suspendering og tager uger at rulle tilbage. Det samme gælder enhver ændring med lokale undtagelser: en butik med andre søndagsåbningstider, en klinik med midlertidig lukning. Masseværktøjer kender ikke lokal kontekst; personen, der vælger butikkerne, gør.

Hvad der overlever en overdragelse

Når en regionschef stopper, forsvinder den uformelle viden med dem: hvilken butikschef der svarer på anmeldelser, hvilket opslag der er en kendt dublet, hvorfor en filial har to kategorier. Et fungerende system beholder de dele, der kan skrives ned:

• Butikskoden og dens statushistorik.
• Hver anmeldelse og hvert svar, inklusive svar på anmeldelser, Google senere fjernede.
• Gemte skabeloner og hvem der godkendte dem.
• Revisionssporet: hvem ændrede hvilket felt, og hvornår.
• Adgang pr. bruger, der kan tilbagekaldes ét sted.

Eksportér listen før sidste dag, ikke efter. En Excel-eksport er et dårligt styresystem men en god afskedsgave – og grunden til, at eksportkøen findes.

En tjekliste for den første måned

1. Byg lokationslisten med butikskoder, og markér lukkede eller dublerede opslag, før du optimerer noget.
2. Vælg én ejer pr. felt: åbningstider, beskrivelse, billeder, svar, adgang.
3. Sæt den daglige anmeldelsesblok og den ugentlige kø. Læg begge i kalendere med navne på.
4. Kør ét profilaudit på tværs af porteføljen, og ret de ti kontroller pr. lokation, travleste butikker først.
5. Flyt de fem mest almindelige svar til delte skabeloner, og svar derefter på det aktuelle efterslæb i én omgang.
6. Aftal månedsrapporten, før første måned slutter: hvilke målinger, hvilket datointerval, hvem der læser den.
7. Gennemgå rettigheder. Fjern alle, der er stoppet, og begræns regionschefer til deres egne butikker.
8. Test overdragelsen: bed en kollega finde én butiks anmeldelseshistorik og profilstatus med kun systemet, ikke din hukommelse.

Hvis testen tager mere end to minutter, lever processen stadig i en person. Det er regnearksproblemet i en ny grænseflade.

Pointen er ikke værktøjet

Halvtreds lokationer har ikke brug for et pænere regneark. De har brug for én identitet pr. butik, én kø der afspejler Googles aktuelle tilstand, en kadence med ejere og en registrering, der overlever personaleforandringer. Få de fire rigtige, og værktøjsvalget bliver indlysende; få dem forkerte, og ethvert værktøj er endnu en fane, ingen stoler på.

Hvis du driver en butiksportefølje med sæsonåbningstider, viser samme mønster sig i detailhandlen: hovedkontorets ændringer og lokale undtagelser ankommer i samme uge. Start med at læse hvad en Google Business Profile faktisk styrer, og prøv derefter listen med dine egne butikskoder.

Start 3 dages gratis prøveperiode · Se priser