Purpose

This SOP outlines when and how Britecode team members should create customer-specific documentation for website functionality, especially for WordPress, WooCommerce, and custom-built features.

The goal is to:

  • Reduce repetitive support requests

  • Empower hands-on clients

  • Provide a clear reference point for training

  • Protect internal team time


When This SOP Applies

Create customer-specific documentation when:

  1. The client is hands-on and actively manages their website

  2. We implement custom functionality unique to that client

  3. We significantly modify plugin configurations

  4. We build custom workflows or admin tools

  5. The client repeatedly asks how to perform the same task

This does NOT need to be done for every client. It should be used for:

  • High-touch clients

  • Clients with custom builds

  • Clients who frequently access the backend


Core Principle

If a feature is custom or configured uniquely for the client, document it.

If a feature already has high-quality official documentation (e.g., WooCommerce coupons), link to it instead of recreating it.


Documentation Structure

Each client documentation file should:

• Be created as a dedicated Google Doc • Be stored in the client’s project folder • Be linked inside the project management system (e.g., under Website Updates or Documentation section) • Include a Table of Contents for easy navigation


Recommended Document Sections

1. Admin Access Information

  • Admin URL

  • Login path instructions

  • Any relevant access notes

(Do NOT store passwords in the document.)


2. Frequently Used Features

Identify features the client regularly uses, such as:

  • Creating products

  • Managing orders

  • Creating coupons

  • Updating content

  • Managing affiliates

If the feature is standard (e.g., WooCommerce coupons):

  • Link to official documentation instead of rewriting instructions

Example: "How to Create Coupons in WooCommerce" → Link to official WooCommerce guide


3. Custom Features (Required Section)

For any custom functionality we implement, include:

  • Feature name

  • What it does

  • Where to find it in admin

  • Step-by-step instructions

  • Screenshots when helpful

  • Common mistakes to avoid

These should be written clearly and simply, step-by-step.

Example structure:

Custom Feature: XYZ Membership Override

  1. Log into admin

  2. Navigate to XYZ Settings

  3. Select membership tier

  4. Click Update


4. Custom Plugin Configurations

If we modify a plugin in a non-standard way:

  • Explain what was changed

  • Explain how the client interacts with it

  • Note any limitations


5. Special Workflows

If the client has unique workflows (e.g., affiliate management, conditional checkout logic, custom CRM triggers):

Document:

  • What triggers the workflow

  • What happens automatically

  • What actions the client must take


Why This Matters

Clients forget.

Even if we train them multiple times, they will ask again. Instead of retraining every time, we can:

  1. Send them the guide

  2. Reference the exact section

  3. Offer assistance if needed

This saves internal time and builds professionalism.


Maintenance of Documentation

Update the client’s documentation when:

  • We add new features

  • We modify custom functionality

  • We change workflows

  • We replace plugins

Documentation should evolve with the site.


Best Practices

• Keep language simple
• Use step-by-step formatting
• Avoid technical jargon
• Link to official resources when available
• Focus documentation only on what the client actually uses
• Do not over-document unnecessary features


Summary

For hands-on clients and custom builds, create a dedicated documentation guide.

Link official documentation for standard features.

Fully document custom implementations.

Reference the guide instead of retraining repeatedly.

This should be standard practice for clients where we build custom functionality or expect ongoing admin interaction.