Knowledge · Customer Experience

    Customer Messages and Updates

    A shared message history ends the 'who told them what' problem. Learn how to keep customer communication in one thread and what a portal thread should contain.

    Why keep customer messages in one shared thread?

    Because scattered communication is how commitments get lost. When every message about a job lives in one thread attached to that job, anyone can see what was promised, when, and by whom — and the customer can re-read it instead of relying on memory of a phone call.

    Key takeaways

    • One thread per customer's work beats four channels and three memories.
    • A visible history makes promises checkable by both sides.
    • Internal notes must stay internal, and separately marked.
    • A portal thread is a record; it is not a replacement for proactive updates.
    • Silence still reads as bad news, even with a portal.

    The problem a shared thread solves

    Communication about a single job typically ends up split across a salesperson's phone, an office inbox, a crew lead's texts and one call nobody wrote down. When the customer says 'you told me Tuesday', there is no way to check, so the business either concedes or argues from memory.

    A shared thread makes the record checkable. It changes the conversation from competing recollections into reading what was actually sent.

    Internal notes are not messages

    Every serious system needs a place to write things the customer must never read: concerns about access, pricing decisions, behaviour on site. Those belong on the record, flagged as internal, and structurally separated from the customer-visible thread.

    The separation must be enforced where the data is served, not by relying on staff to pick the right box every time.

    What a good update looks like

    • Says what changed, not just that something changed.
    • Names the new date, not 'we will be in touch'.
    • Arrives before the customer notices the problem themselves.
    • Comes from an identified person, not an anonymous system voice.

    A portal does not make you communicative

    Publishing a thread the customer can read is passive. The businesses that get referrals still push updates out — a text when the crew is dispatched, a call when a date slips. The portal is where those updates persist, not the reason they exist.

    Where URBLD fits

    The URBLD customer portal shows the message history shared with that customer, with each message attributed to its sender and internal notes excluded from what the customer can reach. In the current implementation the customer's view of that thread is read-only.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Customer Experience

    What customers actually judge: communication, clarity and reliability.

    Browse Customer Experience
    Share this page