> For the complete documentation index, see [llms.txt](https://docs.released.so/guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.released.so/guide/getting-started/best-practices/customer-communication.md). # Customer Communication ## Customer portal A Portal gives customers a dedicated space to see updates, roadmaps, and provide feedback. Tailoring it to the right audience ensures messaging is relevant and actionable. ### Audience selection (decision guide) * **Public**: Discoverability and transparency. No verification; restrict sensitive content. * **Private**: Invite-only for key accounts, internal stakeholders or betas. Higher verification; share detailed plans. ### Branding (quick checklist) * [ ] Logo: 256×256 PNG/SVG, square or circle. * [ ] Colors: Use brand tokens (primary, background, accent). Ensure contrast accessibility. * [ ] Tone: Clear, friendly, and outcome-focused. Avoid jargon. Documentation: [Portal](/guide/product/portals/portal.md) ### Verified users [Configure access](/guide/product/portals/access.md) and verification settings so the right users can view and interact with the Portal without friction. ## Roadmaps A public roadmap helps customers see what’s coming next and understand your priorities, which reduces uncertainty and builds trust. It also aligns expectations, reduces repetitive support questions, and demonstrates transparency by showing that customer feedback is considered. Sharing your roadmap gives customers confidence that work is actively happening and priorities are thoughtfully managed, while also inviting feedback to validate demand before investing in development. ### Roadmap structure Use Now / Next / Later columns to organize your initiatives and communicate priorities clearly: * **Now**: Work that is actively in progress or about to be released. This shows customers and stakeholders what they can expect imminently. * **Next**: Initiatives planned for the near term. These items are on the horizon and give visibility into what’s coming after current priorities. * **Later**: Ideas or initiatives under consideration. This helps signal longer-term thinking without committing to a timeline. * **Exploring**: An optional column or separate board for concepts you’re investigating but aren’t ready to commit to. Sharing these shows transparency and invites feedback early, while keeping the main roadmap focused on tangible priorities. Keep your roadmap focused on initiatives planned for the next 12 months, rather than speculative work that might happen years from now. ### Fields to include Most work item fields are useful internally but create noise for customers. Without full context, fields like priority can mislead or invite debate. Share only what helps customers understand the feature at a glance. Recommended: expose a single contextual field. Either “Category” or “Theme.” Both clearly signal what the feature relates to without implying internal commitments or rank. ## Feedback Feedback gives customers a voice and provides signals about what matters most to them. It also creates engagement and strengthens your relationship. ### Configuration tips * [Enable the Feedback](/guide/product/feedback.md) module in your workspace so users can submit ideas, comment on roadmap items, and add things to their [Wishlist](/guide/product/feedback/wishlists.md). * Use [feedback visibility](/guide/product/feedback/settings.md#feedback-visibility) to match your requirements * Make feedback accessible **everyone** to create a community feel. * Make feedback only accessible to the **author** and your team to keep feedback private. * Monitor the [Inbox](/guide/product/feedback/inbox.md) regularly to respond and link feedback to roadmap items or ideas. * [Limit the number of wishes](/guide/product/feedback/settings.md#maximum-wishes-per-user) to force customers and stakeholder to prioritize. **Recommended reading** ## Release Notes Release Notes keep customers informed about what’s changed, showing progress and demonstrating responsiveness to their needs. ### Writing style Ship stories, not changelists. * Outcome-first headlines: Lead with the user benefit, not the feature name. * Proof points: Include one visual or short Loom for complex features. * Focus on one or two key features, followed by a list of small improvements and bugfixes. * Upgrade notes: Add “how to enable” and “known limitations” where relevant. * Cross-links: Link to docs, roadmap item, and feedback thread to deepen context. * Use [templates](/guide/product/changelog/templates.md) for consistency. * [Adjust the AI prompts](/guide/product/changelog/settings/artificial-intelligence.md) for each work item type to match the desired style. ### Voice and Tone Guide Be human, direct, and helpful. * Clarity over cleverness: Avoid buzzwords; prefer plain English and concrete outcomes. * Empathy: Acknowledge trade-offs and uncertainty explicitly. * Consistency: Use consistent labels (Now/Next/Later/Exploring) across surfaces. * Promises: Avoid hard dates unless ready; offer ranges or criteria instead. ### Keep a consistent cadence Regular updates maintain engagement, build trust, and ensure your communication doesn’t feel ad-hoc. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.released.so/guide/getting-started/best-practices/customer-communication.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.