Collect enough evidence to identify the failed workflow without sending credentials or customer-sensitive data. Reproduce the problem once when it is safe, record the result, and stop repeating actions that could create duplicate orders, payments, messages, refunds, or live-site updates.
Record the operating context
- Tenant or company name and the selected store or location.
- Your role and the affected product area, without sharing credentials.
- Device or Station name, role, platform, app version, and heartbeat state when hardware is involved.
- Page name and public or application URL. Remove access tokens and private query parameters.
- Local date, time, and timezone of the failure.
- The exact button or action used and the complete visible error or status text.
Record safe identifiers and states
Use the minimum identifiers needed for the workflow:
- POS order number or order UUID, store order ID, reservation reference, invoice number, device ID, print-job ID, or deployment/update step name.
- Current order, payment, reservation, device, sync, or publication state.
- The expected result and the result that actually appeared.
- Whether the same problem affects one record, one device, one store, or every location.
- The last known successful attempt and any configuration change immediately before the problem.
A screenshot is useful when it shows the product page, visible status, and timestamp. Crop or redact unrelated customer names, contact details, addresses, and financial information.
Never send secrets
Do not include passwords, POS PINs, MFA or recovery codes, password-reset links, API keys, database URLs, enrollment claims, device tokens, session cookies, authorization headers, payment credentials, full card numbers, CVC, or bank details.
Do not copy a full browser network request or console dump without reviewing it. Headers, URLs, payloads, and logs can contain tokens or personal data. Send only the specific sanitized error and identifiers requested by support.
Add workflow-specific proof
- Payment: provider or Ellich payment state, amount, order reference, and whether the terminal displayed approval. Never include card data.
- Printer: printer name, route, connection type, test-job ID, queue state, and last successful print.
- Station: role, Main POS link, network state, runtime message, retry count, version, and heartbeat.
- KDS: order number, time fired, selected prep station, route, ticket state, and connection indicator.
- Online order: store order ID, link lookup result, import counts, POS order state, and payment state.
- Website: exact public URL, changed field, each live-update step result, warning, cache result, and fresh-session check.
- Reservation: reservation reference, location, customer-visible reservation state, deposit state, and quote or payment reference without payment credentials.
Write a useful support request
State the symptom first, then include context, one reproduction, expected versus actual result, safe identifiers, and the operational impact. Mention any safe workaround already used. Do not describe a guessed root cause as fact.
If service is stopped across a location, say which workflows are unavailable and which remain safe. If a payment may have succeeded, pause duplicate collection attempts until the recorded payment state is reconciled.