Skip to main content
Feature

Team collaboration — internal notes, role-based access, activity timeline

BlueHill ships 6 role tiers, internal-notes that customers never see, mentions, and an activity timeline per customer — so your team can collaborate without leaking context to customers.

What team collaboration in BlueHill looks like

The way BlueHill is designed for teams: every action lives on a customer record (or on a ticket, task, form linked to a customer), and the team's collaboration layer wraps around those actions without polluting the customer's view.

Three core building blocks:

  1. Six role tiers that scope visibility and capability
  2. The internal-notes layer that's invisible to customers
  3. The activity timeline that gives anyone-with-access full context on first click

Role tiers in detail

| Role | Sees | Can do | |---|---|---| | Owner | Everything | Everything including billing | | Admin | Everything | Configure tenant, manage users, all entities | | Manager | All customers in assigned teams | Approve, escalate, reassign | | Team | All customers in assigned teams | Read all, write to assigned | | Member | Customers explicitly assigned | Read + write own customers | | Portal User | Only their own company | Submit tickets, complete forms |

The role hierarchy is enforced at the query layer (MemberRelationship model controls who-sees-what), not just the UI. A Member account literally cannot fetch data for a customer they aren't assigned to — even via API.

Internal notes — the "we never tell the customer" layer

Every interaction in BlueHill is typed. The typing matters because it controls visibility:

| Interaction type | On customer portal? | In customer email? | |---|---|---| | EMAIL_INBOUND | ✓ (came from customer) | ✓ | | EMAIL_OUTBOUND | ✓ (sent to customer) | ✓ | | PHONE_CALL | ✗ | ✗ | | SMS | ✓ (if sent) | n/a | | MEETING | ✗ (unless calendar invite was sent) | ✗ | | NOTE | ✗ (internal context) | ✗ | | INTERNAL_NOTE | ✗ (explicitly hidden) | ✗ | | SYSTEM | ✗ (status changes, etc.) | ✗ |

The two-layer separation means your team can debate next steps, capture sensitive details, or discuss a difficult customer in the internal layer — without any risk that the customer will accidentally see it. The internal-notes filter is enforced at every API boundary.

@mentions

Internal notes (and ticket comments) support @mentions. Type @ and a list of teammates appears. Tagging a teammate:

  1. Notifies them by email and in-app
  2. Surfaces the mention in their personal inbox view
  3. Records the mention in the activity timeline

@mentions never appear in customer-visible content — they're a team-only convention.

Activity timeline

Every meaningful event in BlueHill is appended to the task_activity event log. The log is queryable, filterable, and surfaces in three places:

  1. Per-customer activity — chronological history of everything that's happened with this customer. New CSMs catch up in 5 minutes instead of reading email threads for an hour.
  2. Per-team activity — what your team has been doing this week. Useful for standups and capacity reviews.
  3. Per-account dashboard — leadership view across the portfolio.

The activity timeline is also the source of truth for analytics — every status report, every SLA dashboard pulls from this log. Which means if it's not in the activity log, it didn't happen.

Per-team scoping

For larger teams (especially agencies and managed-services firms), the per-team scoping matters. A team can be:

  • A pod of CSMs handling a customer segment
  • An agency's client-services team handling specific client accounts
  • A geographic region
  • A vertical-industry team

Members within a team see all customers in that team. Members across teams don't see each other's customers by default. Managers can be granted cross-team visibility for capacity balancing.

Portal-assignee vs internal-assigned

For ownership changes, there's a subtle but important detail: the customer sees a portal_assignee field that can be stable even when the internal assigned_to field rotates. So you can hand off a customer between three CSMs internally over a quarter, and the customer sees the same "main contact" on their portal the whole time.

If you want the customer to know about an owner change, you set both fields together. If you want the customer to feel stability while you rebalance internal load, you keep portal_assignee constant.

What's coming

Slack integration for real-time team chat next to the customer record is the most-requested item — on the roadmap, not yet shipped. Today, teams either:

  1. Use Slack independently and reference BlueHill links in their messages
  2. Wire BlueHill webhook events to Slack channels (~10 lines of glue or a Zap)

What this replaces

Teams arriving at BlueHill for the collaboration layer are usually moving off:

  • Slack DMs that lose context once the thread scrolls off
  • Email forwards with customer info copy-pasted ("FYI, see below")
  • Private Notion docs that fall out of sync
  • "Cc me on every email to the customer" — which floods inboxes

Built for

Try it

Start a 14-day free trial — no credit card required.