270708 Delivery Model Redesign

Date: 2026-07-08 Status: rough solution design, not implemented

Idea is to

Starting Point

Delivery Models are still useful, but their purpose should stay narrow:

They are sub-parts of Deals where time can be tracked against a revenue or budget line.
They should support calculating effective hourly rate and delivery progress.
They should not pretend to perfectly infer the signed commercial structure from the Deal amount.
Most Delivery Models should be manually confirmed before they are used for delivery control, reporting, or alerting.

The system's end goal is not simply to generate estimated hours. The end goal is to compare sold value, planned labour, and actual labour so the business can see the real delivery rate and margin pattern.

Proposed Principle

Treat automation as draft setup, not final commercial truth.

Automation can create or refresh a starting point while a record is still in a draft/unconfirmed state. Once a Delivery Model has been manually confirmed, automation should stop overwriting its amount, labour unit, labour amount, or scope unless a user explicitly requests a recalculation.

That implies Delivery Models need explicit state, for example:

Budget_Status: Draft, Confirmed, Retired;
Budget_Source: Deal Default, Manual, Managed Services Plan, Imported/Legacy;
possibly Auto_Calculate_From_Deal: true/false, if a simpler control is preferred.

The exact field names are open, but the important point is that the system needs a durable way to tell "this value is still an automated suggestion" from "this value has been manually approved".

Target Conceptual Model

Deals

Deals remain the sales and commercial handoff record.

They should answer:

What was sold?
Who bought it?
What is the signed value or first invoice value?
What delivery workspace should be created?

Deals should not be the long-term source of truth for recurring MSP service delivery. For recurring MSP work, the Deal starts or changes a commercial relationship, but the ongoing service model belongs on the Managed Services Plan.

The Managed Services / MSP Deal category should be reserved for Deals that create or change a Managed Services Plan. A client can have other Deals and projects at the same time, but those should stay in the appropriate business category, such as Tech Projects or Hardware. A separate project for an existing managed services client should not become an MSP Deal just because the client is an MSP client.

The target operating rule should be one active Managed Services Plan per company. A new PO or Deal for the same managed services relationship should update the existing plan, seats, invoice lines, and plan-derived budgets rather than creating a second active plan. If a customer genuinely needs separate managed services arrangements, that should be an explicit exception with clear reporting and automation rules.

Delivery Models

Delivery Models should represent project delivery budget lines.

They should answer:

Which scope of project work does this budget line cover?
What revenue amount is attached to that scope?
What labour budget is expected?
How much time has actually been logged?
What effective hourly rate or day rate is emerging?

For Tech Projects, a Deal may create one draft Delivery Model as a starting point. The Delivery team can then confirm it, edit it, or split it into multiple models for separate budget lines.

For MSP Deals, Delivery Models should not be generated from the Deal just to represent recurring support. If onboarding or implementation is sold as a one-off project, that may still deserve a Delivery Model, but recurring service capacity should come from the Managed Services Plan path.

Managed Services Plans

Managed Services Plans should become the source of truth for MSP recurring service economics.

They already represent the recurring client relationship for invoicing. The same record, or a closely linked resource-budget record, should answer:

What plan is active?
What support level or service model applies?
How many seats or covered users are active?
What recurring revenue is expected?
What monthly labour allowance or expectation follows from the plan?
Which time should count against that plan?

This moves MSP reporting away from Deal-created Delivery Models and toward the record that actually survives beyond the sales handoff.

Tech Project Flow

For Tech Project Deals:

Deal creation still creates a project and Scoping setup.
Moving to Reserved, Approval and Payment Pending still closes scoping.
The automation may create one draft project-scoped Delivery Model named from the Deal or project.
The draft default may use:
- Amount from the Deal amount;
- Labour_Unit as Day;
- Labour_Amount from a default day-rate calculation.
The model remains Draft until someone confirms the budget.
Deal amount updates may refresh the draft model only while it is unconfirmed.
Once confirmed, later Deal amount changes should create a review warning, not silently rewrite the budget.

This keeps the useful default without treating it as authoritative.

For more complex Tech Projects, the expected workflow is manual split:

one Delivery Model per meaningful budget line;
scopes can be project, tasklist, phase, or task depending on how delivery is tracked;
each model has its own amount and labour budget;
reporting rolls those models back up to the Deal and project.

MSP Flow

For MSP Deals, separate three cases.

Recurring Managed Services

Recurring service should be modeled from Managed Services Plans, not from Deal-created Delivery Models.

At this stage, the redesign should not assume the Managed Services Plan can be created automatically from a Deal. There are still too many onboarding, commercial, seat, invoice-line, support-level, and plan-change gaps. The near-term approach should be:

use the Deal category only to identify that the Deal contains a managed services plan or managed services plan change;
create or update the Managed Services Plan through the onboarding process;
use plan-level automation only after the plan record has enough confirmed data to drive billing, support budgets, and reporting safely.

The likely direction is:

Managed Services Plan identifies the client, billing window, plan status, and plan type/service level.
MSP Seats identify covered users and their billing/service windows.
MSP Invoice Lines and Products identify recurring revenue composition.
A new MSP resource-budget layer derives or stores expected labour per month.

That resource-budget layer could be implemented in one of two ways:

Reuse Delivery Models linked to MSP_Plan, but generate them from the plan workflow rather than the Deal workflow.
Create a separate MSP plan budget/reporting model and leave Delivery Models for project-style scopes only.

Recommendation for the next version: use option 1. Reuse Delivery Models for plan-derived MSP support budgets, but make them clearly plan-owned rather than Deal-owned. The Delivery Model should link to MSP_Plan, use Revenue_Model Recurring, and carry the expected monthly labour budget for the active plan period.

Option 2 is cleaner conceptually as a later model, but it should wait until the Power BI timesheet model and alerting engine no longer depend directly on Delivery Models.

MSP Onboarding

One-off onboarding is different from recurring support.

If onboarding is sold as a distinct implementation scope, it can still be represented as a project Delivery Model. Its amount and labour should come from the signed onboarding scope and be manually confirmed.

It should not be mixed into the recurring support model unless the commercial agreement actually includes onboarding inside the recurring fee.

MSP Support Time

MSP support time needs a reliable mapping to the active Managed Services Plan.

Open mapping choices:

by support project linked to the Account or MSP Plan;
by Zoho Projects tasklist or project convention;
by CRM Account plus active plan date range;
by explicit MSP_Plan lookup on time-reporting metadata if available later.

This mapping is more important than preserving the current Deal-created Tech Support Delivery Model, because the plan is the long-lived contract.

Reporting Shape

Reporting should probably move toward a unified budget-line semantic layer.

Inputs:

Tech Project Delivery Models;
one-off onboarding Delivery Models where applicable;
MSP plan budget rows from Managed Services Plans or linked budget records;
timelogs mapped to the best project scope or MSP plan;
revenue from Deals for project work and from MSP invoice/plan data for recurring work.

Core measures:

sold or recurring revenue;
planned labour hours or days;
actual logged labour;
effective hourly rate;
budget consumption percentage;
revenue recognized or cumulated amount;
draft versus confirmed budget status;
over-budget or under-budget flags.

The important reporting distinction is:

project Delivery Models measure delivery against scoped project budget lines;
MSP plan budgets measure recurring service economics over time.

Alerts and PBI Continuity

The redesign must preserve the two existing consumers that directly depend on Delivery Models:

milestone alerts, which currently read active Delivery Models, calculate completion, write progress state, and send CRM Delivery Model emails;
the pbi/project-timesheets model, which currently uses the delivery-models-report output as the budget and scope table for timesheet analysis.

This means the migration should be additive and compatibility-first. We should not remove or stop generating Delivery Models for an area until the alert path and Power BI model have an equivalent replacement view.

The likely reporting direction is a normalized budget lines view with a stable schema:

source type: Delivery Model, MSP Plan Budget, Legacy;
stable budget-line ID;
CRM record ID and link back to the source record;
project ID and scope identifiers where time maps through Zoho Projects;
account, Deal, and MSP Plan metadata where available;
revenue amount;
labour unit and labour amount;
valid-from and valid-until dates;
draft/confirmed/retired status;
source-of-truth marker.

Initially, that view can be a wrapper over Delivery Models only. As MSP plan budget rows are added, Power BI can move from "Delivery Models are the budget table" to "Delivery Models are one source of budget rows".

Alert continuity needs the same staged approach:

Keep current Delivery Model alerts running unchanged while Tech Project defaults are improved.
Add draft/confirmed fields to Delivery Models, but decide whether alerts include draft models or only confirmed models.
If MSP plan budgets reuse Delivery Models, the current alert engine can be extended with source filters and plan metadata.
If MSP plan budgets become separate records, build a compatibility layer for alert calculations before retiring any MSP Delivery Model dependency.

The current alert implementation sends email through the CRM Delivery Models send_mail action, attached to a Delivery Model record. If future MSP budget rows are not Delivery Models, the design needs a new notification owner:

send alerts from a related Managed Services Plan;
send alerts through a generic email route;
or keep a lightweight Delivery Model compatibility record purely for alert ownership.

The safest migration principle is: every rollout step must leave the PBI timesheet report and milestone alerts meaningful on the same day it ships.

Automation Boundaries

Automation should do less guessing and more setup.

Recommended boundaries:

Create draft records when the business event is clear.
Update draft records from source data while they remain unconfirmed.
Never overwrite confirmed budget fields without an explicit user action.
Warn when source data changes after confirmation.
Use stable IDs/source markers for idempotency, not user-facing names.
Keep process docs aligned only after the implementation behavior is settled.

For the current Tech Project naming question, the safe answer is:

yes, use the Deal name as a better draft model name;
yes, use the Deal amount to calculate an initial labour budget;
no, do not treat that as final;
no, do not auto-sync forever after manual confirmation.

Tech Project Draft Invoice Flow

Tech Project Deals should also gain a finance handoff when they move to the approved/reserved status.

Proposed direction:

Trigger from the same business event as delivery setup: a Tech Project Deal moving to Reserved, Approval and Payment Pending, or the final approved stage if that stage changes later.
Create a basic CRM Invoice and Xero DRAFT invoice from the Deal.
Use the Deal account's Xero contact as the invoice contact.
Use the Deal amount as the initial invoice amount.
Use simple line text from the Deal name, project name, or signed scope reference.
Link the CRM invoice, Xero invoice ID, Xero invoice number, Deal, and project where the CRM schema allows it.
Never approve or send the Xero invoice; finance review remains required.
Refresh only while the linked Xero invoice is still DRAFT.
Once Xero is no longer DRAFT, treat it as locked and create a review item rather than mutating it.

This should be designed separately from recurring MSP invoice generation. The MSP invoice generator is plan and invoice-line driven. Tech Project draft invoice creation is Deal handoff driven and can start with deliberately basic invoice content.

Open details:

whether the draft invoice is for the full Deal amount or a deposit/first payment amount;
which Xero account code and item code should be used by default;
whether the due date comes from the Deal closing date, payment terms, or a finance default;
how duplicate protection should key the invoice: Deal ID, project ID, stage transition, or explicit invoice-purpose field;
what should happen when a Deal amount changes after the draft invoice has already been created.

Migration Sketch

Audit CRM fields available on Delivery Models and Managed Services Plans.
For the next version, reuse Delivery Models for MSP plan-derived support budgets while marking them as plan-owned through MSP_Plan and source metadata.
Add explicit draft/confirmed/source fields before changing automation.
Define the compatibility shape needed by alerts and the Power BI timesheet model before changing source records.
Update Tech Project automation to create draft Delivery Models using stable source markers and Deal-name defaults.
Add a Deal amount/name refresh path that updates only draft Tech Project models.
Add Tech Project draft invoice creation for approved/reserved Deals.
Add clear Deal-category checks so Managed Services / MSP is used only for Deals that create or change a Managed Services Plan.
Stop creating MSP recurring Delivery Models from Deal stage changes only after the PBI and alert replacement path exists.
Design Managed Services Plan resource-budget rules.
Build MSP plan reporting from plan, seat, invoice-line, and timelog data.
Backfill or classify existing Delivery Models as legacy, project, onboarding, or MSP-derived.
Update process docs only after the implemented behavior changes.

Open Decisions

When should MSP plan budgets graduate from Delivery Models to a separate budget-line model, if ever?
Should the one-active-plan-per-company rule be enforced by validation, automation warnings, reporting, or process only?
What is the manual onboarding handoff from an MSP Deal into the Managed Services Plan record?
What field should mark a Delivery Model as confirmed/manual?
Should confirmation be required before alerting and Power BI budget reporting?
Should draft models be visible in PBI with a status flag, or excluded from budget-performance views until confirmed?
What is the right default Tech Project rate: the current 1400 daily rate, a configurable rate, or no default rate beyond a draft estimate?
Should Deal amount edits after confirmation create an alert, a task, or only a report warning?
Should Deal amount edits refresh a Tech Project Xero draft while it is still DRAFT, or should finance own all invoice changes after creation?
How should MSP support timelogs map to the correct Managed Services Plan?
Does MSP onboarding belong under the Deal/project model, the MSP plan model, or both depending on how it was sold?
If MSP plan budgets are not Delivery Models, what record should own milestone alert emails?
Which historical Delivery Models are worth migrating versus leaving as legacy reporting records?

Near-Term Recommendation

Do not start with the simple rename/sync change alone. It improves the first draft but leaves the larger source-of-truth problem unresolved.

Start by adding the design controls:

explicit draft/manual confirmation state;
a clear source marker;
a decision on whether MSP plan budgets live in Delivery Models or separate plan-budget reporting;
a compatibility plan for existing alerts and the Power BI timesheet model.

After that, change Tech Project defaults and MSP behavior in separate slices.