Setting Customer Expectations

Based on: Leicht, Michael, and Vicki Sauter. “Managing user expectations.” University of Missouri St. Louis epublication. umsl.edu.

1. Why Setting Expectations Matters

  • Customers often leave even when they say they are “satisfied.”
  • The gap between satisfied and completely satisfied customers is huge in terms of loyalty.
  • Managing expectations up front helps avoid disappointment, prevents miscommunication, and builds trust.

2. How to Set Expectations

a. Evaluate the Client – Educate the Developers

  • Understand the client’s background, company culture, and experience with vendors.
  • Example: A client from a regulated industry (e.g., banking) expects precision and documentation. Developers must be aware of this context.

b. Find a Common Language

  • Avoid jargon and clarify terminology.
  • Example: “Release” might mean “final delivery” to the client, but “deployment to test” for IT. Define terms early.

c. Educate the Client

  • Help clients understand trade-offs (scope, time, budget, quality).
  • Example: If a new feature is requested late, explain its impact on deadlines and cost.

d. Explain Processes and Standards

  • Make decision-making, progress tracking, and quality validation transparent.
  • Example: Use agile boards or review cycles to make progress visible.

e. Good Enough vs. Perfect

  • Clarify when a “fit-for-purpose” solution is acceptable versus when “perfection” is required.
  • Example: A prototype for internal testing doesn’t need full security, but the final product does.

f. Impact of Changes

  • Clearly communicate how scope changes affect:
    • Time (delays)
    • Budget (extra costs)
    • Quality (possible compromises)
  • Example: Adding a feature may delay delivery by two weeks.

g. Impact of Evaluating Changes

  • Teach clients that even evaluating a change request takes time and effort.
  • Example: Assessing a new vendor integration may require a week of investigation before a decision.

3. Setting Expectations in Practice

a. Honesty

  • “Bad news doesn’t get better with time.”
  • Share issues early to build credibility.
  • Example: If a key dependency slips, inform the client immediately rather than waiting until the deadline.

b. What You Say vs. What You Do

  • Consistency builds trust. Overpromising and underdelivering destroys it.
  • Example: Don’t claim “system is 100% ready” if testing is incomplete.

c. Attenuating Bad News

  • Frame setbacks constructively: explain the issue, options, and mitigation.
  • Example: “The supplier delay pushes us back 5 days, but if we drop Feature X, we can still meet the original date.”

d. Don’t Forget Good News

  • Clients need reassurance, not just crisis updates.
  • Example: Share when milestones are reached early or when user feedback is positive. This strengthens confidence.

4. Examples of Good and Poor Expectation Management

Scenario Poor Practice Good Practice
New requirement late in project Accept silently, then miss deadline. Explain impact on budget and schedule; offer options.
Defect discovered Hide it, hope client doesn’t notice. Report immediately, outline fix and prevention plan.
Progress updates Only deliver at final deadline. Provide weekly demos/reports.
Language use Developer jargon (“We’ll refactor monolith”). Plain terms (“We’ll split the system into smaller, faster parts”).

Disclaimer: AI is used for text summarization, explaining, and formatting. Authors have verified all facts and claims. In case of an error, feel free to file an issue.