Automate Amazon review requests by assigning one request process to each order, using Amazon’s standard Request a Review message, and checking which eligible orders were actually processed. Before activating a campaign, remove overlapping requests from manual routines, older automations and customer-service templates. After activation, reconcile orders against request status rather than assuming an active campaign has reached every buyer.
For sellers in the US Amazon store, this starts with a specific boundary: Amazon allows the Request a Review feature once per order, between 5 and 30 days after delivery. The email asks for both a product review and seller feedback. Automation can reduce repetitive work and missed requests; it cannot guarantee that customers will respond or leave a particular rating. See Amazon’s Request a Review guidance.
The workflow below is an operational recommendation for setting up and checking that process. It is not an Amazon-required audit format or a guarantee of compliance. Check the current rules and the eligibility shown for the actual order before sending.
What are you automating when you request an Amazon review?
A product review describes the item: its quality, usefulness or suitability. Seller feedback describes the buyer’s experience with the seller. They are different records, even though Amazon’s standard request asks for both in one email. A seller-feedback alert therefore does not tell you that a product review was posted, and a new rating on a listing does not prove a particular campaign caused it.
Choose a clearly defined job for the automation: request an honest assessment from eligible buyers using the standard Amazon message. Keep necessary customer-service work in its own process. A request for information needed to resolve a delivery problem has a different purpose from a review solicitation.
Amazon recommends its Request a Review feature instead of writing a request through email or Buyer-Seller Messaging. Its reviews and communication FAQ permits a review request through Buyer-Seller Messaging only if you have not used Request a Review for that order. Do not treat different sending channels as separate review-request allowances.
This matters when someone says, “We only ask once.” The review campaign may ask once, the support template may ask once, and an assistant may click the button once. The buyer’s order is the unit that needs one coordinated decision across those routes.
Who owns the request for each order?
Start with an inventory of every place your business asks for reviews or feedback. Include manual Seller Central work, browser tools, review automations, customer-service signatures, product instructions and packaging. The immediate goal is to remove overlapping order-level requests, while checking any remaining solicitation against Amazon’s policies.
Create a short operating record with the account, marketplace, product scope, sending route, timing, owner and status. This can be a spreadsheet or an internal checklist. Do not assume your messaging tool supplies a cross-tool request register.
| Request route | Control to establish | Evidence to retain |
|---|---|---|
| Main automation | One owner and a defined product/marketplace scope | Campaign settings and activation record |
| Manual requests | An exception process, rather than a parallel daily task | Order ID, request route and result |
| Older campaigns | No overlapping active review solicitation | Campaign inventory and reviewed status |
| Support templates | No automatic review request added to service replies | Reviewed template text |
For example, a US campaign might cover a defined group of products, with an operations manager responsible for exceptions. The customer-service team stops routine manual review requests for that scope. If an order needs investigation, the manager checks its history before deciding whether any action is appropriate.
Document what happens when ownership changes. A new agency, employee or automation should not inherit a blank slate for orders already handled. Keep the earlier request history and define a clean handover boundary. If historical status is unknown, investigate it before sending a catch-up batch.
Which orders should enter the campaign?
Separate three questions: is the order in your intended operating scope, is it due under your chosen schedule, and does Amazon currently allow the request? A product or marketplace filter answers the first question. It does not answer the other two.
Use neutral criteria that you can explain without referring to the buyer’s likely rating. Examples include marketplace, a specified product group and a consistent post-delivery timing rule. Do not use positive support responses, absence of complaints or a satisfaction survey to choose who gets an invitation.
Amazon prohibits seeking reviews only from customers with positive experiences and diverting negative experiences to a different feedback channel. Its product review policy makes that distinction explicit. A filter being available in software does not establish that every use of it is allowed.
Check exclusions for their real purpose. An already-requested order needs duplicate prevention. An order that Amazon marks ineligible needs no workaround. A cancellation has no completed purchase to solicit. A complaint, refund or return should not become a convenient proxy for suppressing an unfavorable review. Handle the service issue under the applicable rules and preserve neutral review-request selection.
Keep a reason beside each operational exclusion. “Already requested through the previous process” is reviewable. “Probably unhappy” signals that the selection logic needs correction. Avoid collecting unnecessary buyer details in the working record; order identifiers and the relevant status are usually enough for this check.
When should the request be scheduled?
Choose timing around a genuine opportunity to use the product, while staying inside Amazon’s allowed window. There is no single best day established for every category. A simple household item and a product requiring setup may need different neutral schedules, but a timing choice is not evidence of higher review conversion.
Be precise about the trigger. “Ten days after order,” “ten days after shipment” and “ten days after delivery” describe different schedules. Check which date the tool uses and how it handles missing data. An order placed several days before shipment can fall outside your intended post-delivery timing if you select the wrong starting event.
There is also an implementation nuance: Amazon’s Solicitations API setup guidance describes a window using its earliest and latest delivery-date fields. Do not build eligibility solely from a manually estimated date. Let the available order-level eligibility and the tool’s supported Amazon process govern whether a request can be sent.
A practical timing check uses a few ordinary orders with different fulfillment paths. Compare the marketplace date, the campaign trigger, the planned delay and the request status. Missing delivery data should remain a visible exception until it is resolved. Scheduling close to the end of the allowed window leaves less time to investigate delays; choose that trade-off deliberately.
How can you set up the process in sellerboard?
In sellerboard, open Autoresponder → Campaigns and create a campaign for the intended marketplace and product scope. Select Amazon’s standard Request a Review template, configure the trigger and delay, and review the campaign’s status before activating it. The Autoresponder guide describes Inactive, Test and Active states; saving a campaign is not the same as sending requests.
Give the campaign a name that makes its purpose and scope obvious to the next person reviewing it. A name such as “US review requests household products” is more useful than “Campaign 3.” Keep the operating owner in your internal record if the interface does not provide that field.
Review campaign priority where products overlap. The product documentation describes priority selection within the application. Treat that as a local control, not proof that manual Seller Central activity, another application or an older support message has been reconciled. The single-owner rule still needs to cover the entire business process.
Before switching to live sending, inspect the selected message, target scope and timing against representative orders. Use the available test controls for their documented purpose. A successful test message can help check configuration; it does not prove that every real order is eligible or that a customer received a request.
Also check your account’s current request allowance and expected volume. Plan limits and account conditions can affect operational coverage. Do not rely on a remembered allowance when projecting whether the next busy period will be covered.
How do you verify that automation actually ran?
Check order-level outcomes after the schedule should have run. In sellerboard, Autoresponder → Orders shows campaign assignment, status, the last sent date and the marketplace’s estimated delivery date. The Orders page documentation explains that Pending Data can mean required shipping or delivery information has not arrived. Read the status explanation rather than translating every unsent record into an error.
Use four operational categories in your own check: not due, completed, explained hold or ineligibility, and unresolved. These are suggested review categories, not a claim about the exact labels in every interface. Record the application’s original status alongside your interpretation so another person can reproduce the decision.
A “sent” record is evidence about the sending process. It is not proof that the message reached an inbox, was opened, or caused a review. Buyer preferences and Amazon’s handling also matter. Do not introduce tracking pixels to manufacture an open-rate metric: Amazon’s Communication Guidelines prohibit them in permitted messages.
When status is unclear, use the order identifier to reconcile the records. Amazon’s API interaction guidance says an API request does not flag the order in Seller Central; trying the button afterward can return an already-requested error. An apparently untouched button is therefore not reliable evidence that nobody asked.
Do not click the button merely to test whether it sends. Start with available history and eligibility. Where the records conflict, preserve the exception and investigate before allowing another route to send.
What does a useful coverage calculation look like?
Count distinct orders, not message attempts. A retry, overlapping campaign or repeated row in an export must not inflate coverage. Keep the period and cohort definition visible so that today’s newly delivered orders are not unfairly counted as missed requests.
Suppose you review 1,000 orders in a fixed cohort. Eligibility here means eligibility for the first request when each order was assessed, before any successful request consumed that opportunity. Preserve that historical basis when reconciling the cohort; an already-requested order is not currently eligible for another request. The following hypothetical counts have been reconciled and do not overlap.
| Cohort step | Orders | Treatment |
|---|---|---|
| Starting cohort | 1,000 | Same account, scope and review period |
| Not yet due | 160 | Carry forward for a later check |
| Outside the window or otherwise ineligible | 40 | Record the reason; do not force a request |
| Due and eligible cohort | 800 | 1,000 − 160 − 40 |
| Already handled by the prior manual process | 80 | Count once; exclude from automation workload |
| Remaining automation workload | 720 | 800 − 80 |
The automation record then shows 600 completed requests, 90 explained processing delays and 30 unresolved cases. Those figures total 720.
Automation completion for its assigned workload = 600 ÷ 720 = 83.3%.
Total request coverage for the due, eligible cohort = (600 automated + 80 earlier manual) ÷ 800 = 85.0%.
The remaining 120 orders require follow-up or an explained final outcome. The 90 pending cases are not completed merely because their delay has an explanation. Revisit them while they are still actionable. If some later become ineligible, preserve that movement rather than quietly removing them from the earlier report.
A raw calculation of 600 ÷ 1,000 = 60% would answer a different question and hide the handover history. Counting all attempted sends could make the process look better than it is. Define the denominator before using a percentage to judge performance.
Keep review outcomes separate. If the listing later gains reviews, those reviews may relate to different purchase dates or other sources. A coverage report establishes whether your request process operated as intended; it does not establish incremental review lift.
What should you do when requests are missing or duplicated?
For a missing request, work from the order toward the campaign. Check scope, trigger date, current eligibility, assignment, campaign state and the actual status explanation. Then inspect account connection or allowance issues if the evidence points there. Avoid changing several settings at once, because that makes the cause difficult to establish.
If the issue affects a whole product group, look for a scope or priority change. If it affects recent orders across products, examine data timing and connection status. These are diagnostic suggestions, not conclusions you can draw from an empty queue alone.
For a duplicate attempt, pause the overlapping request route and identify where ownership broke down. Preserve the relevant order IDs and sending records. Do not resend while investigating. An error showing that Amazon blocked a duplicate is useful protection, but recurring blocked attempts still reveal a process problem.
For an uncertain send result, check history before retrying. A timeout or incomplete display does not prove that the first request failed. Use the supported eligibility and status tools, or ask the service provider to investigate the specific record. Keep any actual account-policy warning in the account’s formal resolution process.
After fixing the cause, review the next eligible cohort. Confirm that the corrected configuration produces the intended outcomes and that the earlier exceptions were resolved or closed with reasons. A saved setting is an intermediate step, not the end of the check.
Which mistakes create the most avoidable risk?
Leaving the old manual routine running. Tell everyone who handles orders when the automation becomes the request owner and where exceptions should go.
Adding a review request to every service reply. Resolve the customer’s actual issue without quietly creating a second solicitation.
Selecting only likely positive reviewers. Neutral template wording does not correct biased recipient selection.
Treating every delivered order as immediately eligible. Check timing and Amazon’s actual order-level availability.
Confusing request status with delivery or response. Do not describe sent requests as opened emails, new reviews or proven sales growth.
Changing campaign settings without checking the next run. Verify the effect on real eligible orders, including any unresolved backlog.
What do sellers often ask about review-request automation?
Can I request a product review and seller feedback separately?
Amazon’s standard request asks for both together. Avoid a second solicitation for the same order merely because you want the other type of response.
Can I manually request a review when automation appears to have missed an order?
First establish that the order is eligible and has not already been requested. Check the sending history and coordinate with the automation owner. A manual request should be a controlled exception, not a parallel routine.
Should I exclude anyone who complained or returned a product?
Do not use those signals to invite only favorable reviewers. Resolve service issues appropriately and assess eligibility under the current Amazon rules without using likely sentiment as the selection test.
Does an active campaign guarantee complete coverage?
No. Coverage still depends on scope, timing, order data, eligibility and the account’s operational conditions. Reconcile the orders that should have been handled against their actual statuses.
What result should I expect from switching on automation?
The result you can verify is a more consistent request process with less manual work. Whether buyers respond, what they say and whether reviews affect future sales remain separate questions.
Reliable review-request automation gives every eligible order a clear owner and every exception a visible reason. Start with neutral selection and one coordinated request, then verify the orders behind the campaign totals. That makes the process easier to operate without promising an outcome the seller cannot control.
