Post Go Live

Post Go Live Services Stage Overview and Training Guide


Purpose

This training guide outlines the standardized process for managing projects that have successfully gone live but still require additional services, billing coordination, or follow up activities. The goal is to improve visibility into post go live work, ensure proper project tracking, and support accurate operational and billing workflows within Salesforce and TaskRay.


Overview of the New Process

Historically, projects that were technically live but still required additional activities were being manually labeled by users within the project title as “Post Go Live.” This created inconsistencies and lacked standardized reporting visibility.

To resolve this, a new official project stage has been introduced:


Post Go Live Services

This new stage provides:

  • Standardized visibility into projects requiring post deployment work
  • Improved reporting and operational tracking
  • Conditional billing controls
  • Better lifecycle management between Go Live and Full Completion


Previous Process

Prior State

After a project went live:

  • The project was typically moved into the Closing stage
  • Users manually appended text such as:
    • “Post Go Live”
    • “Post Go Live Support”
    • “Post Go Live Services”
  • There was no formal project stage representing this operational status
  • Reporting and dashboards could not easily distinguish projects still requiring work after deployment


New Standardized Process

New Project Stage

A new project stage has been added:

Post Go Live Services

This stage should now be used whenever:

  • The customer is officially live
  • Core deployment activities are complete
  • Additional follow up work still remains

Examples include:

  • SaaS billing coordination
  • PaaS billing coordination
  • Additional consulting services
  • Remaining configuration tasks
  • Post deployment support activities
  • Final operational validation items


Step by Step Process

Step 1 — Confirm Customer Go Live

Before moving a project into the new stage:

  • Confirm the customer is officially live on the platform
  • Validate that production operations have started
  • Ensure core implementation milestones are complete


Step 2 — Update the Project Stage

Navigate to the project record and update the:

Project Stage

Change the project stage to:

Post Go Live Services


Step 3 — Review Conditional Billing Fields

Once the stage is changed:

A conditional visibility rule will display a new field section related to billing classification.

This section only appears when:

Project Stage = Post Go Live Services



Billing Type Options

When the project enters the Post Go Live Services stage, the following billing classifications become available:

Software as a Service Billing

Use when:

  • Ongoing SaaS related billing activities are required
  • Cloud hosted software services remain active
  • SaaS operational coordination is still pending


Platform as a Service Billing

Use when:

  • PaaS related infrastructure or hosting services are involved
  • Platform billing coordination is required
  • Additional platform support activities remain open


Conditional Visibility Logic

Important Behavior

The billing classification fields:

  • ONLY appear when the project stage is set to:
    • Post Go Live Services
  • DO NOT appear while the project remains in:
    • Closing
    • Executing
    • Other project stages

This ensures:

  • Cleaner project layouts
  • Reduced user confusion
  • Relevant field exposure only when needed


Why This Approach Was Selected

The team evaluated creating separate project stages such as:

  • SaaS Billing
  • PaaS Billing

However, it was determined that:

  • Only a subset of projects require these workflows
  • Separate stages would create unnecessary complexity
  • A conditional billing model inside a single Post Go Live Services stage provides cleaner governance

This design keeps the project lifecycle streamlined while still supporting operational visibility.



Operational Benefits

Improved Reporting

Leadership and PMO teams can now:

  • Identify all projects currently in post go live activity
  • Report accurately on deployment completion versus remaining work
  • Track projects requiring ongoing billing coordination


Improved Governance

The new process:

  • Eliminates inconsistent manual naming conventions
  • Standardizes lifecycle tracking
  • Improves project health visibility


Improved Customer Lifecycle Management

This stage helps distinguish between:

  • Customers who are fully complete
  • Customers who are live but still receiving services

This provides more accurate operational status tracking across PMO, Customer Success, Billing, and Support teams.



Recommended Usage Guidelines

Use “Post Go Live Services” When:

✅ Customer is live
✅ Additional services still remain
✅ Billing coordination is ongoing
✅ Final support or consulting tasks remain open


Do NOT Use “Post Go Live Services” When:

❌ Customer is not yet live
❌ Core implementation work is still actively underway
❌ The project should remain in Executing or Planning


Examples

PaaS project - Customer failer is completed and they are live in SaaS =  Post Go Live 

IaaS project - Customer phone porting is completed =  Post Go Live 

On Prem Migration - Customer golive is completed = Post Go Live 

Consulting - All scoped deliverables are complete = Close the project (Post Go Live isn't required as there are no outstanding tasks)

Consulting - All scoped deliverables are complete, but there is a Support Ticket raised = Post Go Live 

Licence  - All deliverables are complete = Close the project

Add On Module - All scoped deliverables are complete = Close the project (Post Go Live isn't required as there are no outstanding tasks)

 Add On Module - All scoped deliverables are complete, but there is a Support Ticket raised = Post Go Live 

 


Key Takeaways

  • “Post Go Live Services” is now the official standardized stage for projects that are live but still require additional services
  • Manual title modifications should no longer be used
  • Billing classification fields appear dynamically based on project stage
  • The process improves reporting, governance, and operational visibility
  • This workflow supports cleaner project lifecycle management across the organization
Was this article helpful?
Thank you for your feedback!
User Icon

Thank you! Your comment has been submitted for approval.