DineDrop
DineDrop Admin

Operations Centre

Standard procedures for resolving exceptions consistently and protecting customers, restaurants, riders and DineDrop.

Back to command centre

Required incident record

For every exception, record: order number, date/time, issue category, current status, customer contact, restaurant, rider, payment method, evidence, responsible party, decision, refund/adjustment amount, administrator and completion time.

Failed or unverified bank-transfer payment

Trigger: Receipt is missing, unreadable, duplicated, altered, does not match the amount, or payment cannot be found.

Owner: DineDrop admin

Service target: Review before restaurant acceptance whenever possible.

  1. Place the order on payment hold; do not ask the restaurant to prepare it.
  2. Compare order amount, transfer reference, receipt time, sender details and DineDrop bank activity.
  3. Contact the customer once for a clearer receipt or correction.
  4. If verified, mark payment verified and release the order to the restaurant.
  5. If not verified within the operating window, cancel as payment failed and record the reason.
  6. Flag repeated false or duplicated receipts for account review.

Restaurant rejects an order

Trigger: Restaurant cannot prepare the order because of closure, sold-out items, equipment failure or capacity.

Owner: Restaurant first response; DineDrop final resolution

Service target: Restaurant should accept or reject promptly.

  1. Restaurant selects reject and gives a short reason.
  2. DineDrop contacts the customer and offers an agreed substitute or cancellation.
  3. For cancellation, refund verified bank-transfer payments in full.
  4. Restore any valid promotion where practical.
  5. Record avoidable rejection against restaurant performance and request menu/availability correction.

Customer cancellation

Trigger: Customer asks to cancel before delivery.

Owner: DineDrop admin

Service target: Respond quickly and check the current preparation status.

  1. Before restaurant acceptance: cancel and refund verified payment in full.
  2. After acceptance but before preparation: ask the restaurant whether costs were incurred.
  3. During preparation or after ready: cancellation is reviewed case by case; food cost may be non-refundable.
  4. After rider pickup: cancel only for safety or exceptional operational reasons.
  5. Record who authorised the cancellation, refund amount and responsibility.

Refund processing

Trigger: Admin approves a full or partial refund.

Owner: DineDrop finance/admin

Service target: Confirm the decision promptly and process according to the published policy.

  1. Verify order number, customer identity, payment amount and refund reason.
  2. Set refund as pending and record full or partial amount.
  3. Obtain verified bank details through a secure support channel when required.
  4. Process the transfer and save the refund reference or proof.
  5. Mark refund completed and notify the customer.
  6. Allocate the cost to DineDrop, restaurant or rider according to verified responsibility.

No rider available

Trigger: Order is ready but no approved rider can collect it.

Owner: DineDrop dispatch

Service target: Begin escalation immediately when the restaurant marks ready.

  1. Check all online and approved riders and call the nearest available rider.
  2. Notify the restaurant not to remake or release the order to an unverified person.
  3. Update the customer with a revised estimate.
  4. If delay risks food safety or unacceptable quality, offer cancellation/remake/refund options.
  5. Record the rider shortage for staffing and peak-hour planning.

Delayed delivery

Trigger: Preparation, assignment, pickup or travel exceeds the expected time.

Owner: Responsible stage owner, coordinated by DineDrop admin

Service target: Contact the affected party before the customer has to complain.

  1. Identify whether the delay is restaurant, dispatch, rider, weather, traffic or customer access.
  2. Update the tracking status and revised estimate.
  3. Call the restaurant or rider and agree on the recovery action.
  4. Notify the customer and offer a reasonable remedy for severe avoidable delays.
  5. Do not mark picked up or delivered early to improve statistics.
  6. Record the cause and review repeat delays weekly.

Customer complaint

Trigger: Complaint about food, missing item, payment, rider conduct, delay or delivery.

Owner: DineDrop support/admin

Service target: Acknowledge promptly and keep one owner until closure.

  1. Record order number, customer contact, complaint category and requested remedy.
  2. Preserve receipt, chat, photographs, status timeline and call notes.
  3. Contact the restaurant or rider without sharing unnecessary customer data.
  4. Decide replacement, credit, partial refund, full refund or no refund using evidence and policy.
  5. Communicate the decision respectfully and record completion.
  6. Escalate safety, harassment, fraud or serious food-quality allegations immediately.

Rider cash settlement

Trigger: Rider collected cash from one or more completed cash orders.

Owner: Rider and DineDrop cashier/admin

Service target: Settle at the end of the rider shift or daily cutoff.

  1. Generate the rider’s completed cash-order list and total cash collected.
  2. Calculate rider earnings separately; do not silently offset unexplained shortages.
  3. Rider hands over the required cash or transfers it to the approved account.
  4. Admin counts/verifies the amount and records settlement date, method and reference.
  5. Both parties confirm any rider earning paid, retained or carried forward.
  6. Record shortages immediately; investigate before new cash assignments are issued.

Daily launch checklist