Commercial Services Design
The implementation plan accompanies the commercial performance presentation. Phase 1 combines the CRM widget, Qwilr quote generation and acceptance, Service Line and Billing Event setup, and invoice drafting for new deals and projects. Reconciliation follows later. This page describes the shared model and reporting foundation; the plan defines the build sequence, remaining decisions and pilot checks. It is the single active delivery plan; this reference describes intended behaviour and identifies the implemented reporting baseline.
Status: approved universal-module direction; implementation and consolidation
remain planned. Services reuses the existing Managed_Services_Plans module;
Service Lines reuses the existing MSP_Invoice_Lines module. Rename their
display labels and API names to Services / Services and Service Lines /
Service_Lines through a coordinated integration cutover, preserving module and
record IDs. Use them for new deals from the first iteration. The API-rename
direction was confirmed on 1 October 2026; old API names describe the installed
baseline until that cutover.
The exploratory Commercial_Services module is a migration source to retire,
not a second permanent parent.
Implemented exploration baseline
The shared MSP_Invoice_Lines module has optional Commercial Service and Plan
lookups. The documented baseline has 166 MSP lines retaining their Plan and
linking to their exploratory Commercial Service.
Native Invoices support a Commercial Service header link; an invoice spanning
several services leaves that header blank and uses item-level ownership. The optional
Expected_Labour_Tier picklist sets project Consulting planning rates through
a code-maintained tier mapping; blank uses Tier 1 ($50/hour). MSP planning
uses $50/hour independently of this field. Consulting lines can select
Labour_Budget_Type and store Expected_Labour_Hours separately from selling
Quantity. Fixed budgets use total hours; recurring allowances use monthly hours.
Blank explicit hours remain pending. Lines without that type retain the legacy
quantity/Arrangement convention. Seat labour retains its recurring allowance
comparison. Additional allowance intervals, Product budget defaults and line
completion are future extensions. Invoice generation through universal Services
and Billing Events is planned in Phase 1; the existing MSP Plan-based generator
remains operational.
The module cleanup records implemented
changes and verified CRM module removal. Sharps and Success Works provide
the MSP proof; Consulting and purchased Products use the same shared lines,
including ARACY's hardware and setup lines within one service.
The service and month perspectives define the reporting structure. The browser pilot implements the service overview, all-service monthly/cumulative Performance and configured Forecast, with service Activity, selected-period Product components and invoice evidence as drill-downs. Separate line allocation and complete scope history remain implementation work. Ongoing invoice reconciliation, historical matching and performance completion belong to the later phase of the implementation plan; they do not gate the initial new-deal quote-to-invoice pilot.
The archived MSP migration record documents the native invoice pilot, and the dated CRM inventory provides its earlier structural reference.
The exploratory reporting refresh uses CRM Review_State = Confirmed as its inclusion
gate. Operators can refresh all confirmed services or one selected service, or
recalculate saved inputs without external reads. Source selection happens before
invoice-detail and project-work collection. See the
refresh process.
A daily schedule and incremental Xero/Projects history synchronization remain
future work; the reporting refresh uses a scoped worker and persistent caches.
Guided quote-to-invoice delivery
The CRM widget guides the flow from the first iteration. Staff prepare Proposal Lines on a new Deal, with Product defaults, agreed prices, billing instructions and independent delivery budgets. Those lines generate the Qwilr quote. Acceptance imports only selected items and accepted quantities/values, retaining the signed revision and source identities.
Staff return to the widget to review the service and its lines, confirm dates and delivery scope, and preview Billing Events before activation. The same interface guides later milestone releases, due charges and invoice-draft review. Saving a draft, customer acceptance, activation and invoice issue remain distinct steps. Backend validation supports each guided action.
Iterate on this complete path for new deals and projects before reconciling historical customer records. Generated items retain source links, accepted-value checks and duplicate protection from the start. Broader payment/credit/status reconciliation and reporting allocation follow in the later phase. This is intended behaviour; the implemented reporting and Plan-based billing boundaries below remain in force until the new workflow is delivered.
Commercial foundation
Service groups lines under a customer commitment. The attached Product is each line's primary driver: it supplies catalogue identity, default selling price, purchase-cost basis and labour treatment. The line supplies the particular quantities, overrides, dates and delivery rules. The same model serves MSP, Tech Projects, Home and Hardware. The exploratory Service Role classifies the group in the browser report and must be mapped onto Services; it does not select Product or line costing or restrict its Products. Project, Onboarding and Recurring agreement roles include owed delivery in Performance contribution, with the same budget, closeout and planned-estimate rules. The generalised Service owns customer and agreement context; each line owns its commercial, billing and delivery behaviour.
The service holds customer, name, Service Role, lifecycle and relevant Deal/agreement context. MSP, Project and Hardware are the primary browser roles; Onboarding, Ad hoc, Home and custom roles can remain separate. Business Category retains its legacy uses; it does not override or fill a missing Service Role. It identifies the commitment independently of invoice numbers, payment status and changing quantities. A renewal can continue the same service identity; the original Deal and current agreement need not be the same.
Each line holds its effective commercial and delivery values. A service can combine laptops, setup labour and recurring support. The same Product can appear on lines in different service categories without changing its cost treatment. Service revenue and costs aggregate the line results, counting each invoice item and time entry once. Pending costs on one line leave the complete service margin unknown while known line margins remain visible. The target design has no service-level recurrence setting that controls every line; the legacy Arrangement field remains a fallback only for unconverted Consulting lines.
Reuse the existing Plan and Line modules
Generalise Managed Services Plans (Managed_Services_Plans) as Services and
MSP Invoice Lines (MSP_Invoice_Lines) as Service Lines. These are the universal
parent and component modules for MSP, Tech Projects, Home, Hardware and mixed
commitments. Apply display and API renames in Phase 1, with affected integrations
updated in this repository and deployed together. Preserve existing module and
record identities and compatible relationships. See the
API cutover map.
| Record | Universal relationship |
|---|---|
| Existing MSP Service | Retain the existing Plan record and ID, its customer, agreements and operational links |
| New project, hardware or mixed Service | Create a real Service in the generalised Plan module; no exploratory Commercial Services record is required |
| Service Line | Reuse the existing line module, renamed to Service_Lines, and its existing parent lookup as the universal Service parent |
| MSP Seat | Account-owned dated support membership linked to a Contact; Services consume the Account roster through their seat-priced lines |
| Project / delivery evidence | Link to the owning Service and relevant line scope |
| Exploratory Commercial Service | Map to a destination Service during consolidation, then retire the exploratory record/module |
The installed optional Commercial_Service and Plan line lookups describe the
exploration baseline. They are not the target two-parent model. Every new Service
Line must have the universal parent, enforced by the new flow; migrate existing
non-MSP lines before tightening metadata requirements across historical records.
Reuse Product, Quantity, Unit Price Override, Description Override and compatible
date fields. Map missing agreement, role, lifecycle, budget and delivery fields
onto the retained modules after checking installed metadata.
MSP Seats use their own Account lookup. The Service remains the commercial parent of each charge; its Account supplies the roster for monthly and annual seat Products. Seat billing dates, annual renewal rules and one-off prorate quantities are independent of the ownership relationship. The legacy Seat Service lookup is retained as hidden migration evidence, not a second parent. See the Account seat migration.
Native Invoice items already have Configured_MSP_Invoice_Line, a lookup to the
retained line module. Preserve this relationship and line IDs. Invoice and item
lookups that point to exploratory Commercial_Services require explicit mapping
to universal Service ownership; a label change does not retarget them. Reuse
compatible existing Plan relationships and inspect supported lookup changes
before specifying additions or migration writes.
The separate exploratory Service_Invoice_Lines capture module was removed in
the documented September cleanup. It is distinct from the retained configured
line module and from Commercial_Services, whose consolidation remains planned.
Consolidate useful evidence, then retire the exploration
Complete the Service relationship mappings before implementing the accepted-service
handoff. The offer widget and Qwilr acceptance verification come first, following
the delivery plan. Historical
reconciliation can follow the new-deal pilot. Preserve useful invoice ownership, configured-line
matches, accepted terms, labour budgets and source identities through an auditable
Commercial_Services-to-Service crosswalk. MSP commitments normally map to their
existing Plan; non-MSP commitments need a reviewed existing or new Service.
Missing or ambiguous evidence remains available for review.
Move affected links and reporting/integration readers to the retained parent, verify ownership and totals, and remove exploratory dependencies before retiring the module. Keep a recoverable snapshot and mapping. Do not duplicate new commitments into both modules or count both parents in reports. Existing reconciliation evidence can be reused without preserving its exploratory schema.
Route billing explicitly before using the generalised modules
The current middleware selects Plan charges using billing dates. Plan_Type
and Plan_Status do not isolate a new project from that generator. Before new
Services can be processed, define and enforce one billing authority per charge
in both the legacy and Billing Event paths. Hold unresolved ownership for review;
do not use a display rename or service category as the routing rule.
Keep existing MSP charges under their selected authority until reviewed cutover. Event-owned lines use their own schedules and Billing Events. Preserve Seat eligibility and existing issued history; generalising the parent must not create legacy recurring invoices for a new project or bill the same charge twice.
Service lines and actual invoice items
A Service Line represents a component of the commitment: usually one consulting line for a Tech Project, with additional lines when a distinct Product, consultant rate or scope requires them. Most Tech Projects are expected to need just that consulting line, sometimes with a discount. The structure supports several lines without requiring every project to be split.
| Responsibility | Proposed representation |
|---|---|
| Group the commitment | Service in the generalised Plan module with customer, Deal and agreement references |
| Define a component's behaviour | Service line with Product, price/quantity basis, cost basis, independent billing instructions and delivery budget |
| Schedule a charge | Proposed Billing Event linked to its source line, occurrence or milestone, amount, coverage and invoice item |
| Supply common defaults | Product with catalogue identity, default price/cost and labour treatment; line-specific values take precedence |
| Supply the planning values | Effective price, expected non-labour cost and expected labour stored on or calculated from the service line |
| Record what was actually billed | Native CRM Invoice item retaining the Xero line identity and financial values, linked to the service and relevant service line |
| Explain actual effort | Recorded work attributed to the line through its delivery scope and work dates |
Every line requires an attached Product. The Product is a behavioural foundation,
not merely a description used for display. Explicit line overrides take
precedence over supported defaults; service category cannot override Product
treatment. Current purchased costs read that Product's Cost_Price at refresh,
while saved selling-price overrides remain independent. Its core information is:
| Information | Meaning |
|---|---|
| Product and description | Catalogue identity and the particular work or item sold; internal Consulting uses Product 003; hourly external supply uses CONSULTING-EXTERNAL |
| Price and quantity basis | Fee or unit price excluding GST, with a quantity where needed, such as seats or licences; separate from labour quantity |
| Cost basis | Expected non-labour cost from the Product or a line-specific value, plus labour costing when applicable |
| Labour associated | Whether the line carries expected and actual work |
| Labour amount and unit | Expected work in hours or days, with any per-seat or other quantity basis explicit |
| Labour budget type | Product default, overridable on the line: recurring allowance, fixed budget or no labour; independent of billing recurrence |
| Billing instructions | One-off, recurring or finite instalment charges, with dates or milestone conditions and applicability |
| Delivery coverage | Fixed total budget or recurring allowance, with its own period, dates, rollover and completion rules |
Price, cost and labour are independent of recurrence. For example:
| Service category | Line | Recurrence | Cost driver |
|---|---|---|---|
| MSP | Support | Monthly | Expected support allowance and actual time spent |
| MSP | Onboarding | One-time | Expected project labour and actual time spent |
| Tech Projects | Consulting | One-time or recurring | Expected consulting labour and actual time spent |
| Any applicable category | Licence or equipment | Recurring or one-time | Product cost, with labour only if explicitly included |
These are examples, not category restrictions. A recurring line needs enough period information to compare its allowance with the right work and invoices; it does not require a billing schedule or a monthly wrapper record for reporting.
For historical migration candidates with reviewed Qwilr terms already recorded in a prepared Delivery Model, that preparation can supply labour amount and unit. An issued invoice can supply a billed baseline; it does not establish the full accepted contract value. For new deals, Phase 1 imports accepted terms through the Qwilr integration and guides their review in the CRM widget. The implemented service line contains no Delivery Model or Qwilr lookup, source ID or URL, and reporting does not read either to calculate the line. The planned integration must retain a proposal/revision-to-line crosswalk for acceptance and retry handling without making reporting depend on live Qwilr reads. Migration working papers can retain the source crosswalk outside the operational line. No further agreement research is needed when the prepared values are sufficient.
Implemented Product and labour rules
Internal Consulting (003) and External Consulting (CONSULTING-EXTERNAL)
supply distinct cost identities while sharing the Xero sales item 003. External
Consulting uses the line-owned External Hourly Cost for all recorded and remaining
hours; overruns increase the supplier fee. The forecast always includes external
fees and makes salaried allocation optional. Fixed payroll remains a business cost.
The single-line activity model requires explicit allocation before a service can
combine internal and external labour lines. The particular fee, labour amount, unit and recurrence
belong to the service line, so projects can use the same Product with different
values. MSP expected labour costs $50/hour for all Seat lines, regardless of
labour tier. Internal Consulting uses the line's Expected_Labour_Tier:
Tier 1 = $50/hour, Tier 2 = $80/hour, Tier 3 = $95/hour and Tier 4 = $110/hour.
CRM stores only the tier; code maintains the costs in AUD. Blank uses Tier 1,
and an unrecognised Consulting tier blocks cost validation.
A Consulting line with Labour_Budget_Type = Fixed budget uses
Expected_Labour_Hours as its total planned work. Recurring allowance uses
that field as hours per calendar month, independently of the service's
Arrangement. Selling Quantity and Unit Price Override then describe the sale:
one setup fee at AUD 599 is Quantity 1 and Unit Price Override 599, with planned
hours left blank until known. Blank hours do not mean one hour or zero labour.
Its expected and projected margins remain unknown; purchased components on the
same service retain their own costs and margins. Recorded incurred labour can
still be shown when available. With neither a budget nor recorded work, setup
cost and the complete service margin stay unavailable.
For a legacy hourly Consulting line without an explicit Labour Budget Type,
the shared line's Quantity supplies a one-off hours budget, or hours per
calendar month when Arrangement = Recurring. For a one-off scope, 10 days at
7.6 hours is entered as 76, with 144 as the hourly selling price. A 23-hour monthly
retainer uses Quantity 23. Its allowance is prorated by calendar days within
report and line dates, capped by an ended service's End Date, and does not roll
over. Active is a billing flag and does not erase Consulting allowances.
Missing monthly hours leave expectations unknown without blocking actual costing.
Native invoice items keep their own issued quantities and prices. Day units,
other allowance intervals and Product-level budget defaults remain extensions.
Actual cost follows recorded work and staff rates. Missing Consulting staff
rates use the line's tier rate, with blank selecting Tier 1; MSP retains its
$80/hour fallback. The tier does not change known staff costs or selling prices.
The fixed-budget Consulting pilot holds the full expected labour cost in
projected margin until its hours budget is exceeded or the service is closed.
Commercial Service Lifecycle = Ended with End_Date on or before the reporting
cutoff is the pilot closeout signal. At closeout, incurred cost replaces the
budget and unused hours are released. Seat and recurring Consulting margin always use incurred period
cost. Component details retain recorded hours, incurred costs and budget
balances. Worker-rate differences affect the Consulting headline only at
closeout or an hours overrun. These figures retain the report's July-onward
revenue/work scope; they are not lifetime project results.
Do not create a Product per project or consultant rate, or write project values
back to the shared Product. Product defaults may help initial entry; later
catalogue changes do not overwrite saved line values.
Labour amount is independent of billed invoice quantity. Do not multiply the total fee by expected labour or infer labour from price. Both margin comparisons use billed revenue: expected labour cost uses the line's labour amount and unit, while actual labour cost uses recorded work and applicable staff costs. A Day quantity needs the report's explicit hours-per-day conversion. Add non-labour cost where applicable, without counting labour again through a Product cost that already includes it. Estimated cost remains labelled as an estimate when there is no actual purchase-cost evidence. Retain the basis used for historical comparisons when line expectations change.
A service line and an issued invoice item have different lifetimes. One service line can explain several monthly or staged invoice items. Issued quantities, rates, discounts and amounts remain on each actual item; an invoice is not proof of the complete contract value, billing schedule or original effort budget. Match each actual item to one service line in the pilot. Any item spanning several components needs an explicit allocation, with the original amount counted once. Product identity alone is not a line identifier: two consulting lines may use the same Product with different rates or scopes.
Actual invoice items link to the stable identity of a record in
the retained line module (currently MSP_Invoice_Lines, target Service_Lines).
Ownership of recorded work is explicit and does not require
a Delivery Model or Qwilr reference. The information above defines the behaviour
of that existing module; it is not a new module, subform or invoice-generation UI
specification.
Discount percentages stay on their source invoice items. A separate negative
discount item remains a separate signed financial item and reduces revenue
once. Associate it with the consulting line when that relationship is clear;
otherwise use an adjustment service line until component allocation is known.
A discount does not generate negative labour or an additional labour budget.
The pilot recognises MSP-DISCOUNT and MSP-NFP-DISCOUNT as price-only Product
codes: both have zero cost even when the catalogue cost price is missing.
With one consulting line, the relevant project work can belong to that line. With multiple consulting lines, use explicit consultant or work-scope ownership. A higher selling rate does not establish a higher staff cost. Shared work and expected labour contribute once; unresolved line allocation stays visible instead of repeating the full project cost on every line.
Invoice evidence and reporting
Configured charges and dated seat eligibility explain what billing should generate. Track existing invoices and their actual lines, and reconcile each line back to its configured charge where the evidence supports a match. For MSP, that charge is an existing MSP Invoice Line on the operational Plan. Each actual line links to its parent Invoice, CRM Product, service and coverage dates and retains its billed quantities, prices, discounts and financial values. Later Product or charge changes do not rewrite issued lines. Capturing invoice history does not require generating new invoices.
Reuse CRM Invoice records for document history and reporting by invoice date, customer, currency and source status. Use their line amounts for service and Product breakdowns, and reconcile those amounts to each invoice's totals. The invoice-to-line relationship and configured-charge mapping make successive months traceable through records.
The exploratory implementation uses a Commercial Service lookup on the Invoice header for single-service documents, with item-level attribution for mixed ones. The target uses the same ownership rule against the universal Service parent. Map the exploratory references during consolidation while preserving existing Invoices, Plan/Deal links, Xero IDs and stable configured-line attribution. An invoice spanning several Services keeps its universal Service header blank and uses item ownership; do not assign the whole invoice arbitrarily to one Service.
Invoice and credit items provide the revenue evidence for the service-month model, alongside recorded work and other costs. Multiple documents can contribute to a month, and an invoice can contain several service periods. Source invoice date and service coverage remain distinguishable; coverage alone does not define an allocation rule.
The accepted agreement, configured billing instructions and issued invoices can disagree. Their relationships make a difference explainable; copying one over the other does not resolve it. Draft refresh follows operational billing rules, and actual financial evidence remains traceable to the source document.
Delivery budgets and recorded work meet invoice lines through service ownership, scope and dates. Shared support effort is counted once. Customer entitlement, billed quantity and internal effort remain separate. Missing Product matches, costs or historical evidence stay visible as gaps.
Service and month perspectives
Service × month is the common reporting unit. Opening a service reads its activity across months; opening a month reads the activity of every included service in that month. Both perspectives use the same amounts, source selection and calculation rules. The month total is the sum of its service rows.
The model separates monthly activity from the position of a fixed scope at a cutoff date. Monthly revenue and costs can be added across services or months. A scope's full budget, remaining effort and projected margin describe its position at that date and are not amounts to add across months.
Commitments, activity and reporting totals
| Information | Responsibility |
|---|---|
| Service | Identify the customer commitment independently of its invoices and reporting months |
| Service line | Define the component, applicable dates, price and cost rules, billing recurrence and labour budget type |
| Dated source activity | Retain invoice items, credits, recorded work and cost evidence with their original source identity, dates and amounts |
| Attribution | Identify the owning service and, where supported, its service line; preserve explicit splits and unresolved ownership |
| Service-line month | Derive revenue, recorded hours, labour cost, other cost and applicable recurring allowance for one line, calendar month and currency |
| Service month | Aggregate the line activity and any service-owned activity awaiting line allocation, counting every amount once |
| Scope position | Evaluate the fixed scope's budget, incurred cost, remaining or overrun hours, completion and projected/final margin at the cutoff |
Service-line months and service months are calculated reporting results. They do not require a Service Month CRM module, monthly wrapper records or a second set of manually maintained charge snapshots. Totals retain a path to the source items and recorded work that explain them.
Attribution to a service can be established before attribution to one of its lines. Such activity remains in that service's total, visibly awaiting line allocation; it must not be copied onto each component. Activity without a known service remains in a separate unassigned view and outside the service subtotal. Business-level activity also remains separate. Neither requires an invented Service or an arbitrary allocation to customers.
Billing recurrence and labour budget type are independent line rules. A fixed project paid in monthly instalments retains one effort budget. A recurring allowance belongs to its applicable period. A service containing onboarding and monthly support therefore has both behaviours, determined by its lines rather than its category.
Period and calculation rules
The initial monthly view retains the browser report's date basis: issued revenue net of credits follows document date, recorded labour follows work date, and billed Product-cost estimates follow their associated billed items. Both perspectives use the same cost rules and preserve estimate and fallback labels. This monthly structure does not introduce a new cost-recognition policy or automatically spread an annual or staged invoice over its delivery period. Keep evidenced service coverage available independently of the reporting month.
Recurring allowances use their applicable dates and period, including the defined proration for partial periods. Historical expectations need the values effective for that period; a current-configuration comparison must be labelled as such when historical values are unavailable. Preserve dated budget, rate and completion changes so a historical position can be explained.
For monthly activity, contribution is revenue less recorded labour cost and other costs under the report's costing rules. Use this measure in both service and month totals. Expected recurring cost can be compared alongside it. A held fixed budget affects the scope's projected margin, not the monthly activity cost or the combined monthly contribution.
Cumulative amounts sum monthly activity from an explicit start date through the cutoff. Cumulative margin percentage is total contribution divided by total revenue; percentages are not added or averaged. A zero revenue denominator has no margin percentage. Label cumulative figures with their actual period, such as “since 1 July 2026”; “since inception” requires complete scope history.
A confirmed zero, missing data and a partial month have distinct meanings. Retain months with costs but no revenue and eligible months with no activity. Carry unresolved attribution and cost coverage into the service and month totals; activity elsewhere must not hide an incomplete component. Known amounts may be shown with an incomplete label, while a full margin percentage remains unavailable when the required amounts are missing.
Report navigation and rendering
The browser has three permanent tabs: Commercial services, Performance and Forecast. Commercial services combines the selected-period overview with one searchable, sortable list and a Needs attention filter. Performance presents monthly/cumulative activity and reserve movements. Forecast separates recurring FY expectations from one-off whole-contract expectations. Service Role and customer filters carry across these views; forecast horizons and recorded dates have distinct meanings.
A service opens as a drill-down with Summary, Activity and Lines & evidence. The originating report, filters, dates and list position survive the round trip. Selecting a Performance month opens its service list. Service Activity can open all services for the same selected activity period. Local detail dates can vary without replacing the parent selection. A category change returns to the parent report rather than silently replacing the selected service.
Fixed-scope budgets, consumed/remaining effort and projected/final positions stay at the snapshot cutoff in Lines & evidence. Monthly/cumulative activity remains available for fixed and recurring services, including mixed services. Remaining budget is not an invented monthly delivery plan. Recurring comparison uses complete months and marks partial periods. The same service-month amount appears in the service overview, the Performance totals and service Activity.
See report pages and filters for the implemented navigation and the separation of role classification, Product costing and forecast salary allocation.
Consistency checks
- The same service-month amount appears in both perspectives.
- Summing a month's service rows reproduces that month's service total.
- Summing a service's monthly activity reproduces its selected-period total; summing either axis over the same services and months gives the same result.
- Source allocations preserve the original signed amount and count work once; any rounding is resolved consistently before either view aggregates it.
- Budget positions, cumulative balances and projected margins are never summed across months. A monthly filter does not reset a fixed scope's consumed effort.
- Scope positions disclose incomplete history, and incomplete monthly inputs remain visible in totals. Selecting another view cannot turn unknowns into zero.
Historical invoice mapping example
Gidget Foundation's
INV-22222928
was read from Xero on 9 September 2026. It is a paid AUD invoice dated
29 June 2026, with one item, Product code 003, described as Referral
Prioritisation Dashboard, quantity one, and no discount. That quantity is a
billed item, not one consulting hour or day. Its description alone does not
verify an association with the Gidget Phase 5 Deal.
This illustrates the distinction between billed evidence and the full commitment: a staged invoice supplies only its billed portion. A reviewed migration needs the accepted scope, labour budget and service ownership as separate evidence, and must preserve the original invoice date. The candidate mapping and any missing native CRM mirror remain subject to the implementation plan's historical follow-up register. This example is not a separate build sequence or an approved customer migration.
Delivery model and operational boundaries
Product defaults and line completion
The exploratory reporting pilot selects its calculation from the attached Products, whether
or not a Plan is linked. Seat Products supply recurring allowances; one
Consulting Product 003 line can carry a fixed budget or monthly allowance
alongside purchased items. Explicit line budget fields separate hours from
selling quantity and take precedence over the legacy Arrangement convention.
The service lifecycle/end date still closes the single fixed labour line or
ends its allowance. Multiple labour lines, including Seat plus Consulting,
require explicit work allocation and remain unmodelled until that is available.
Supply Labour Budget Type as a Product default with a saved service-line override: Recurring allowance, Fixed budget, or No labour. The implemented optional line picklist covers the two labour types; purchased-only Products do not require it. Keep it separate from billing recurrence: a fixed project budget can be invoiced in monthly instalments without resetting its hours. Separate effort amount/unit from billed quantity and define allowance periods explicitly.
Track completion and its effective date on each fixed-budget line, with service completion closing its remaining work under a defined rule. Define cancellation and reopening semantics explicitly. An MSP Seat, a consulting project and hardware should coexist on one service, with recorded work allocated once to the appropriate line. Replace the remaining Product-code conventions with explicit Product defaults before extending to several labour components or other Consulting allowance intervals. Preserve budget revisions and completion history, and add complete project-to-date work coverage before asserting lifetime results.
Service and billing responsibilities
The universal Service-and-lines model supports billing and performance tracking. The retained Plan and Line modules are generalised in Phase 1 alongside Qwilr, the CRM widget and Billing Events. Both display and API names change through a coordinated repository/integration cutover; module and record IDs remain intact. The exploratory Commercial Services module is consolidated and retired later within this plan; it is not a permanent reporting layer.
Implement explicit billing authority before new-deal records can be processed. Reviewed instructions, timing, account/tax mappings, draft-refresh rules and retry protection remain necessary. Existing MSP Seat, agreement and delivery relationships survive the transition. Transfer useful exploratory evidence and redirect readers before retirement; retain one owner for each charge and one Service identity for each commitment.
Tech Project service lines own their price and labour expectation from the reporting proof onward. Qwilr supplies accepted terms for new deals in Phase 1; reviewed Delivery Models and historical Qwilr evidence can supply migration inputs later; retiring other operational uses of Delivery Models is separate work. The presentation pilot scenarios define the mixed hardware/setup/support and instalment-project checks. Their illustrative values do not overwrite historical customer records. Existing line values, native invoice evidence and accepted scope must be read and reviewed before a customer migration; missing labour budgets remain unresolved.
This document does not establish a billing cutover or change an operational workflow. Current MSP invoicing, Deal processing and invoice reconciliation remain the references for implemented behaviour.