Safe information to send with a support request

A good support request is specific enough to reproduce the problem and free of anything that would put the restaurant at risk. This page is the checklist for both halves of that.

Do these five checks first

They resolve a large share of reports and, when they do not, they turn a vague message into a precise one.

1. Reproduce the problem in a private browser window, signed out.
2. Reload the page once, to rule out a cached copy.
3. Note whether it also happens signed in.
4. Note the scope: one item, one category, one menu type, one language, or everything.
5. Note what changed just before — an import, a settings change, a new language, a new photo, a plugin update.

What to send

Where

• The exact public URL where the problem is visible.
• The menu type, the category and the item involved.
• The language, if the site is multilingual.
• Which restaurant site, if the account covers more than one.

What

• What you expected to see.
• What you saw instead.
• The exact wording of any message on screen.
• Whether it happens signed out, signed in, or both.

How

• The steps that reproduce it, in order.
• The device and browser, especially when it only appears on a phone.
• When it started, and what changed at that time.

Evidence

• A screenshot of the public page.
• A screenshot of the admin screen showing the value you saved.
• For import problems, two or three sample rows with the exact text you pasted.

What never to send

• Passwords, one-time codes, or login links.
• Hosting, database, email or CDN credentials.
• Screenshots that show account details, billing pages or a password manager.
• Personal data about guests or staff.
• Supplier contracts, cost prices, margins or other commercial data unrelated to the fault.
• Full server logs without reviewing what is in them.

If a message asks you for anything on this list, stop and confirm through your usual service contact before replying. A genuine request will not need your password.

Preparing a screenshot safely

1. Capture only the region that shows the problem.
2. Crop out the browser's address bar if it contains a private token.
3. Crop out the admin bar and the account name.
4. Check the corners of the image for open tabs, notifications and file names.
5. Never annotate a screenshot with credentials "for convenience".

A template you can copy

Site / restaurant:
Public URL:
Menu type / category / item:
Language:

Expected:
Actual:
Message on screen (exact wording):

Signed out: yes / no
Signed in: yes / no
Private window, reloaded once: yes / no

Steps to reproduce:
1.
2.
3.

Started: (date/time)
Changed just before:
Attached: (screenshots, sample rows)

What makes a report resolvable

The single most useful sentence is the one that separates the layers: "It is correct in the admin screen and wrong on the public page, signed out, after a reload." That one line rules out the content, points at a cache or a generated file, and usually shortens the exchange to a single reply.