Restaurang i AI-svar – menyn är problemet

Restauranger har en fördel och en nackdel jämfört med boende. Fördelen är att frågorna är extremt specifika och att specifika frågor har färre konkurrenter. Nackdelen är att svaret nästan alltid ligger i menyn, och menyn är det innehåll branschen är sämst på att publicera läsbart.

Varför PDF:en inte fungerar

Det finns goda skäl till att menyer blir PDF:er. Menyn formges i samma verktyg som trycksaken, den byts ofta, och att exportera en fil är enklare än att uppdatera en webbsida. Resultatet är ändå att innehållet blir svårt eller omöjligt att komma åt: en PDF kan behöva hämtas och tolkas separat, och är den exporterad som bild finns ingen text alls i den.

En meny som ligger i ett bildgalleri eller som en flash-liknande bläddrare är samma problem i en annan förpackning. Ser du menyn men kan inte markera texten med muspekaren, finns den inte som text.

Skriv menyn för frågan, inte bara för rätten

Att lägga upp menyn som text är steg ett. Steg två är att den ska besvara det gästen faktiskt frågar om, vilket sällan är rättens namn.

• Märk ut allergier och kost per rätt: glutenfri, laktosfri, vegansk, nötter. Det är den vanligaste frågan av alla.
• Skriv ut om en rätt kan anpassas – "kan göras glutenfri" är ett eget svar och nästan aldrig utskrivet.
• Ange kökstyp med ord folk använder: nordiskt, italienskt, husmanskost, fine dining, street food.
• Skriv ut prisnivå i text, minst som intervall för varmrätt. "Varmrätter 165–265 kr" besvarar en fråga ett kuvertpris inte gör.
• Beskriv tillfällena stället passar för: affärslunch, barnkalas, date, stor sällskap, sent på kvällen.
• Ange lunchtider och om lunchmenyn skiljer sig från kvällsmenyn.

Allergimärkningen förtjänar en varning. Skriver du ut att en rätt är glutenfri tar du ett ansvar, och en gäst med celiaki kan bli sjuk av ett slarvigt påstående. Skriv bara ut det du faktiskt kan stå för i köket, och var tydlig med skillnaden mellan "glutenfri" och "tillagad i ett kök som hanterar gluten". Fel åt det farliga hållet är värre än ingen uppgift alls.

Strukturerad data för restaurang

Schema.org-typen `Restaurant` har fält som passar just de här frågorna: `servesCuisine` för kökstyp, `hasMenu` för att peka ut menyn, `acceptsReservations` för bordsbokning, `priceRange` för prisnivå och `openingHoursSpecification` för tider. Det finns även `Menu` och `MenuItem` för menyn i sig, men de är mer arbete och färre använder dem.

Ordningen spelar roll: markup på en meny som inte finns som text hjälper ingenting. Gör menyn läsbar först, märk upp den sedan. Det är den vanligaste felprioriteringen i det här sammanhanget – man beställer strukturerad data av en byrå medan menyn fortfarande är en JPEG.

Vanliga frågor

Vi byter meny varje vecka. Måste vi uppdatera sajten varje gång?

Nej. Lägg upp den fasta delen som text och beskriv den växlande delen i ord: "veckans fisk och två säsongsrätter byts varje vecka". Det ger ett svar på vad stället är för sorts krog utan att kräva veckovis redigering.

Räcker det att menyn finns på vår Facebook- eller Instagramsida?

Sällan. Menyer där ligger nästan alltid som bilder, och innehållet på sociala plattformar är dessutom olika tillgängligt för olika tjänster. Din egen sajt är den enda källa du kontrollerar fullt ut.

Vår meny ligger i vårt bokningssystem. Räcker det?

Beror på om systemet renderar menyn som text på en adress som går att hämta, eller bygger den med skript i webbläsaren. Testa genom att öppna sidan och försöka markera en rätt med muspekaren – går det inte att markera texten finns den sannolikt inte att läsa.

Ska vi skriva ut priser i menyn på webben?

Ja, åtminstone som intervall. Prisnivå är en av de vanligaste sakerna en gäst vill veta i förväg, och en meny utan priser lämnar den frågan obesvarad.