# How do you handle internal customers? **Internal customers** should be treated as partners whose work provides essential evidence, not as an order queue and not as outsiders who must accept every platform decision. Learn their goals by observing real journeys across CI, deploy, observability, and auth. Set clear service boundaries, prioritize needs transparently, communicate decisions, and close the loop. The platform team owns the product judgment; users supply context that judgment can't be sound without. ## Why can the customer metaphor become difficult? The word customer can encourage useful empathy. It reminds platform engineers that an internal tool exists to help someone complete work. It can also imply that every request should be fulfilled because the customer is always right. Internal relationships are more complex because teams share organizational goals, constraints, and accountability. A product team may request a custom CI feature that helps one repository but increases maintenance for everyone. A security group may need stronger auth controls that add steps to common work. A platform team may prefer architectural consistency that makes a critical product deadline harder. No party has the complete view. Use the metaphor to support service and discovery, not submission. Internal users understand their work and pain. The platform team understands shared architecture, operating cost, and broader patterns. Strong decisions combine both forms of expertise. ## Who should the platform team listen to? Listen beyond the loudest lead engineers. New hires, frequent deployers, incident responders, service owners, regulated teams, and occasional users encounter different problems. Security and operations partners may see risks that direct users don't. Leaders may provide strategy and funding context. Create a user map that names major groups, tasks, constraints, and current contact. Check whose experience is absent from recent decisions. A voluntary council often attracts confident supporters and critics while missing busy or less powerful teams. Reach out deliberately to fill gaps. Internal users can also be nonusers. A team that avoids the platform may have a valid technical reason, stale assumptions, migration cost, or low trust. Study avoidance without beginning from blame. Their workaround may reveal a missing capability or an unclear value proposition. ## How do you discover the real need? Ask about a recent event rather than a desired feature. Have the user walk through their last failed deploy, slow CI run, missing signal, or auth integration. Note the trigger, steps, waiting, decisions, workarounds, people involved, and consequence. Concrete behavior produces better evidence than broad preference. Separate the need from the proposed solution. A request for another deploy button may reflect poor status visibility. A request for direct production access may reflect a slow incident path. A request for a new observability tool may reflect missing ownership or training. Solving the stated feature without the underlying problem can add complexity and preserve pain. Confirm your understanding in plain language. State who faces the problem, when, how often, what happens, and why existing options fail. Let the user correct it before the team discusses implementation. ## Which listening methods should you combine? | Method | What it reveals | Common limit | | --- | --- | --- | | Workflow observation | Actual steps and workarounds | Small sample | | Interview | Goals, context, and perception | Recall and selection bias | | Support analysis | Repeated acute friction | Misses silent users | | Usage data | Adoption and stopping points | Doesn't explain motive | | Incident review | Consequence under pressure | Focuses on failure | | User council | Needs across teams | Can favor confident voices | No method is sufficient alone. Data might show that auth setup is abandoned, while observation reveals that users can't interpret permission names. Support volume might look low because teams ask a known expert privately. Triangulation reduces confident but incomplete conclusions. Give platform engineers direct exposure. A product role can organize discovery, but filtering every interaction through one person weakens shared context and empathy. ## How should requests enter the system? Provide one visible intake path for requests, with simple guidance for urgent incidents and security concerns. Capture the user, problem, consequence, frequency, current workaround, and timing. Don't require a perfect business case before someone can report friction. Private messages will still happen. Move meaningful requests into the shared system and explain why. Visibility allows related needs to combine, prevents duplicate promises, and gives users a place to follow progress. It also protects engineers from becoming private account managers. Acknowledge requests quickly without promising delivery. Tell the requester when triage occurs, what information is missing, and how decisions are made. Waiting with a known process is different from silence. ## How do you say no without damaging trust? - Restate the user need and confirm that you understood it. - Explain the decision principle and relevant evidence. - Name the cost, conflict, or boundary that prevents commitment. - Offer an existing path or bounded workaround when safe. - State what new evidence could change priority. - Record the decision where other users can find it. - Return if the need later becomes common or more consequential. Avoid vague language such as not now when there is no realistic review point. Honest rejection lets a team plan. If work might become relevant, name the trigger or date. If it conflicts with platform direction, say so plainly. Don't use architecture as an unexplained veto. Translate the concern into reliability, security, cost, ownership, or future change consequence. Users don't need every implementation detail, but they deserve reasoning connected to organizational outcomes. ## How should expectations and service boundaries be set? Document supported journeys, expected reliability, response channels, ownership, and known limits. For CI, state supported repository patterns and where specialized help is needed. For deploy, state release controls and recovery responsibility. For observability and auth, clarify what the platform provides and what service teams must configure or operate. Boundaries should work during pressure. Test them in incident exercises and onboarding. If users can't tell who owns a failed deploy or incorrect permission, the documentation isn't clear enough. Update it when the organization or architecture changes. Avoid promising identical service to every team when consequence differs. A critical regulated system may receive a distinct path, but the reason and cost should be visible. Unexplained exceptions create perceptions of favoritism. ## How do you close the feedback loop? Tell users what you learned, what the team decided, and what happens next. If several reports led to a CI improvement, share the connection. If evidence changed a roadmap choice, explain it. This demonstrates that feedback has consequence and encourages future honesty. Return after release. Ask whether the task improved in practice, inspect adoption, and watch support. A feature can satisfy its specification while leaving the journey difficult. Closing the loop includes validation, not only announcing completion. Communicate mistakes as well. If the platform team misunderstood the need or caused migration pain, acknowledge it and describe the correction. Internal trust depends more on accurate response than on an image of perfection. ## How should customer evidence affect priorities? Combine user evidence with reach, strategic fit, operational risk, confidence, and continuing cost. A severe problem for one critical team may outrank a mild inconvenience for many. A common request may remain lower priority if an upcoming platform change removes the need. Make these tradeoffs explicit. Satisfaction surveys can indicate sentiment but shouldn't determine the roadmap alone. Users may dislike a necessary security control or enjoy a feature that adds unacceptable operating risk. Pair sentiment with task success, reliability, adoption, and business consequence. Review the portfolio with representative users, but retain platform accountability. A council can challenge assumptions and expose missing context. It shouldn't become a vote where attendance determines investment. The team's duty is to make a reasoned choice and show its work. ## How do you repair a damaged internal relationship? Begin by naming the specific failure without defending intent. Perhaps a deploy migration created unexpected work, a CI incident lacked updates, or an auth change arrived without enough notice. Ask the affected team to describe the consequence and listen for both technical and coordination problems. An apology helps only when it is paired with changed behavior. Agree on immediate recovery, an owner, and a communication rhythm. Then review why the platform team missed the impact. The cause may involve narrow discovery, unclear ownership, schedule pressure, or assumptions about user capability. Share the resulting changes and return after enough time to see whether they worked. Don't promise that friction will never recur. Promise clearer expectations, earlier contact, dependable escalation, and honest follow through. Trust is rebuilt through several ordinary interactions where the platform team does what it said, explains tradeoffs, and responds accurately when conditions change. Consistency makes the repair believable. ## Frequently asked questions ### Who are a platform team's internal customers? They are the product engineers, service owners, security partners, and other employees who rely on platform capabilities to complete work. ### Should internal customers decide the platform roadmap? They should provide essential evidence, but the platform team must combine it with strategy, risk, reach, cost, and technical judgment. ### How should a platform team decline a request? Explain the understood need, decision principle, evidence, available alternative, and what could change the decision. ### How can platform engineers learn what users need? Combine workflow observation, interviews, support patterns, usage data, incident learning, and regular user councils. ### What is the best measure of internal customer satisfaction? Use satisfaction as one signal, then pair it with task success, reliability, adoption, support demand, and qualitative accounts. Related: [managing a platform engineering team](https://isilta.com/blog/how-to-manage-a-platform-engineering-team/), [setting an internal SLO](https://isilta.com/blog/how-to-set-internal-slo-for-a-platform-team/), [prioritizing a platform roadmap](https://isilta.com/blog/how-to-prioritize-platform-work/).