Support and feature requests from the admin

Write requests that support can understand and act on quickly.

Operations

When something in your store is not behaving the way you expect, or you wish a screen could do one more thing, the fastest path to a fix is a clear written request the support team can read once and act on. Most slow replies are not the team being slow; they are a back-and-forth caused by a request that says "the orders page is broken" with no order number, no screenshot, and no sense of what you actually tried to do. A few extra lines from you the first time saves a day of "can you send us more details" later.

This lesson is only about writing that request well from inside your admin, whether it is a bug you hit or a feature you want added. It is not about handling a live outage where the store is down and money is on the line, and it is not about asking for a whole new app or integration. Both of those have their own playbooks linked at the end. Here we stay on the craft of one good message: what to include, how to describe the problem so someone else can see it, and what to attach so the team does not have to guess.

What a request that gets acted on fast actually contains

Support reads dozens of messages a day, so a request that answers their first three questions before they ask wins. Build every request around these parts:

  • One clear sentence of what you were trying to do. "I was confirming a cash-on-delivery order for a customer in Giza" tells the team the context instantly. Lead with the goal, not the frustration.
  • What you expected versus what actually happened. Spell out both. "I expected the order status to change to confirmed; instead the page showed an error and the status stayed on pending." The gap between expected and actual is the whole bug in one line.
  • The exact identifiers involved. Order number, product name or SKU, customer name, the discount code, the date and rough time it happened. A request with the real order number is acted on in minutes; one without it sits in a queue waiting for a reply.
  • How often it happens. Once, every time, or only on certain orders? "It happens on every COD order over 5,000 EGP but normal orders are fine" points the team straight at the cause.
  • The impact in plain terms. Is this blocking you from shipping today, or a small annoyance you can work around? Honest impact helps the team order the work correctly.

Describe the problem so someone else can reproduce it

The single most useful thing you can give support is a path they can walk themselves. A team that can reproduce a problem can fix it; a team that cannot is stuck guessing. Write the steps the way you would tell a new staff member:

  1. List the steps in order, numbered. "I opened the order, clicked confirm, then the page froze." Three short steps beat one long paragraph.
  2. Say where you were when it happened. Were you on the orders screen, the product editor, checkout as a test buyer, the mobile app, or a browser on your laptop? The same action can behave differently in each place.
  3. Note your device and connection. Phone or computer, which browser, and whether you were on mobile data or Wi-Fi. Egyptian merchants often work from a phone on the go, and some issues only show up there.
  4. Copy the exact error text. If a red message appeared, type it out word for word or screenshot it. "It said something went wrong" is far weaker than the literal message and any reference code shown with it.

If you cannot reproduce it on demand, say so honestly and give the time window it happened in. Even "it failed twice this morning around 10am" lets the team line your report up against their logs.

What to attach and how to set priority

Attachments turn a description into proof, and a clear priority tells the team how to slot your request. A screenshot of the actual screen, with the error visible and the order or product in frame, is worth more than three paragraphs. A short screen recording is even better for something that happens mid-action, like a button that does nothing when tapped. Avoid sending only a photo of your screen taken with another phone when a proper screenshot is possible, and never paste a customer's full card details or any sensitive personal data into a request.

When you set priority, be honest and specific so the queue stays trustworthy:

  • Urgent is for something blocking orders or payments right now, where every hour costs you sales — a rush before a Ramadan weekend, for example.
  • Normal is for a real problem that has a workaround, like a report that loads slowly but still loads.
  • Low or feature is for "it would help if the page could also do this." Frame a feature request as the outcome you want and why: "If I could filter orders by governorate, I could batch shipments per courier zone and cut my packing time." The why is what helps the team weigh it against everything else merchants ask for.

A short, specific, well-attached request is the cheapest investment you can make in getting unblocked quickly, and it builds the kind of track record that gets your feature ideas taken seriously.

Related lessons