AWS vs Microsoft Inbound Co-Sell Referrals: Acceptance Clocks and Triage Policy

An inbound co-sell referral is an opportunity a cloud provider’s sales team shares with you to work jointly. AWS gives you five business days to accept or reject one; Microsoft gives you 14 days to accept or decline. Let the clock run out and AWS removes the invitation from view; Microsoft archives the opportunity as expired, a terminal state. Accept everything and you owe follow-up on deals you may not want, which Microsoft’s own guidance warns against.

---

Here are the two clocks side by side, with what each cloud does when one runs out:

	AWS: ACE opportunity invitation	Microsoft: inbound co-sell opportunity
Where it arrives	The Opportunity Invitations tab in AWS Partner Central, when an AWS sales executive attaches you to an opportunity	The Inbound tab under Referrals > Co-sell opportunities in Partner Center, from a Microsoft seller or another partner
The clock	5 business days, to the acceptBy date and time in the referral’s payload	14 days
If nobody answers	The invitation expires and leaves your Opportunity Invitations tab	Archived as expired, a terminal state, and Microsoft or the sending partner is notified
What you see first	Company, website, country and industry; use case, business problem, next step, monthly recurring revenue and target close date; your AWS contacts. The customer’s contact name, title, email and phone are masked	The deal details, with Microsoft’s advice to contact the customer if you want to learn more before you respond
Declining	A rejection reason is required, and access to the opportunity is lost	Select a reason, add notes and close the deal. It is archived as declined, a terminal state, and the sender is notified
Accepting	Creates the opportunity in your account. AWS then sends the unmasked customer contacts and expects regular updates	You name the deal and set its estimated value and purchase time frame, which Microsoft uses to find you similar deals
What the cloud says about what you accept	Its CRM guide lists the factors behind AWS Sales’ recommendations to attach a partner, with no weights	Respond quickly, and be selective about the deals you accept

Auto-accept looks like the fix, and in Suger it is one switch per cloud, for AWS and for Microsoft (via Suger’s Azure Marketplace integration). But neither cloud treats an accept as free. AWS expects you to engage every referral you accept and keep it updated. Microsoft is blunter: accepting deals that aren’t a good fit “could affect the quality of the opportunities that you receive.”

So the question isn’t whether to automate. It’s which policy each queue runs, who owns it, and how fast they act. Below are three policies (manual review, auto-accept plus a triage SLA, and a decline rule), each with an owner. Buyer requests from an AWS Marketplace listing reach the same invitation queue with routing of their own, covered in answering AWS Marketplace private offer requests.

How long do AWS and Microsoft give you to accept a co-sell referral?

Five business days on AWS and 14 days on Microsoft. When the AWS clock runs out, the invitation expires and is removed from your view; when Microsoft’s runs out, the opportunity is archived as expired, a terminal state, and the sender is notified.

Work the AWS clock from the timestamp, not a count of days. AWS’s CRM guide says to accept or reject “before the acceptBy date and time specified in the payload,” and Suger backfills the invitation’s Accept By expiration date onto the Salesforce referral record, beside the partner acceptance status. AWS’s is also the shorter clock, so in a queue that holds both clouds, it sets the pace.

The other difference is what you know when you decide: on AWS you accept without the customer’s contact details, while Microsoft’s guidance for a received opportunity is to “review the details and then contact the customer if you want to learn more about their business needs.” For what happens to the record after either accept, see how co-sell works.

Does accepting every co-sell referral cost anything?

On Microsoft it can, by Microsoft’s own account. On AWS, an accept commits you to engaging the referral and updating AWS on it, and AWS publishes the factors behind its partner recommendations but not how they are weighed.

Microsoft’s referrals FAQ gives three tips for getting more co-sell opportunities:

• “Respond quickly to deals. When you respond to incoming requests promptly, your visibility is progressively increased in future partner search results.”
• “Be selective about the deals you accept. We monitor the types of deals that you accept or decline and use that information to help you find similar deals. Accepting deals that aren’t a good fit doesn’t improve your search results and could affect the quality of the opportunities that you receive.”
• “Report estimated deal sizes, closing dates, and the final status of your deals, whether won or lost.”

Speed and selectivity only pull against each other when nobody owns the queue. Auto-accept delivers the first and gives up the second, so on Microsoft it needs a triage step behind it.

Partner Center’s own reporting adds a second reason. Its referrals Summary page calculates co-sell win rate as won deals divided by the inbound deals you accepted plus your outbound deals, so every inbound deal you accept and never win lowers the rate on your own dashboard. The same page has a Referrals acceptance time widget, the distribution of how long you take to accept, which is the number a manual-review SLA should keep short.

AWS’s guidance is about what follows an accept. Its CRM guide explains where referrals come from: “The AWS Sales team receives recommendations to attach a partner to an AWS sales opportunity based on multiple factors, such as the quality of information in the solution listing, past opportunities, progress in the partnership journey, and past performance.” That’s a list of inputs with no weights attached, not a scoring rule.

What AWS does spell out is the obligation an accept creates: “You then engage with the opportunity and provide regular updates to AWS.” Its sales guide recommends a next step at each stage change, with “a specific action with a deliverable, a named owner, and a concrete date,” and notes that the next step “is used to calculate your Opportunity Quality score.” An AWS referral accepted and then ignored is an open opportunity in your own pipeline with no next step.

Which triage policy should each queue run?

One of three, chosen per cloud, each with a named owner and a backup: manual review when volume is modest and fit varies from deal to deal, auto-accept plus a triage SLA when a lapse is the bigger risk, and a decline rule for referrals you already know you won’t work. The decline rule runs alongside either of the other two.

Manual review

Manual review is a policy in which every referral waits for a named person to accept or decline it, against an internal deadline well inside the cloud’s clock.

• Owner: one queue owner per cloud, and a backup with the same access in Partner Central or Partner Center. A queue that depends on one person lapses when that person is out.
• Before accepting: check whether the account is already in your CRM with an owner or an open deal, whether the use case is one you sell, and whether the referral duplicates one you shared yourself. Then name the seller who makes first contact.
• On accept: on Microsoft, set the deal name, estimated value and purchase time frame from your review. Microsoft says the information you enter is used “to help you find similar deals in the future.”
• Fits: Microsoft queues, where selectivity is part of the provider’s own guidance, and any queue with modest volume and uneven fit.
• Risk: the clock. Manual review fails quietly, one lapsed referral at a time.

Auto-accept plus a triage SLA

Auto-accept plus a triage SLA is a policy in which Suger accepts pending referrals automatically, and a named owner reviews every accepted referral within a set time, then assigns it or closes it.

• Owner: the queue owner triages; the seller they assign owns first contact.
• Triage ends in one of two outcomes: a seller and a next step with an owner and a date, or a closed referral, as Closed Lost with a reason on AWS or as lost on Microsoft. On Microsoft, triage is also when someone reviews the deal value and purchase time frame, the fields Microsoft asks you to set when you accept.
• Fits: AWS queues with more referrals than one person reviews daily, or where invitations have already lapsed. AWS’s shorter clock is the one auto-accept protects most.
• Cost: you give up declining. Every referral you would have declined becomes one you must close, and on Microsoft each is an accepted deal counted in your win rate.

Decline rule

A decline rule is a standing list of referral types you decline on sight, with a specific reason, instead of letting them expire.

• Owner: the owner of that queue, the same business day.
• What goes on the list: duplicates of a referral you already shared, use cases your product doesn’t serve, and customers you can’t support. AWS’s own list of rejection reasons includes “Duplicate of partner referral” and “Unable to support.”
• Why decline instead of waiting: a lapse and a decline both end the referral, and on Microsoft both notify the sender, but only a decline records why. AWS says the rejection reason “helps AWS track usage patterns.”
• With auto-accept on: the rule still applies one step later, as a close at triage rather than a decline.

An example policy

An illustrative example with a fictional company: Acme sells a data security product on AWS and Microsoft. Its AWS invitations have lapsed before and its Microsoft queue is smaller, so it runs:

Queue	Policy	Owner (backup)	Internal SLA
AWS opportunity invitations	Auto-accept plus triage	Co-sell operations lead (alliance manager)	Triage within one business day of the accept
Microsoft inbound co-sell	Manual review	Microsoft alliance manager (co-sell operations lead)	Accept or decline within two business days
Known no-fits, both clouds	Decline rule	Whoever owns that queue	The same business day, with a specific reason
Failed Auto-accept runs	Accept by hand if still pending, otherwise reconcile with the referral’s status	Co-sell operations lead	Checked every business day

The SLAs are Acme’s, not the clouds’. What matters is that each one is shorter than the clock it protects, and that every row has a name against it.

How does Suger’s auto-accept work on AWS and Microsoft?

Suger accepts pending referrals on each cloud where you switch it on, and logs every attempt as an Auto-accept run under Metrics → Logs:

	AWS	Microsoft
Where you switch it on	Auto-Accept Referrals, when you edit the AWS ACE integration	Auto-Accept Referrals, when you edit the Azure Marketplace integration, once Enable Cosell is on
What it accepts	Engagement invitations still Pending and not expired	Referrals whose substatus is Pending

That leaves the queue owner three jobs:

• Check the Auto-accept runs every business day. Filter Metrics → Logs by the Auto-accept workflow type. An AWS accept that errors fails its run and isn’t retried automatically, and a red ! appears on the referral’s status tag. Inspect each failed run: if the invitation is still pending, accept it by hand before it expires; if its state has already changed, reconcile the run with the referral’s current status.
• Reach the customer the same day on AWS. The customer’s name, email and phone arrive only after acceptance. Suger’s documentation puts them at 10–30 minutes later, an observed range rather than an AWS commitment.
• Decline in your own words. When you decline an AWS invitation in Suger, the reason you type goes to AWS as written: one line of 1 to 80 printable characters.

Suger’s auto-accept settings for AWS and Microsoft cover each switch in full.

What should the queue owner check every week?

Five things: lapses, failed accepts, accepted referrals nobody has triaged, acceptance time, and what your closes and declines have in common.

• No lapses. Count AWS invitations that expired and Microsoft deals archived as expired. The target is zero; each one is a referral nobody decided on.
• No failed accepts left unresolved. Inspect each failed AWS run in Metrics → Logs. If the invitation remains pending, accept it by hand before it expires; if its state has already changed, reconcile the run with the referral’s current status.
• Nothing accepted and untriaged past your SLA. Every accepted referral has a seller and a dated next step, or has been closed.
• Acceptance time inside your SLA. On Microsoft, read the Referrals acceptance time widget on Partner Center’s referrals Summary page.
• Closes and declines reviewed. A referral type that keeps being closed at triage belongs on the decline list, and on Microsoft it’s a reason to move that queue back to manual review.

Frequently asked questions

How long do you have to accept an AWS co-sell referral?

Five business days. After that the invitation expires and leaves your Opportunity Invitations tab. The exact deadline is the acceptBy date and time in the referral’s payload, and until you accept, the customer’s contact name, title, email and phone stay masked.

What happens if you don’t respond to a Microsoft co-sell opportunity?

After 14 days, Partner Center archives it as expired and notifies Microsoft or the partner who sent it. Expired is a terminal state: you can’t edit the deal or take any further action on it.

Should you auto-accept every co-sell referral?

Not without a triage step behind it. Microsoft says accepting deals that aren’t a good fit could affect the quality of the opportunities you receive, and AWS expects regular updates on every referral you accept. Suger’s auto-accept buys speed; a triage SLA keeps you selective.

Can you decline a co-sell referral after accepting it?

No. Accept and decline are the two answers to a pending referral. Once you accept, a referral you won’t work gets closed instead: as Closed Lost with a reason on AWS, or as lost on Microsoft, which asks partners to report every deal’s final status.

Which co-sell referrals does Suger auto-accept?

AWS and Microsoft referrals, each switched on separately: on the AWS ACE integration, and on the Azure Marketplace integration for Microsoft. Suger accepts AWS invitations still Pending and not expired, and Microsoft referrals whose substatus is Pending, logging each attempt as an Auto-accept run.

What happens if Suger’s auto-accept fails on AWS?

Its run fails under Metrics → Logs and isn’t retried automatically, and a red ! appears on the referral’s status tag. If the invitation is still pending, accept it by hand before it expires; if not, reconcile the run with the referral’s current status.

Takeaways

• AWS gives five business days and Microsoft 14. After that, AWS removes the invitation from view and Microsoft archives the opportunity as expired.
• Microsoft asks for speed and selectivity together; AWS asks for regular updates on everything you accept. Neither treats an accept as free.
• Choose a policy per cloud (manual review, auto-accept plus a triage SLA, or a decline rule alongside either) and put one owner and a backup on every queue.
• Suger’s auto-accept is switched on per cloud, for AWS and Microsoft. Check the Auto-accept runs every business day: a failed AWS accept isn’t retried automatically, so accept it by hand while the invitation is still pending.
• Close what you won’t work instead of letting it sit, and move repeat closes onto the decline list.

Suger keeps AWS and Microsoft referrals in step with Salesforce, HubSpot or Dynamics 365, with auto-accept set per cloud and every attempt logged. See how the whole referral workflow runs in Suger’s co-sell automation.