The Conversations page in GoHighLevel is extremely difficult — nearly impossible — for teams to use effectively when multiple employees are involved.

Our company, like many others, has several team members who each have their own phone number within the system. Customers might text one number or another depending on who they’ve spoken with before. For example, a customer might text TIM in the office about scheduling, KRISTEN about an estimate, and JOHN in the field about running late. These messages all appear in the same conversation thread, making it very unclear which internal number (and which team member) the customer is talking to.

Technically, it IS possible to see who they’re texting — but it’s NOT INTUITIVE at all. You have to click the three dots, open the details, and look closely to find it. That’s simply not practical for busy teams who need to move quickly or for less tech-savvy employees who might not even realize that detail exists. The result is constant confusion and mistakes: employees reply from the wrong number, conversations overlap, and customers receive multiple conflicting responses.

This isn’t about assigning a customer to a single user — that wouldn’t make sense for a real business where multiple people communicate with the same customer about different things. The issue is that THE SYSTEM DOESN’T MAKE IT VISUALLY OBVIOUS WHICH INTERNAL NUMBER OR TEAM MEMBER A MESSAGE IS TIED TO.

At a minimum, GoHighLevel should make this distinction VISUALLY CLEAR AND EFFORTLESS TO IDENTIFY — for example:

Displaying a VISIBLE LABEL, ICON, OR COLOR CODE showing which internal number each message belongs to.

Offering TABS OR FILTERS FOR EACH PHONE NUMBER, so users can view conversations for one number at a time, or switch to a COMBINED TAB that shows all messages together if desired.

This would make the Conversations page far more usable for real-world teams with multiple people communicating through separate numbers.

This issue has been raised before, but it appears to continually be overlooked. It’s not a minor design preference — it’s a CORE USABILITY FLAW that causes confusion, duplicated work, and communication errors daily. PLEASE CONSIDER PRIORITIZING A SOLUTION.