1. What this policy covers
This is how Menuraq answers support requests from restaurants, riders and guests. It covers what happens when something goes wrong with an order, a delivery, a payment, a device or an account. It does not replace the Terms of Service or a restaurant’s own refund policy.
Support is submission-first. You send us the problem with the information you already have; we reply by email, SMS or inside the app. There is no open chat window to wait in. A live session is only opened by an agent when a problem cannot be described in writing.
2. First reply and resolution targets
These are targets, not guarantees. A target is the window we set ourselves so you can plan; the clock pauses while we are waiting on information only you can give us. Every request gets a reference (for example S-01024) that you can quote when you follow up.
| What happened | Who asks | First reply | Resolved |
|---|---|---|---|
| Data requestCritical | Guests, Restaurants | 1 day | 30 days |
| Delivery stuckHigh | Guests, Restaurants, Riders | 5 minutes | 45 minutes |
| Delivery failedHigh | Guests, Restaurants, Riders | 10 minutes | 45 minutes |
| Device offlineHigh | Restaurants | 10 minutes | 1 hour |
| Order cancelled by the merchantHigh | Guests, Restaurants | 10 minutes | 2 hours |
| Order not receivedHigh | Guests, Restaurants | 10 minutes | 1 hour |
| Printer offlineHigh | Restaurants | 10 minutes | 1 hour |
| Charged twiceHigh | Guests, Restaurants | 15 minutes | 1 day |
| Payment failedHigh | Guests, Restaurants | 15 minutes | 1 hour |
| Refund not receivedHigh | Guests, Restaurants | 15 minutes | 1 day |
| Account accessHigh | Guests, Restaurants, Riders | 30 minutes | 2 hours |
| Subscription payment failedHigh | Restaurants | 1 hour | 1 day |
| Order lateNormal | Guests, Restaurants | 15 minutes | 1 hour |
| Order wrong or incompleteNormal | Guests, Restaurants | 30 minutes | 4 hours |
| Staff locked outNormal | Restaurants | 30 minutes | 2 hours |
| Rider gets no offersNormal | Riders | 1 hour | 4 hours |
| Booking issueNormal | Guests, Restaurants | 2 hours | 1 day |
| Menu import failedNormal | Restaurants | 4 hours | 2 days |
| Rider asks about earningsNormal | Riders | 4 hours | 2 days |
| Something elseNormal | Guests, Restaurants, Riders | 4 hours | 3 days |
A late target is not a reason to open a second request. It is a reason to reply to the first one: the reference keeps the history, the agent and the cause together.
3. Who fixes what
Your restaurant fixes the things that happen inside your business: menu content, prices, opening hours, staff access, kitchen process, and a printer or router on your own network. Menuraq fixes the platform: order records, delivery dispatch, payments, refunds it processed, accounts, and the Menuraq apps.
If a request is really a restaurant decision, we will tell you and hand it back with the reason. We will not change your menu, your prices or your staff on your behalf from a support case.
4. Payments, refunds and chargebacks
A refund is only promised once it has actually been sent. A case resolution that says “refunded” means the refund was issued and accepted by the payment provider, not that it was requested. Card and mobile-money providers usually settle a refund within 5–10 business days; that delay is the provider’s, and we will tell you which stage the refund is at.
A duplicate charge is checked against the provider before anything is reversed. A chargeback is not a support preference: it is a bank process, and Menuraq answers it with the order and delivery evidence it holds.
5. Riders
A rider reports what happened to a delivery from the delivery screen. The report is not a negotiation: Menuraq decides whether the job stays with the rider or goes back to the pool, and the app states that consequence before the rider confirms. Handing a delivery back before pickup releases it without a fee; handing it back after pickup is treated as a failed delivery and an agent reviews it.
Rider earnings questions are answered from the recorded deliveries and settlements. A missing earning is investigated; it is not adjusted on the strength of a message alone. Rider accounts and device pairing problems follow the same first-reply targets as any other request.
6. Escalation
If a request is not moving, reply to the same case and ask for an owner review. The case is then flagged for the platform owner, who is the only person who can finish it. Opening a second case splits the history and makes the review slower, not faster.
Urgent safety issues — a rider in danger, a threat, or suspected fraud — should be reported through the same case with “urgent” in the description. Do not wait for a reply before contacting the emergency services where someone is at risk.
7. Data, privacy and account access
A request to export or delete personal data is answered by the platform owner, and identity is confirmed before anything is sent or erased. Support agents can see the records needed to answer a case; they cannot browse customer data for another purpose.
Account access requests are verified against the account’s owner. We will not unlock an account on the word of someone who cannot prove they own it.
8. How to reach us
Restaurants: Dashboard → Help. Riders: the delivery screen or the rider support screen. Guests: the help form, the order’s help link, or the contact address on the receipt. You can check a filed request at help/status with its reference and the email you used.
Include the order number, the branch, and what you expected to happen. Those three facts are what let an agent act on the first reply instead of asking for them.
Response targets are derived from the same playbooks the support queue runs on. The table above is the binding list; the summary elsewhere is a convenience.