All articles
    Leadership & Operations

    Trust Is Built Before Something Goes Wrong

    Hollis & Co. Team

    Trust becomes easier to sustain when promises, ownership, and communication are clear before a customer needs an explanation.

    Make the promise visible

    Businesses often describe trust as a brand quality. A more useful operating definition is whether customers can understand what will happen, who is responsible, and what the company will do when reality differs from the promise.

    Start with the promises that are easy to make and difficult to keep: a delivery date, an implementation timeline, a response standard, or a statement about how information is handled. Put those promises somewhere the people delivering the work can see them.

    If sales, support, and operations describe the service differently, resolve the difference before it becomes a customer’s problem. The best wording is not necessarily the most persuasive version. It is the version the company can deliver consistently.

    Assign responsibility before an incident

    For each important customer commitment, identify an owner and a backup. Decide who can approve an exception, who communicates a delay, and who keeps the record of what was agreed.

    This discipline applies to technology incidents as well as service failures. NIST’s small-business guidance recommends preparing incident-response and recovery plans, identifying responsible people, and planning stakeholder communication (NIST). A practical plan should help a team act under pressure, not merely demonstrate that a document exists.

    Run a simple tabletop exercise. Suppose a critical supplier is unavailable on a busy day. Can the team identify affected customers, pause new commitments, and explain the next update without improvising every step?

    Communicate the boundary of your knowledge

    When something goes wrong, customers need a clear distinction between what is known and what is still being investigated. Avoid filling that gap with an optimistic explanation that may later have to be withdrawn.

    A useful update answers four questions:

    • Impact: What does the customer need to know about their situation?
    • Action: What is the company doing now?
    • Choice: Is there anything the customer should do or avoid doing?
    • Next update: When will the customer hear more, even if the investigation is unfinished?

    Do not promise a resolution time simply because an update feels incomplete without one. A credible next communication time is better than a speculative fix date.

    Close the loop after the immediate problem

    Once normal service returns, identify the promise that failed and the control that should change. Was the problem a missing owner, an unreliable dependency, an unclear contract, or a sales commitment the delivery team never approved?

    Not every incident needs a public essay. Every material incident should produce a usable internal lesson and any customer explanation the circumstances require.

    The work of trust is often unglamorous: maintaining accurate records, making realistic commitments, and telling people when those commitments are at risk. Those habits are worth building before a business is large enough to have a dedicated team for them.