KarmSakha
Help

Career Coaching & Personal Development

Sales Skills for Non-Sales People: Explain a Proposal and Respect the Decision

Editorially revised on 9 October 2026.

People outside sales often need to explain a proposal, understand another person's needs and ask for a decision. Useful skills include listening, describing evidence, comparing trade-offs and responding to concerns. They do not require invented urgency, a fixed talk-to-listen ratio or promises that every objection can be overcome.

This guide offers an original proposal worksheet and three fictional workplace examples. It focuses on making a choice understandable while respecting the other person's authority and right to decline. It does not predict conversion rates or treat persuasion as a substitute for accurate information.

Define the decision before preparing a pitch

Ask what decision is actually needed. Are you requesting approval for a small trial, asking a client to choose between options or proposing a change to an internal process? These differ from selling a product to someone who has not expressed interest.

Name who can decide and which other people need to be consulted. A colleague may offer useful feedback without authority to approve spending, change a contract or alter another team's work. Enthusiasm from one person does not establish permission to proceed.

Write the proposal in one factual sentence. For example: “I propose a limited trial of a shared handover field so the receiving team can see unresolved items.” That is clearer than “This will transform collaboration.” The larger promise needs evidence the small proposal does not yet supply.

Understand needs through relevant questions

Ask about the problem, its context and what a useful outcome would look like. A question such as “Where does the current handover leave you uncertain?” invites specific information. “You agree this process is terrible, right?” pushes a conclusion before the other person has described their experience.

Yale's informational-interviewing guidance supports conversations used to learn about work and organisations. That is a limited conversation principle, not evidence for a universal sales method or a claim that networking conversations should be converted into sales pitches.

After listening, summarise your understanding and invite correction. If the person says your summary is wrong, revise it. A useful proposal should respond to the actual need, not merely create an opportunity to recite your prepared pitch.

Use a proposal worksheet

FieldWhat to establish
NeedThe problem as described by the relevant person or record.
EvidenceWhat you have observed and what remains uncertain.
Proposed actionA specific step with a bounded scope.
Trade-offTime, effort or other consequences to consider.
AuthorityWho can approve and what permission is required.
Next decisionProceed, revise, test, defer or decline.

Keep evidence and forecasts separate. “Three records were missing a handover status in my sample” is an observation about that sample. “This change will eliminate all missing records” is a prediction and requires a basis you may not have.

You can suggest a way to test an uncertain benefit instead of pretending it is proven. A limited trial with agreed measures often provides a clearer decision than a confident claim about permanent improvement.

Fictional example 1: an engineer proposes a small process change

A fictional engineer, Arun, notices that unresolved review comments are difficult to locate during handover. He wants to add a status field to an existing tracker. He does not control the team's tools or another person's workload.

His practice proposal: “In the sample I reviewed, some unresolved comments were not easy to identify at handover. Could we trial one status field on a small set of items? I would like to check whether it makes unresolved work clearer and how much time updating it takes. The team owner would need to approve the trial and decide who maintains the field.”

The proposal identifies an observation, an uncertain benefit and a cost to measure. It does not claim that everyone has experienced the same problem or that the engineer can change the workflow alone.

A colleague objects that another field creates extra work. Arun asks where the burden would occur, then considers whether an existing field can be improved instead. The objection changes the proposal. Listening has value only if it can affect the decision.

Fictional example 2: a designer presents two real options

A fictional designer, Meena, is explaining two layouts for a client document. One prioritises a compact overview; the other gives more space to detailed notes. She has not run user research proving that one is superior.

Her practice explanation: “The compact layout lets more items appear together. The detailed layout gives each note more space but shows fewer items at once. Which task matters most for the people using this document? If both matter, we can review a small sample before choosing.”

This gives the client a concrete comparison instead of an unsupported claim that one design always converts better. If the client asks for a result she has not measured, Meena says what she knows and proposes an appropriate test if feasible.

She also confirms the scope of any additional work before starting it. A request to explore a sample does not automatically authorise a larger redesign or an extra charge. Clear decision boundaries help the discussion stay useful.

Fictional example 3: a coordinator handles a concern about reliability

A fictional coordinator, Faisal, proposes a shared weekly status note. A manager worries that the information will become stale. Faisal has no evidence that the note will remain accurate without an owner and update process.

His practice response: “That is a relevant concern. A note without an update owner could become misleading. Before a trial, we should decide who updates it, which source it uses and how it shows the date checked. If we cannot maintain that, the proposal may not be worth proceeding with.”

The response does not try to defeat the objection with social proof or fabricated success stories. It recognises a condition necessary for the proposal to work. Declining or revising the idea can be a reasonable outcome.

If the manager asks whether another team uses the method successfully, Faisal should give only a verified, permitted example. He must not invent an endorsement or disclose another team's private records to make the proposal seem credible.

Explain value without manufacturing pressure

Connect the proposed action to the need, then explain the basis for that connection. “This field may help the receiver identify unresolved work” is a bounded rationale. “Everyone who cares about quality must support this” pressures identity instead of explaining the action.

If there is a real deadline or capacity limit, state it accurately and explain its source. Do not create a false deadline to force a decision. If the benefit is uncertain, name the uncertainty rather than replacing it with enthusiastic language.

Avoid implying a favour creates a debt to accept your proposal. Helping a colleague and requesting a decision are separate interactions. The other person should be able to evaluate the proposal on its merits and decline it without being cast as ungrateful.

Classify concerns before responding

A concern may involve missing information, a competing priority, a practical constraint or a disagreement about value. These need different responses. If the person lacks information, supply accurate details. If there is a budget or time constraint, revising the scope may help. If the action is outside their authority, identify the proper decision owner.

Some concerns reveal that the proposal is unsuitable. Do not treat every “no” as an objection you are entitled to overcome. Ask whether further clarification would be useful, then respect the answer and agreed boundaries.

A simple rehearsal exercise is to ask a partner for three objections: one factual, one practical and one that requires declining the proposal. Practise changing your response accordingly. The purpose is better judgement, not a script that produces agreement every time.

End with an explicit next step

Confirm what has actually been decided: a trial approved, a revision requested, information still needed or no action. Record the owner, scope and review point where relevant. Do not describe a positive conversation as approval if the decision remains open.

For interview practice involving conditional actions, use situational responses. For work exploration before a larger career change, use career pivot experiments. These address different decisions and should not be relabelled as sales results.

Frequently asked questions

Do I need to talk less than a fixed percentage?

There is no universal ratio established here. Ask relevant questions, listen to the answer and leave room for correction. The needs of the conversation determine how much explanation is useful.

What if the person declines?

Clarify only where appropriate and respect the decision. A refusal may reflect a valid constraint or an unsuitable proposal. It is not automatic evidence that you need a stronger pressure tactic.

Can I mention another team's results?

Only use accurate information you are permitted to share, with its scope and limitations. Do not invent testimonials or convert a small observation into a guaranteed result.

Related guides

Ask KarmSakha AI