The system that owns a delivery menu image is the one your team treats as the authoritative place to store and update it. That might be your POS, a menu management tool, or the delivery channel itself. Do not assume that the system holding the item name also controls its photo.
When a channel rejects an image, the practical question is whether someone can see the rejection, correct the source, and get an acceptable image published. Before buying an integration, ask the vendor to show that path for each channel you use. Also agree on what guests should see while a replacement is pending.
Set image requirements around your workflow
Start with the places where guests actually see your menu: your direct ordering site, each delivery marketplace, and any other ordering screen in scope. A photo that looks good on a large menu editor may be cropped differently on a phone. Check the guest-facing view on the devices your customers are likely to use, not just the back-office preview.
Next, draw the path for one item. Where is its photo uploaded? Does the integration send the image itself, a reference to it, or no image at all? Can a channel user replace the photo locally? If so, does a later menu update overwrite that replacement? These answers determine whether your team has one reliable source or several versions to maintain.
Assign two responsibilities. The image owner decides which file represents the item and has permission to change it. The channel owner checks whether the correct image appears on each ordering channel and follows up on failures. In a small restaurant, one person may do both jobs. The roles still need to be clear when a photo is rejected on a busy Friday.
Include the person who maintains the menu in the buying conversation. Ask how the team will find an item by its stable item ID, rather than relying on a name that may change or appear more than once. If the same dish has different sizes or variants, decide which image belongs to each record.
Image ownership matters during launch, but also after a recipe change, a seasonal menu update, or a location-specific substitution. Decide who confirms that a replacement photo still represents what the guest will receive, and keep a source file the restaurant is authorized to use.
Compare ownership and channel requirements
For every channel, ask for its current image requirements and how they are enforced. Useful details include accepted file types, dimensions, file size, aspect ratio, cropping behavior, and any content restrictions. Requirements can differ by channel and can change, so record when they were confirmed and who provided them.
Then separate three questions that are easy to mix up:
- Storage: Where is the original file kept, and who can access it?
- Control: Which system supplies the image that a guest sees, and can another system override it?
- Approval: Who or what accepts the image for a particular channel, and how is a rejection reported?
Ask whether an image update travels independently or only with a broader menu publish. Find out whether the channel can keep showing an older image, show no image, or require a manual change while the new file is reviewed. Treat the answer as channel-specific until it is demonstrated for your setup.
Fleksa's integration directory distinguishes live connections from connections available on request. US marketplace examples include DoorDash, Uber Eats, and Grubhub, subject to setup and availability. Ask which connections apply to your locations and whether image handling is supported for each one. If your restaurant POS is part of the proposed flow, ask which system wins when the POS and a channel have different photos.
For an existing POS integration or another provider, request the same walkthrough rather than comparing feature names alone. A connection that sends menu items does not, by itself, establish how images are sent, reviewed, or corrected. Mark an unsupported image flow as a known limitation; mark an unproven flow as unknown until you have an answer.
Build an image register and run a safe test
An image register gives the operator and vendor one place to track what should happen. Keep a row for each item and channel combination. At minimum, record the item ID, source file and owner, channel constraints, approval status, expected and observed result, fallback, and the person responsible for the next action. A file path or asset ID should point to the actual source, not just a copy someone downloaded from a channel.
The following register is hypothetical. Its channel labels and requirements are examples for planning, not rules for any named marketplace. The owner would replace them with the requirements and results for the restaurant's actual setup.
| Item and channel | Source and constraint | Approval and result | Fallback and owner |
|---|---|---|---|
| B17, bowl; Channel A | b17-bowl.jpg; menu manager owns source. Channel accepts the file type and dimensions in this scenario. | Expected: current photo appears. Observed: current photo appears in the simulated channel view. Pass. | Keep source available; menu manager checks the next update. |
| B17, bowl; Channel B | Same source; scenario constraint rejects its dimensions. | Expected: rejection is visible. Observed: no rejection notice shown in the simulation. Fail for the notice requirement. | Channel manager checks status manually and requests a compliant replacement; vendor explains the missing notice. |
| S04, soup; Channel A | s04-soup.jpg; location manager owns source. Image transfer for this connection is not yet demonstrated. | Expected: current photo appears. Observed: not tested. Unknown. | Use a channel-local upload if permitted; location manager confirms ownership and retests. |
The table separates the image outcome from the communication outcome. In the second row, the problem is not merely that the file fails a channel constraint; the expected notice is also missing. The manual status check is a temporary workaround, not proof that the integration handles rejection automatically. In the third row, a local upload is only a candidate fallback until the channel permits it and the team knows whether a later update can overwrite it.
Run the scenario in a sandbox or other isolated environment with the vendor. Begin with a valid image and verify that the right item receives it in the simulated guest view. Change the source image and check whether the update reaches each in-scope channel. Then use a file that violates a known test constraint and record the rejection, notification, responsible person, and replacement steps.
For each step, write the expected result before the demonstration and the observed result afterward. Save a reference to the view or status shown, along with the date and configuration. Check the crop and item association as well as the upload status: an accepted photo attached to the wrong dish is still a failure for the restaurant.
Keep image practice separate from a live service pilot. A simulation must not create a real card charge, guest message, or courier dispatch. If the vendor cannot safely simulate a channel response, record that case as unknown and agree on another way to verify it. A later live pilot, if the restaurant chooses one, needs its own controlled scope and approval; it is not a substitute for safe practice.
Decide what happens after rejection
Use three decision labels. Pass means the agreed result was observed in the stated setup. Fail means an agreed requirement did not work. Unknown means the result has not been established. A channel that does not support image transfer can be an acceptable documented limitation if the restaurant agrees to a workable alternative; it should not be marked as a successful transfer.
For every failure or unknown, assign a follow-up before signing or rollout. The follow-up should name the owner, the action, the date for a response, and the evidence needed to close it. For example, the vendor might demonstrate a rejection notice; the restaurant's channel manager might confirm that a local replacement is allowed; and the menu owner might provide a correctly sized source file.
Agree on the guest-facing fallback in advance. Depending on what the channel permits, it might be an approved replacement image or a menu listing without a photo. Do not assume the old image disappears or remains visible. Ask who approves the fallback and how long the team can operate with it. If a manual upload is necessary, write down where it happens and whether the next integrated update could undo it.
Set a retest when the vendor changes the configuration, the restaurant replaces the file, or the channel changes a relevant requirement. The same item and channel should be checked again so the result can be compared with the original failure. Keep exceptions with the menu records where the people making updates can find them.
Bring your register to a restaurant management software demo. Ask the vendor to demonstrate a valid image, a rejected image, the notice, and a replacement for your proposed channels. Leave with a named owner and a follow-up date for each open case.
Frequently asked questions
Does the POS always own delivery menu images?
No. The POS may be the source, but a menu tool or channel may control the image instead. Ask where changes are made and whether a later update can overwrite a channel-local photo.
What should happen when a delivery channel rejects a photo?
The team needs a way to identify the rejection, assign a correction, and confirm what guests see while it is unresolved. Ask each vendor to demonstrate the notice and replacement process for the channel in scope.
Can an item publish without an image?
That depends on the channel and setup. Confirm whether a listing without a photo is allowed, whether an older photo remains visible, and who must approve the fallback.
