You are 100% right, documentation can't fix it. Having been involved in onboarding acquisitions into a larger parent company, it's been eye-opening to see how much of this is driven by culture.
The parent company's culture may be patient, contemplative, considerate, and proactive. They know it takes a long time to get things done and that everyone is busy. They open tickets, do research, seek advice from multiple groups. They double-check that they did something correctly, having learned that entering something incorrectly leads to it taking longer to get done. They check your slack status, and follow up after a few days if they don't get a reply e-mail.
But sometimes an acquisition's culture is quite different. A lot of 'drop everything right now, I need you to do something for me'. Using '@here' a lot and directly pinging people for non-urgent things. Or leaving a comment in a ticket like 'the backend team needs to fix this' but not going to the actual team to tell them they need to fix it and how. If they don't get a reply to an e-mail, they might wait forever.
None of this is due to good or bad people. The acquisition culture can be changed over time to the parent company's culture. But there needs to be a concerted effort to teach and exemplify the culture, though cooperation, trust, and leading by example.
Rather than a 'user guide', you can have informal discussions with groups and agree on some common communication strategies. You can discuss how different forms of communication affect you and build empathy within your team. And if the team ends up wanting varying ways of communication, then you can write user guides and publish them somewhere. The agile approach is more about building culture collaboratively and informally, and documenting what comes out of that as a de-facto standard.