Communicating with Partners, Site Owners, and Their Teams

This page has information about the way we communicate and interact with our clients (we prefer to call them “partners” or “site owners”).

All messages from our internal team, TAMs, and contract TAMs should come from ███████████████

All emailed communications should come from a our ███████████████ as we want our partners to only send us email to our shared inbox, where we have folks scheduled to respond and more of us available in case whomever the partner is emailing is out. We try to never expose our individual email addresses to the partner (however, calendar invitations and sharing a Google Docs will reveal individual email addresses). If a partner does email you at your individual address, forward the message to███████████████ and reply from there. You should include a quick note reminding them that they should send all messages to ███████████████ going forward. Note that if a partner prefers a medium other than email to communicate about project statuses, we’ll typically accommodate the request. Start a Slack conversation if a partner requests updates through a medium other than email.

We suggest using video chats strategically. Phases of the project that may warrant a video chat are the project kickoff, design discovery, and training the site owner or their team on the site. We always offer to jump on a video call if the partner seems frustrated or if we have to deliver a potentially disappointing project update.

Tools we use for video:

Zoom: video and screen share, and recording (if applicable and approved by the partner). Free accounts limit calls to 40 minutes.
Google Meet: video and screen share, and recording (if applicable and approved by the partner). The “Add Google Meet Video Conferencing” option must be selected to the calendar invitation when scheduling the meeting, or edited to include this option afterwards.
Loom: screen recording with voice-over—great for showing how to do something on the site.
Google Docs: good for collaborating with site owners if they note they’re comfortable doing so. Contractors should share any Google Docs they prepare for a partner with ███████████████. This gives the entire internal team access (no need to add folks individually).

Note taking consent: Please ensure you gather consent from participants on the call before starting any automatic video, transcription, or note taking tool. If someone on the call is not comfortable with that or gives their consent it’s important that we respect that.

Documenting video calls

When scheduling a video call:

Note the time and date on the related project’s P2 so others are aware that the call is scheduled.
Post notes on what was discussed on the call in the same project P2 thread as soon as the call has ended.

Shared Slack channels

If a partner prefers to use Slack for project collaboration, our required method is using a Slack Connect channel shared between our Automattic Slack and the partner’s Slack rather than inviting them as a single-channel user to our Slack; or our team joining their Slack directly. A channel set up using our Slack Connect allows anyone on our team to join the channel to monitor updates or cover during AFK, anyone on the partner’s team to join the channel on their end, and the flexibility to invite external agencies into the channel for collaboration as well.

Slack Connect requires a paid Slack plan from both the Inviter and Invitee. Slack Connect also requires approval from A8c’s Slack Admins when we are the Inviter. Once you create the shared channel in A8C’s workspace and the invite is accepted by the partner, an approval request will show up in #slack-admins in Slack. If you invite additional people to the pre-existing channel later on, an approval request will also show up in #slack-admins in Slack.

If you’re working on an internal project with another team at Automattic, a project-specific shared Slack channel is also beneficial (see Working and communicating with other teams at A8c).

Setting up a shared Slack channel

Naming the channel
- All channels should start with ███████████████- and include a clear naming of what the channel is about.
- Add -pub if an external user is added, e.g. a contractor or Pressable employee. Example:
  ███████████████
- Add -partner for partner-facing channels, and include the partner name. Example:
  ███████████████
Once you’ve settled on a name, create the channel and invite members. Remember that Slack Connect users require approval from A8c’s Slack Admins, ███████████████.
Once the channel is created, add your team leads to the channel and make a note of the channel name on the Project P2. Add the Slack channel to the Linear Project and Partner.

For any -pub (external), -partner (shared with a partner), or Slack Connect (shared with either agency or partner’s) channels, remember: don’t share internal A8C links or info in this channel, because contractors and third-party developers are considered external to Automattic.

Launch projects and ongoing support in Slack

When communicating with a partner in Slack, our standard is to transition to email support once a project has been completed or launched. It’s beneficial to establish this expectation with the partner beforehand, preferably before creating the channel. We very rarely offer ongoing support in Slack after launch, except for some internal teams and edge cases. If you are unsure, please reach out to your team lead to discuss.

Communication style, tone, and philosophy

We aim for high-quality interactions with site owners, so written communication should be error-free. Additionally, all communications (verbal or written) should be:

Collaborative

We refer to our clients as “partners” because our work with them is a collaboration, a joint effort to produce an end result that we can all celebrate. We are not a vendor, we’re a trusted guide through having a great WordPress experience.

We should avoid any language that is transactional, or that evokes any kind of “them vs. us” dynamic.

It’s not “the partner’s issue” it’s “the issue we’re working on together.”
We’re not “closing this out,” we’re “agreeing that this has been fully addressed.”
We don’t tell a partner that “I need you to…,” but instead help them understand that “in order to do X, the next steps are…”

Where possible we should use individual names and bring a warm and professional familiarity to our interactions.

Empowering

While we do a lot of work for our partners on their behalf, we should always have a goal of helping them “learn to fish” when they are able and interested.

We should always offer to involve the partner in work we’re doing for them as much as they’re interested. “If you’d like we could set up a screen share while I go through those steps…” or “I can put together some documentation for you about how I did that.”
If we provide a technical answer or explanation, we should try to link to documentation that goes in to detail. “Here’s some more information about that.”
We should definitely avoid any jargon or overly detailed technical explanations that may intimidate or frustrate a partner contact.
We should invite further discussion and inquiry wherever possible. A partner should never feel like they’re bothering us or taking up too much time. “If you have any questions or if you need anything else, just let me know.”

A partner should always know what’s expected of them, what they can expect of us, and what our recommendations are for how we can work best together.

Clear

We should always substitute the precise and clear for the vague and open-ended.

“We’ll follow up soon” should become “I’ll get back to you about this by the end of the day Tuesday.”
“I’ll send you some more information” should become “I’ll be sending you a link to X along with a project brief, which we’ll look for you to review and approve.”
Adopt “bottom posting” or quoting the item you’re responding to directly above your response.

We should also assume the attention of our partners is scattered across many things, and that any time we can assist them with a refresher on what we’re referencing, what was discussed, what was agreed upon, we’re helping them get things done faster.

“Regarding your question about the best way to turn on feature X on site Y…”
“I know we talked last week about your plan to do X and I’m following up…”

Concise

We should make sure our communications are only as long as they need to be to convey information critical for the partner to see in that moment. If there is significant additional information to convey, try to do that via a linked document or attachment, making it clear who needs to look at that and whether any response/action is needed.

We should also format our messages for ultimate readability and scan-ability. If a partner can’t figure out the gist of what’s being communicated and what’s being asked of them in a few minutes or less, then the message isn’t as effective as it could be.

Use clear introductions of what the message is about. “I’m writing to follow up on the question about…”
Use bullet points for enumerating lists like timelines, next steps, shared agreements, conversation points.
Put any important links on a line by itself, instead of burying it in a wall of text.

Avoid insensitive language

Avoid insensitive language or euphemisms. Some examples:

“Dead”. Use “due date” instead of “deadline”; “broken links” instead of “dead links”.
“Headless”. Use “decoupled” instead.