Smart Mentions — User Guide

Recommended operating roles:

• Collaboration Admin
• Governs mention usage rules, response SLAs, and escalation standards.
• Can define module-level policy and review behavior trends.
• Reviews adoption quality and unresolved mention patterns.
• Should not use mentions as a substitute for formal access/permission controls.

• Module Owner
• Governs rollout priorities by record type and team process.
• Can publish working standards for message clarity and closure behavior.
• Reviews weekly outcomes by team and unresolved escalations.
• Should not allow mention threads to replace required task/ticket lifecycles.

• Team Member
• Can post contextual mentions in records and respond to incoming requests.
• Can reference related records with `#` where enabled.
• Reviews pending requests assigned to them and closes loops with updates.
• Should not post vague, ownerless, or non-actionable mention messages.

• Manager / Reviewer
• Governs response discipline and escalation quality within their team.
• Can review mention outputs by user/team and coach process behavior.
• Reviews open vs resolved threads and response-time trends.
• Should not use mentions for general broadcast chatter without ownership.

Use this checklist before rollout:

1. Confirm record coverage

• Verify Smart Mentions is enabled in the records your teams use most.
• Confirm notes/comments/posts are available where follow-up typically happens.

1. Confirm people and object references

• Validate `@` mentions for users.
• Validate `#` references for related objects where enabled.

1. Define response SLAs

• Set expected response windows by urgency level.
• Clarify escalation thresholds for overdue requests.

1. Define message format standards

• Require: owner, action, urgency, due date, and expected outcome.
• Add examples for high-quality and low-quality mentions.

1. Define escalation behavior

• Specify when to escalate blocked work.
• Define who is mentioned first, and who is included on second-level escalation.

1. Define closure expectations

• Require a closure update in the same thread.
• Clarify what qualifies as resolved vs still pending.

1. Prioritize record types for adoption

• Start with high-impact records (sales handoffs, invoices, projects, support cases, operations dependencies).
• Expand to additional modules after initial behavior stabilizes.

1. Test cross-team scenarios

• Run test flows across sales, finance, operations, projects, and support.
• Validate owner clarity, response speed, and closure quality before full rollout.

Workflow 1: Mention a teammate on a record

1. Open the target record.
2. Add a note, comment, or post.
3. Type `@` and select the teammate.
4. Write the action request and priority.
5. Save the update.
6. Follow up in the same record until closure.

Workflow 2: Reference a related business object

1. Open the current note/comment area.
2. Type `#`.
3. Select the related project, invoice, customer, estimate, contract, expense, lead, or proposal.
4. Insert the reference.
5. Keep discussion tied to the correct object.

Workflow 3: Escalate blocked work

1. Identify the blocker in the source record.
2. Mention the responsible owner.
3. Add a `#` reference to the affected record/dependency.
4. Add required decision, deadline, and next action.
5. Review and update the thread until closure.

Workflow 4: Multi-team handoff

1. Add a contextual handoff note in the source record.
2. Mention the receiving owner/team.
3. Reference linked records needed for action.
4. Clarify action, due date, and urgency.
5. Keep the handoff history in the same thread.

Workflow 5: Resolve a mention follow-up

1. Open the mention context.
2. Review linked record details.
3. Complete the requested action.
4. Reply with status and outcome.
5. Mark/treat the thread as resolved based on team practice.

Workflow 6: Weekly review of open mentions

1. Review open mention threads.
2. Identify overdue follow-ups.
3. Review response patterns by team/user.
4. Coach teams on clarity and ownership discipline.
5. Update usage rules where repeated issues appear.

• Mention volume by user/team
• Contains adoption and usage intensity by owner/team.
• Used by: Collaboration Admins and managers.
• Supports decisions on training priorities and staffing pressure points.

• Open vs resolved mention threads
• Contains closure posture and unresolved follow-up backlog.
• Used by: Module Owners and team leads.
• Supports decisions on escalation enforcement and closure discipline.

• Mentions by module/record type
• Contains where mention activity is concentrated across processes.
• Used by: Process owners and operations reviewers.
• Supports decisions on where to deepen adoption or redesign handoffs.

• Response-time review
• Contains average and outlier response behavior by team/user.
• Used by: Managers and operational reviewers.
• Supports decisions on SLA tuning, coaching, and accountability.

• Escalation hot spots
• Contains repeated blocker and escalation patterns by department/workflow.
• Used by: Operations leadership.
• Supports decisions on process fixes, ownership changes, and dependency redesign.

Mentions are not appearing correctly

• Confirm mention syntax is used properly (`@` for people, `#` for records).
• Confirm the update was saved in a supported note/comment/post area.
• Validate that the referenced user/record is available in that context.

Tagged user is not responding

• Check urgency and due date clarity in the original message.
• Apply escalation policy when SLA is exceeded.
• Review team response trends in weekly operations review.

Too many low-value mentions

• Enforce message format standards.
• Require clear owner and outcome language.
• Coach teams using real thread examples.

Confusion between `@` and `#`

• Use `@` for people ownership.
• Use `#` for record/object references.
• Include both when assigning action on a related record.

Object references are not used consistently

• Add examples in team onboarding.
• Require `#` references for cross-record dependencies.
• Review compliance during weekly quality checks.

No closure comment is added

• Set closure comment as required practice.
• Review unresolved threads weekly.
• Escalate repeated non-closure behavior to managers.

Legacy `smart-mention` page causes confusion

• Use Smart Mentions as the public name everywhere.
• Treat `smart-mention` only as a legacy alias/redirect.
• Keep user-facing titles and links on the plural canonical route.

Confusion between Smart Mentions and chat/ticket workflows

• Smart Mentions = contextual collaboration inside records.
• Chat tools = broad conversation channels.
• Support Desk = structured service/ticket lifecycle.