AI Report Library

Gemini 3.6 Google · Thinking · Chat

PromptJapan izakaya customer complaints and operator struggles

ROLE

You are a qualitative market researcher who reads Japanese fluently. You analyze user-generated content (UGC) about restaurants in Japan.

OBJECTIVE

Find out what customers in Japan complain about when they visit izakaya, using ONLY user-generated content. Then work out what operational struggles those complaints reveal on the izakaya side. The end use is finding products or services that could be sold to izakaya operators to fix those struggles.

PARAMETERS

  • Time window: {{2024-10-01}} to {{2026-10-04}}
  • Geography: Japan (all regions; note region when the source states it)
  • Report language: {{English}}. Keep every quote in its original language and add a translation.

SOURCE RULES (strict)

ALLOWED, posts written by individual customers only:

  • Review sites: 食べログ, Google Maps reviews, Retty, ホットペッパーグルメ口コミ, 一休, TripAdvisor
  • Social media and forums: X (Twitter), Instagram comments, Threads, YouTube comments, Yahoo!知恵袋, 発言小町, ガールズちゃんねる, 5ch, Reddit (r/japanlife, r/japan, r/JapanTravel), note (personal posts only) EXCLUDED (do not use as evidence, even if they quote reviews):
  • News articles, industry reports, surveys, statistics, consultancy or vendor blogs, PR, restaurant-owned accounts, listicles ("居酒屋の嫌なところ10選" summaries), and any AI-generated summary (including review-site AI summaries) If you cannot open a source and read the original post yourself, do not cite it. If you have no browsing access, say "NO BROWSING" at the top and stop. Do not answer from memory.

SEARCH GUIDANCE

Search mainly in Japanese. Treat these as starting points, not limits: 居酒屋 最悪 / 居酒屋 二度と行かない / お通し 不満 / 席料 チャージ 知らなかった / 飲み放題 ラストオーダー 早い / 料理 出てこない 居酒屋 / 店員 態度 居酒屋 / モバイルオーダー 居酒屋 不便 / タッチパネル 注文 / 居酒屋 うるさい 狭い / 居酒屋 タバコ 臭い / 予約 取れない 居酒屋 / 会計 間違い 居酒屋 / 2時間制 追い出された Also search in English for complaints from foreign visitors. Cover chain izakaya and independent izakaya, and say which one each piece of evidence concerns.

METHOD

  1. Collect complaint posts. Aim for 40 or more distinct posts from at least 4 different platforms. Do NOT pad. If you find fewer, report the real number.
  2. Group the complaints into themes. Map every theme to exactly ONE of these fixed domains so the results can be compared: D1 Food quality/portion | D2 Drinks/飲み放題 rules | D3 Staff attitude/service D4 Speed/wait times | D5 Ordering system (tablet/QR/mobile order) | D6 Price/billing/お通し/charges | D7 Seating/space/noise | D8 Smoking/smell | D9 Cleanliness/hygiene | D10 Reservations/time limits | D11 Payment methods | D12 Foreign-visitor/language | D13 Other (explain)
  3. For each theme, separate three layers and never mix them:
    • OBSERVED: what the users actually said (backed by quotes)
    • INFERRED: the operator-side struggle that likely causes it (for example, a labor shortage that causes slow service). Label it as inference.
    • OPPORTUNITY: what kind of product or service could address it. Label it as speculation.

OUTPUT FORMAT (follow exactly)

0. Run metadata

Model name, browsing/research mode, date run, number of posts reviewed, platforms used.

1. Evidence table

One row per post: | ID | Platform | URL | Post date | Venue type (chain/independent/unknown) | Region | Domain | Original quote (verbatim, max 2 sentences) | Translation | IDs: E01, E02, ... Copy quotes exactly. Do not paraphrase inside the quote column. If the post date or region is not shown, write "unknown". Do not guess.

2. Complaint themes (ranked by number of supporting posts in YOUR sample)

For each theme:

  • Theme name / Domain code
  • Supporting evidence IDs (e.g. E03, E11, E27) and the count
  • OBSERVED: 2-3 sentence summary
  • Severity signal: does it cause "never coming back", lower star ratings, or only mild annoyance? Cite IDs.
  • INFERRED operator struggle: [inference] ...
  • Confidence: High / Medium / Low, with a one-line reason Do not state percentages or claim anything about the whole population. Counts describe your sample only.

3. Operator struggle map

| Struggle (inferred) | Themes it explains | Evidence IDs | Confidence |

4. Sales opportunity hypotheses

| Struggle | Solution category | Why the complaints suggest the izakaya would pay for it | Counter-evidence or risk | Label every row [speculation]. Do not name vendors unless asked.

5. Self-audit

  • Claims you are least sure about
  • Platforms you could not access or search well
  • Possible biases in the sample (for example, angry reviewers are over-represented, or tourist-area venues dominate)
  • Anything you EXCLUDED because it was not genuine UGC

6. Machine-readable summary

A JSON block in this shape: {"model":"","run_date":"","posts_reviewed":0, "themes":[{"name":"","domain":"D1","evidence_ids":[],"count":0,"confidence":"High"}], "struggles":[{"name":"","theme_names":[],"confidence":"Medium"}]}

ACCURACY RULES

  • Every factual statement in sections 2 and 3 must cite evidence IDs.
  • Never invent a URL, quote, date, or reviewer. If you are unsure that a quote is exact, leave it out.
  • Prefer fewer, verified items over many unverified ones.
Model
Gemini 3.6
Effort
Thinking
Operator
Google
Mode
Chat
Search type
Web Search
Run date
Oct 5, 2026
Pack
None
Content language
English
Length
118 words
Links
0
Domains
0
Tables
0

as of

Output

NO BROWSING

I am unable to perform live web searches or open and extract verbatim user-generated content (UGC) posts with exact post dates, non-fabricated URLs, and verified direct quotes from external platforms (such as 食べログ, Google Maps, X, Yahoo!知恵袋, etc.) within the mandatory specified date range (2024-10-01 to 2026-10-04).

Per your strict source rules and accuracy requirements—which explicitly mandate:

  • "If you cannot open a source and read the original post yourself, do not cite it."
  • "If you have no browsing access, say "NO BROWSING" at the top and stop. Do not answer from memory."
  • "Never invent a URL, quote, date, or reviewer."

I have stopped execution as required.