# Sharing knowledge with your customers **Sharing knowledge with your customers** means giving internal and external users the truth they need to choose, plan, and respond. Explain the relevant constraint, current state, safe action, and time of the next fact. Do not expose secrets or dump internal debate. Translate technical knowledge into a reliable customer interface and keep uncertainty visible. ## Treat internal customers as customers A product team using an internal platform depends on service knowledge much like an external buyer depends on product guidance. It needs supported paths, SLO scope, known limits, incident status, and an accountable contact. The absence of a contract or invoice does not make uncertainty cheaper. Platform teams sometimes expect internal users to absorb architecture before asking for help. Reverse the entry point. Begin with what the product team can safely build, which customer effects the platform can promise, and which cases require review. Link the architecture for engineers who need to inspect the reasoning. Internal transparency also improves external answers. When product, support, and sales can rely on the same limit and status, customers hear one account. If each function privately asks engineering, small differences become promises the product cannot keep. ## External customers need usable truth An external customer rarely needs the full diagnostic path. They need to know whether they are affected, what remains available, what action is safe, and when another verified update will arrive. This is not less honest than sharing raw logs. It is truth arranged around the customer's responsibility. Avoid language that hides agency. We are investigating can be accurate, but it is incomplete if you already know the affected surface and next check. Say what is known, what is not yet known, who is working, and the next update time. If no safe workaround exists, say that plainly. Customer facing groups need approved access to these facts before pressure rises. Draft common limit explanations and incident structures with engineering, product, support, legal, and security as appropriate. Preparation reduces both delay and the temptation to improvise certainty. ## Status pages are action tools A status page should help readers decide whether to wait, retry, use another path, or continue normally. Name affected functions in customer language. A component marked degraded may mean little to someone who knows only that invoices are failing. Connect the technical state to an observable product effect. Update rhythm builds trust. Choose the next update time based on investigation reality, then publish even if the only new fact is that scope has not changed. Silence forces customers to seek private channels and makes account size determine access to truth. After resolution, preserve a concise incident note. Explain impact, duration, current safety, and prevention at the level customers can use. Keep exploit detail, private data, and speculative blame out. Transparency is not a public copy of the internal incident room. ## Information for common customer moments | Moment | Customer needs | Avoid | | --- | --- | --- | | Known limit | Boundary and safe choice | Architecture dump | | Incident | Impact, action, next fact | Unverified cause | | Refused request | Reason and alternatives | Policy says no | | Recovery | Current safety and follow up | Premature certainty | The avoid column is not a reason to become vague. Replace internal volume with relevant precision. A customer can understand that a payment operation cannot be repeated safely while the result is unknown. They do not need every queue and database involved to make the next choice. Use the same core facts across channels. A status page, support response, and account update can vary in depth, but impact and current state should agree. Contradiction sends customers toward private contacts and rewards those with the strongest access. ## Explain why a request was refused A bare refusal hides knowledge that could help the customer adapt. Name the constraint in terms of protected outcomes. For example, a payment change may be refused because it can create duplicate charges under uncertain network results. Then explain a supported option or the evidence needed for another review. Do not invent flexibility when none exists. If regulation, security, or product design prevents the request, be direct. State what part is fixed, what part remains a choice, and who can confirm interpretation. Respectful clarity is more useful than a long answer that implies negotiation where none is possible. Record common refusals internally with approved customer language. This keeps support from escalating every repeat and gives engineering evidence about demand. A growing pattern may justify a product change even when each individual answer remains no. ## Write an update customers can use - Name the affected customer action. - State the current verified condition. - Separate facts from investigation. - Say what remains safe. - Offer a workaround only if it is tested. - Give the time of the next fact. - Update the durable customer record. Write the first sentence for the reader who sees only that sentence. During a payment issue, say which payments or reports are affected before naming an internal service. Follow with scope, safe behavior, and timing. A technical name can appear when it helps support identify the issue. Have someone outside the response group read the draft. Ask what they would do next and what they believe is affected. If their answer differs from reality, revise before broad distribution. Under pressure, this short check prevents confident ambiguity. ## Keep uncertainty honest Customers can handle uncertainty better than contradiction disguised as certainty. Use known, suspected, and unknown deliberately. Explain what evidence is being gathered and when it can change the assessment. Do not announce a cause because one internal theory is popular. Match confidence to consequence. A low confidence workaround that touches payments should not be offered as a helpful experiment. An internal product team may be able to test a change safely in a limited environment. State the boundary and monitoring needed for any trial. When facts change, correct the record visibly. Say what changed and why the prior account was reasonable at the time, if it was. Quiet edits make attentive customers wonder which statement they can trust. ## Protect secrets without hiding consequences Customer transparency has real limits. Do not reveal credentials, personal data, active exploit paths, another customer's information, or private personnel discussion. Work with security and legal partners to define those limits before an incident, not while every minute matters. Even when cause detail is restricted, consequence can often be clear. Tell customers which action is affected, what data exposure is confirmed or not confirmed, which protective step to take, and when the next review occurs. Restriction should narrow the sensitive fact, not erase the whole account. Internal customers also deserve appropriate boundaries. A product team may need the approved security pattern and reason without access to a live vulnerability report. Give enough truth to comply and plan. If all useful guidance is classified with the deepest evidence, teams will learn rules through delay. ## Close the loop into product work Customer questions are knowledge signals. Track where people repeatedly misunderstand a limit, request a private status update, or escalate a refusal. The answer may need clearer guidance, a better product surface, or a different operating promise. Do not treat every question as a support writing problem. Bring representative cases to planning. A platform group might learn that its SLO is stated in service terms while product teams plan around user journeys. An external product team might learn that a payment limit appears only after customers design an incompatible process. Earlier product cues can prevent both. Tell customers when their question changed the interface. You do not need to promise every request. Acknowledging that a known limit, guide, or status practice improved because of observed confusion demonstrates a functioning learning loop and reduces the need for private influence. ## Prepare customer knowledge before pressure Run a short exercise for a likely limit or incident. Give engineering the technical state, ask product to name the customer choice, ask support to draft the first answer, and ask security which detail needs control. Compare the drafts. Differences reveal assumptions that would otherwise surface during a live customer problem. Create approved building blocks, not rigid scripts. A useful block names affected action, verified scope, safe behavior, owner, and next update. People can adapt tone and depth to an internal platform team, a small external customer, or a regulated account while preserving the same facts. Include a rule for escalation when customer evidence contradicts the internal view. Support should know where to send a trace, product should know who can change the impact statement, and engineering should know how the correction returns to the public route. Fast correction is part of transparency. Review promises after the event. An account conversation may have implied a response time or product capability that the service does not support. Address the mismatch directly and update guidance. Do not leave engineering to discover the promise during the next escalation. Notice which customers receive facts first. Large accounts may have direct contacts while smaller customers depend on general status and support routes. Personal service can add context, but core impact and safety information should not depend on influence. Publish common facts promptly, then use private conversations for the customer's particular choices and obligations. ## What are common questions? ### Do internal product teams count as customers? Yes. Teams using a platform need supported paths, known limits, service expectations, status, and a reliable answer route. ### What should an incident update include? State affected customer actions, verified condition, what remains safe, any tested workaround, and when the next fact will arrive. ### Does transparency require sharing internal logs? No. Share usable truth about impact, constraint, action, and timing while protecting sensitive evidence and private data. ### How should you explain a refused request? Name the protected outcome or fixed constraint, explain available alternatives, and state what evidence could support another review. ### What if the cause is still uncertain? Separate known facts from current theories, explain what is being checked, and correct the visible record when evidence changes. Related: [opening knowledge silos between teams](https://isilta.com/blog/knowledge-silos-between-teams/), [making knowledge usable for another team](https://isilta.com/blog/making-knowledge-usable-for-another-team/), [opening knowledge across the organization](https://isilta.com/blog/opening-knowledge-across-the-organization/).