Hiring Cloud Infrastructure Salespeople: A Practical Employer Guide

Define the role, customers and territory

Start with what the salesperson will sell: infrastructure capacity, a managed cloud offering, migration services, or an ongoing services agreement. Specify whether your business sells directly, resells services, or works alongside provider and implementation partners. Experience selling one of these offers should not automatically qualify someone for another.

Define target accounts by workload, organization size, purchasing process and technical requirements—not simply “companies using cloud.” Map likely participants: infrastructure leaders, platform engineers, security teams, finance, procurement and executive sponsors. Your hiring brief should identify who evaluates, approves, implements and pays.

For a United States territory, state account ownership, geographic coverage, travel expectations and time-zone coverage. Decide whether the role owns new accounts, expansion or both, and document how it works with solution architects and customer success.

Validate market-specific selling constraints

Build the role around your actual deal history. Review recent wins, losses and stalled opportunities to identify technical validation steps, procurement gates, migration dependencies and reasons buyers delayed. Separate time spent proving suitability from time spent negotiating or waiting for implementation capacity.

For consumption-based offers, ask candidates how they would investigate workload behavior, usage assumptions and projected growth during discovery. Test whether candidates distinguish an estimate from a commitment and explain uncertainty without making unsupported savings promises.

AWS describes security responsibilities as divided between AWS and the customer, with customer obligations depending on the selected service. Do not generalize that model to every vendor or service. Have your technical team verify current service documentation, configuration ownership, support escalation, contractual commitments and any buyer-specific compliance requirements before sellers make representations.

Build a role scorecard with observable evidence

Use the same scorecard for every candidate. Rate each competency from one to four: unsupported assertion, partial evidence, clear evidence, or repeatable evidence with sound judgment. Record examples rather than impressions.

Set minimum standards before interviewing. For example, require clear evidence in discovery and commercial reasoning, while allowing product-specific knowledge to develop during onboarding. Do not let a recognizable employer name substitute for demonstrated ability.

Plan base pay, variable compensation, quota and ramp

Define the job before benchmarking compensation. Use O*NET to research task and skill descriptions, then identify the closest appropriate occupation in the BLS occupational wage tables. Verify occupation, geography and data year. A broad national category is not a local salary quote or a ready-made cloud sales compensation package.

Choose a base-and-variable structure that fits seller control over outcomes. Document whether quota and commissions depend on bookings, recognized revenue, consumption, margin or another defined measure. Clarify credit for renewals, partner transactions, expansions and shared accounts, plus treatment of cancellations and adjustments.

Build ramp assumptions from your own onboarding milestones, opportunity creation and observed sales cycles. Model hypothetical low, expected and high attainment outcomes before approving the plan. Have finance, HR and appropriate counsel review terms, payment timing and applicable requirements before issuing an offer.

Run structured interviews and a realistic work sample

Use a consistent sequence: recruiter screen, manager evidence interview, technical collaboration exercise and structured references with permission. Tell candidates what you assess. Keep the exercise bounded and fictional; do not ask for unpaid work on a live prospect.

Role-specific interview questions

• New-account seller: “How would you distinguish a serious migration project from general interest? Which next commitment would you request?”
• Expansion seller: “Usage is increasing, but the customer disputes its bill. How would you investigate before proposing more services?”
• Technical seller: “Which discovery gaps require a solution architect, and what information would you provide before that meeting?”
• Any role: “Describe a deal you slowed down because an assumption was unverified. What happened next?”

Hypothetical migration exercise

A fictional software company wants to move a customer-facing application from a hosted environment to cloud infrastructure. Its finance lead wants predictable spending; engineering has not documented workload peaks. The buyer asks for a proposal before selecting services.

Allow 15 minutes of preparation, a 20-minute discovery role-play and a short written follow-up. Supply the same facts to every candidate; leave some questions deliberately unanswered.

1. Identify current workloads, dependencies, availability needs and decision criteria.
2. Explore service choices without prescribing an architecture prematurely.
3. Ask who will own configuration, security tasks and support escalation.
4. State consumption assumptions and the evidence needed to test them.
5. Propose a next meeting with named roles, deliverables and decision gates.

Score question quality, listening, uncertainty handling and handoff clarity—not presentation polish. Have interviewers score independently before discussing results.

Prevent common hiring failures

• Hiring for provider vocabulary: Ask candidates to explain trade-offs in buyer language, then identify what needs technical validation.
• Confusing team results with personal contribution: Ask who sourced, qualified, designed, negotiated and closed a specific opportunity. Accept anonymized evidence.
• Rewarding premature certainty: Include missing usage data in the exercise. Strong candidates should flag it rather than invent a precise estimate.
• Ignoring the services boundary: Require candidates to separate infrastructure purchases from migration, implementation and ongoing management responsibilities.
• Leaving ownership ambiguous: Define partner involvement, account credit and post-sale handoffs before hiring.

Use references to explore the same competencies, not to collect general praise. Ask what support the person needed and which situations exposed development needs.

Create a 30/60/90-day onboarding plan

First 30 days: establish accuracy

Teach the offer, target accounts, discovery process and escalation boundaries. Have the hire shadow technical and commercial calls, review lost deals and practice explaining service responsibilities. Require a scored discovery simulation and an accurate CRM example before independent qualification.

Days 31–60: practice with supervision

Assign a defined account set and review outreach, discovery notes and stakeholder maps weekly. Pair the seller with a solution architect for qualification. Coach on missing assumptions and buyer commitments, not just activity counts.

Days 61–90: establish repeatable execution

Review opportunity quality, next-step ownership, forecast rationale and handoff completeness. Compare progress with your documented ramp assumptions. Where long sales cycles limit closed revenue, assess verified milestones rather than treating early pipeline value as proof of success.

Employer checklist for the coming week

• Write a one-page role brief covering offer, buyers, territory and ownership.
• Review recent deals with sales, technical delivery and finance.
• Select five scorecard competencies and minimum evidence standards.
• Draft compensation definitions and test payout scenarios.
• Prepare the fictional migration exercise and interviewer instructions.
• Assign interview stages and independent scoring responsibilities.
• Schedule onboarding owners and the first three coaching reviews.
• Check that outreach describes the actual role without unsupported earnings claims.

Employer FAQs

Must candidates have sold AWS, Azure or GCP?

Make provider-specific experience mandatory only where the job requires immediate familiarity. Test transferable workload discovery, commercial judgment and technical collaboration separately from product knowledge.

Should we hire a seller or a solution architect?

Decide who owns commercial progress and who validates technical suitability. If one role must cover both, assess both explicitly and ensure the workload is realistic.

How much sales-cycle experience is enough?

Compare candidates with your actual deal complexity and approval process. Ask for evidence of managing dependencies through completion, rather than relying on years of experience alone.

Sources and relevant next steps

Use the linked AWS documentation only for AWS-specific responsibility guidance. Verify other services against their current documentation and contracts. Recheck BLS occupation, geography and year when benchmarking pay, and use O*NET to refine task requirements.

Once the scorecard and compensation framework are approved, browse salespeople on Salesfolks against your criteria. You can create an account and check current employer plans before choosing your next step.

Candidate perspective: Cloud Infrastructure Sales Jobs: A Candidate’s Guide to Roles, Interviews and Offers.