Assist_Design/docs/operations/external-processes.md
barsa 72d0b66be7 Enhance Documentation Structure and Update Operational Runbooks
- Added a new section for operational runbooks in README.md, detailing procedures for incident response, database operations, and queue management.
- Updated the documentation structure in STRUCTURE.md to reflect the new organization of guides and resources.
- Removed the deprecated disabled-modules.md file to streamline documentation.
- Enhanced the _archive/README.md with historical notes on documentation alignment and corrections made in December 2025.
- Updated various references in the documentation to reflect the new paths and services in the integrations directory.
2025-12-23 15:55:58 +09:00

10 KiB

External Processes and Team Handoffs

This document describes operational processes that occur outside the Customer Portal but are necessary for system operation and customer service.


Process Ownership Matrix

Process Owner Trigger Dependencies Documentation
Salesforce Account Creation Sales Team Customer inquiry Salesforce Admin access Salesforce training docs
Customer Number Assignment Sales Team New customer onboarding SF Account created Sales procedures
CS Order Approval CS Team Order in "Pending Review" Salesforce access CS training docs
Internet Eligibility Check CS Team Eligibility request Case Customer address info CS procedures
WHMCS Product Setup DevOps New product launch WHMCS Admin access This document
Salesforce Flow Maintenance SF Admin Feature changes SF Admin + Dev access SF Flow documentation
Freebit Account Configuration Partner Relations New SIM products Freebit partner credentials Freebit contract docs
SSL Certificate Renewal DevOps Expiration alerts Certificate provider access This document
Database Backups DevOps Scheduled / On-demand DB Admin access Database Operations

Customer Onboarding Flow

Pre-Portal Setup (Sales Team)

Before a customer can use the portal, Sales must complete these steps:

  1. Create Salesforce Account

    • Create Account record with customer details
    • Assign unique SF_Account_No__c (Customer Number)
    • Set initial account status
  2. Verify Customer Information

    • Confirm contact details
    • Verify billing address
    • Complete KYC requirements if applicable
  3. Internet Eligibility (if applicable)

    • Submit eligibility check via portal OR
    • Manually check eligibility and update Account fields:
      • Internet_Eligibility__c
      • Internet_Eligibility_Status__c

Handoff to Portal

Once Sales completes setup, customer can:

  • Sign up using their Customer Number
  • Link existing WHMCS account (if migrating)
  • Place orders through the portal

Order Approval Flow

CS Review Process

When an order is placed, CS must review and approve:

Order Review Checklist:

  1. Verify customer identity matches Salesforce Account
  2. Confirm product eligibility (Internet type matches eligibility)
  3. Verify installation address is serviceable
  4. Check for duplicate active services
  5. Review any special instructions or notes

Approval Actions:

  • Approve: Set Order Status = Approved
    • Triggers provisioning workflow automatically
  • Reject: Set Order Status = Cancelled
    • Add rejection reason to Order notes
    • Customer is notified via portal

SLA:

  • Standard orders: Review within 2 business hours
  • Priority orders: Review within 30 minutes

Escalation Triggers

Escalate to supervisor if:

  • Customer disputes eligibility result
  • Multiple orders from same account in short period
  • Order value exceeds threshold
  • Address verification fails

Internet Eligibility Process

Request Flow

  1. Customer submits eligibility request (Portal)

    • Creates Salesforce Case (Type: Eligibility Check)
    • Updates Account fields to "Pending"
    • Creates/updates Opportunity (Stage: Introduction)
  2. CS reviews request (Salesforce)

    • Verify address details
    • Check service availability databases
    • Determine eligibility type (Apartment 1G, Home 1G, etc.)
  3. CS updates Salesforce (Salesforce)

    • Set Internet_Eligibility__c to result
    • Set Internet_Eligibility_Status__c = Checked
    • Update Opportunity stage (Ready or Void)
    • Close the Case
  4. Customer sees result (Portal)

    • Portal reads updated Account fields
    • Catalog shows eligible products

SLA:

  • Standard check: 24-48 business hours
  • Express check: 4 business hours

Cancellation Request Process

Customer-Initiated Cancellation

  1. Customer requests cancellation (Portal)

    • Creates Salesforce Case (Type: Cancellation Request)
    • Finds linked Opportunity via WHMCS_Service_ID__c
    • Updates Opportunity stage to "△Cancelling"
    • Sets ScheduledCancellationDateAndTime__c
  2. CS reviews request (Salesforce)

    • Verify customer authorization
    • Check cancellation terms and fees
    • Confirm scheduled date
  3. CS processes cancellation (WHMCS + Salesforce)

    • Cancel service in WHMCS (if not automatic)
    • Update Opportunity stage to "△Cancelled"
    • Close the Case
  4. Final billing (WHMCS)

    • Generate final invoice if applicable
    • Process any prorated refunds

Cancellation Types

Type Notice Period Effective Date
Internet 30 days End of notice period
SIM Immediate or scheduled 1st of following month
VPN Immediate Same day

Product Configuration

Adding New Products

When launching new products, coordinate between teams:

1. Salesforce Setup (SF Admin)

  • Create Product2 record
  • Set required fields:
    • Name, StockKeepingUnit
    • WH_Product_ID__c (WHMCS product ID)
    • Billing_Cycle__c
    • Item_Class__c (Service, Activation, Add-on)
  • Add to portal Pricebook (PORTAL_PRICEBOOK_ID)

2. WHMCS Setup (DevOps/Billing)

  • Create product in WHMCS Products/Services
  • Configure pricing and billing cycle
  • Set up any required custom fields
  • Test product creation via API

3. Portal Verification (Development)

  • Verify product appears in catalog
  • Test checkout flow with new product
  • Confirm provisioning works correctly

4. Documentation (All Teams)

Product Change Checklist

  • Salesforce Product2 updated
  • WHMCS product updated
  • Pricing synced between systems
  • Portal cache cleared
  • Tested in staging environment
  • Documentation updated

Salesforce Flow Maintenance

Record-Triggered Flows

The portal depends on these Salesforce Flows:

Flow Trigger Action
Order Approval Flow Order Status → Approved Publish OrderProvisionRequested__e
Eligibility Update Flow Account eligibility fields changed (Optional) Notify customer

Flow Change Procedure

  1. Development (SF Admin + Dev)

    • Clone existing Flow for modification
    • Test in Salesforce Sandbox
    • Document changes
  2. Deployment (SF Admin)

    • Schedule deployment during low-traffic period
    • Notify development team
    • Activate new Flow version
  3. Verification (Dev + QA)

    • Test affected portal functionality
    • Verify Platform Events are received
    • Check BFF logs for any errors
  4. Rollback Plan

    • Keep previous Flow version available
    • Document rollback procedure
    • Have SF Admin available during deployment

SSL Certificate Management

Certificate Inventory

Domain Provider Expiration Renewal Process
portal.example.com Let's Encrypt Auto-renew Automated
api.example.com Let's Encrypt Auto-renew Automated
whmcs.example.com [Provider] [Date] Manual

Renewal Procedure

Automated (Let's Encrypt):

  • Certbot runs automatically
  • Monitor for renewal failures
  • Alert if cert expires within 14 days

Manual:

  1. Generate CSR
  2. Submit to certificate provider
  3. Complete domain verification
  4. Download and install certificate
  5. Restart affected services
  6. Verify certificate in browser

Certificate Expiration Alerts

  • 30 days: Warning notification
  • 14 days: Urgent notification
  • 7 days: Critical alert

Credential and Access Management

Access Request Process

System Request To Approval By Access Level Options
Salesforce SF Admin Manager Read-only, CS, Admin
WHMCS DevOps Manager Staff, Admin
BFF/Portal DevOps Tech Lead Developer, Operator
Database DevOps Tech Lead Read-only, Read-write

Offboarding Checklist

When a team member leaves:

  • Revoke Salesforce access
  • Revoke WHMCS access
  • Remove from deployment systems
  • Rotate any shared credentials they had access to
  • Update on-call schedules
  • Transfer ownership of documentation

Communication Channels

Team Contacts

Team Channel Escalation
Development [Slack/Teams channel] Tech Lead
CS Team [Slack/Teams channel] CS Manager
Sales Team [Slack/Teams channel] Sales Manager
DevOps [Slack/Teams channel] Ops Lead
SF Admin [Email/Slack] IT Manager

Incident Communication

See Incident Response Runbook for incident communication procedures.



Last Updated: December 2025