Skip to content

Manage a Deal

One Deal should match one signed Qwilr page or Purchase Order. If a client approves separate scopes, create separate Deals so project setup, delivery tracking, and invoicing stay clear.

Tip

Use the required Deal Category field to choose the sale's offer design and setup. It has six choices and no default. Historical Deals can retain their old category until their scope is reviewed individually. See the rollout status.

Choose the Deal Category

Select one value; there is no default. Use the short picklist labels below.

Deal Category Use for Offer design / starting products
MSP - New Client A new managed service agreement, even for an existing customer MSP design; support plans, Discovery, Onboarding and optional Extra Devices
MSP - Additional Product / Service Licences or services added to an existing managed service Plain design; empty product list
Tech Project A defined one-off scope: migration, SharePoint setup, CRM implementation Tech Project design; empty product list
Tech Retainer Ongoing development or website/project maintenance Retainer design; empty product list
Hardware An equipment sale, including to an MSP customer Plain design initially; empty product list
Home Residential support or home services Plain design; empty product list

Classify the sale, not the customer. A laptop sale to an MSP customer is Hardware; a separately scoped migration is Tech Project. Monthly instalments for a fixed project do not make it a Tech Retainer. Pure equipment sales use Hardware; residential service engagements use Home. Use separate Deals for independently approved scopes. One offer can include both one-off and recurring lines.

Older MSP and Tech Projects values remain readable during migration. Review older MSP records individually before choosing new-client or additional-service; do not assume every historical MSP Deal was a new client.

Open a New Deal

  1. Create the Deal when a real opportunity has been identified.

    • If the opportunity starts as a Lead, convert the Lead first.
    • Immediately update the new Deal after conversion.

  2. Complete the core Deal fields.

    • Deal Owner: the person responsible for securing and scoping the work.
    • Deal Name: client plus job name, for example WLCW Ongoing Support.
    • Deal Category: select the sale type from the table above.
    • Closing Date: the expected client approval date.
    • Stage: start with Limbo/Follow Up - 20% unless the context already justifies a later stage.
    • Contact: the client-side person responsible for the project.
    • Company: the client account. This is required except for Home Deals.
    • Amount: for one-off work, use the total Deal value. For recurring work, use the first monthly or first-invoice amount.
    • New or Existing: identify whether this is new or existing work.
    • Lead Source: record where the opportunity came from.

  3. Check the automatic project setup.

    • MSP - New Client, Tech Project and Tech Retainer Deals should get a linked Zoho Project.
    • The project should have a Scoping tasklist, a Scoping task, and a Scoping Delivery Model.
    • MSP additions, Hardware and Home Deals are skipped by project setup.
    • A missing or unsupported category is also skipped; correct it and ask the administrator to rerun setup if a project is needed.

  4. Create the Qwilr page from the Deal.

    • Use Prepare offer and follow Prepare a Deal Offer.
    • Review the category-selected design, products and billing.
    • Edit the Qwilr page and share it with the client when it is ready.

  5. Keep the Deal amount aligned with Qwilr.

    • If the Qwilr amount changes, update the Deal amount.
    • For recurring Deals, the Deal amount should match the first invoice, not the full contract lifetime value.

When The Deal Is Reserved

Move a signed MSP - New Client or Tech Project Deal to Reserved.

  1. Confirm the signed QWILR.

    • The client-approved scope should be final enough to start delivery setup.
    • The Deal amount should match the signed Qwilr or the first invoice amount.

  2. Confirm the linked project is ready.

    • The Deal must already have a linked Zoho Project.
    • The linked project must have a Scoping tasklist.
    • If either is missing, fix the project setup before changing the stage.

  3. Change the Deal stage.

    • Set Stage to Reserved.
    • For MSP - New Client and Tech Project Deals, the automation closes the Scoping tasklist, attempts to end the Scoping Delivery Model, sets the Deal Closing Date to today, and ensures the next Delivery Models exist.
    • Other Deal categories are skipped by this automation.

  4. Review the generated Delivery Models.

    • Generated models are starting points.
    • Update amounts, labour units, and labour amounts to match the signed Qwilr before relying on them for delivery tracking or reporting.
    • Set Budget Status to Confirmed when the values have been checked against their source. Use Retired when a budget should stop contributing to expected labour.
    • Record Budget Source, such as Signed Qwilr or Manual, so the basis of the estimate remains visible. Blank legacy statuses and Draft budgets remain reportable during data cleanup.
    • Expected Invoice Date is optional and does not place revenue or labour in the current report; the linked Deal's Closing Date is the provisional placement date.

  5. Handle invoicing separately.

    • Do not use the recurring MSP invoice process for one-off onboarding, project, or Deal charges.
    • Use the Deal-led finance process for the first invoice or one-off invoice.
    • When the invoice already exists in Xero, preview and then apply the project-invoice mirror so the CRM Invoice's Commercial Deal points back to this Deal.
    • Do not link that project invoice to an MSP Plan. The Deal gathers revenue; its Delivery Models gather the related expected and actual labour.

Review Tech Project Delivery Models

  1. For a one-time Tech Project, review WIP Update from Signed QWILR.

    • The automation creates one project-scoped Delivery Model.
    • Amount starts from the Deal amount.
    • Labour Unit starts as Day.
    • Labour Amount is calculated from the Deal amount using the implemented daily rate.
    • Change only the amount, labour unit, or labour amount needed to match the signed Qwilr.

  2. For a Tech Retainer, arrange recurring delivery setup manually.

    • Its initial project has Scoping, but the Reserved automation does not create a one-time project model for it.
    • Review and close Scoping as appropriate, then create the agreed recurring model with monthly revenue, labour and validity dates.
    • Confirm billing separately; selecting Retainer does not activate invoicing.

  3. For a Tech Project with both one-time and recurring elements, use manual review.

    • The standard automation does not fully model mixed structures.
    • Confirm the correct model split before delivery tracking starts.

Renew a Recurring Delivery Model

When recurring work continues on the same Zoho Project but the commercial terms or expected labour change:

  1. Keep the existing Delivery Model for the period it governed.
  2. Set its Valid_Until to the final day of the old terms.
  3. Create a recurring Delivery Model with the same project and intended scope.
  4. Set the replacement model's Valid_From to the following day and enter the new amount and labour expectation.
  5. Check that the validity periods do not overlap or leave an unintended gap.

Timesheet reporting assigns work to the existing recurring model until the replacement starts. Work logged in a gap after the old budget ends has zero additional budget. From the replacement's start date, its model owns the work. This keeps the historical comparison without moving work to a new Zoho Project.

Review Work After a Recurring Budget Ends

  1. Keep the agreed end date when billing and its monthly labour budget finish.
  2. Continue logging delivery work against the existing project and scope.
  3. After the timesheet report refreshes, check each later month containing work.
    • Actual hours should include the logged time.
    • Expected hours should be zero for that month.
    • Monthly completion should be blank because there is no monthly budget.
  4. Check the overall comparison across the full agreement period and later work.
    • Actual hours include the later work.
    • The overall expected hours stay at the agreed budget.
  5. Ask the report owner to investigate if time is missing, the budget grows after the end date, or work is assigned to the wrong replacement model.

For example, a February–September agreement with 22.8 hours per month has a total budget of 182.4 hours. Three hours worked in October appear against zero October budget and add three hours to the overall actuals. The total budget stays at 182.4 hours. This timesheet comparison does not extend billing or change CRM delivery-alert eligibility. See the reporting rules.

Review MSP Delivery Models

When an MSP - New Client Deal moves to Reserved, the automation creates two tasklists and two Delivery Models.

  1. Review Audit/Onboarding.

    • This model is scoped to the Audit/Onboarding tasklist.
    • Set the one-time onboarding amount from the signed Qwilr.
    • Set the labour unit and labour amount from the signed Qwilr.

  2. Review Tech Support.

    • This model is scoped to the whole project.
    • Set the recurring amount from the first signed Qwilr payment.
    • Use Hour as the labour unit unless the contract says otherwise.
    • Estimate monthly labour from the support level and seat count:
      • Level 1: 15 minutes (0.25 hours) per seat per month.
      • Level 2: 30 minutes (0.5 hours) per seat per month.
      • Level 3: unlimited support, with an indicative expectation of 1.5 hours per seat per month for planning and reporting, not a support limit.
    • Adjust the estimate when the contract has a different support expectation.
    • Keep logging all work, including time above the indicative expectation.

Time logged outside the Audit/Onboarding tasklist is treated as Tech Support work for delivery-model tracking.

Deliberate Limits

This operating process uses the existing Deal, MSP Plan and Delivery Model structure. The commercial services design direction records the separate, evolving foundation for service ownership of invoice lines and monthly expectations. It does not change the steps or invoice links described here; implementation must update this process when those rules change.

Manual Review Checklist

  • The Deal amount does not match the signed Qwilr.
  • The Deal has no linked Zoho Project.
  • The linked project has no Scoping tasklist.
  • Someone expects automatic Reserved setup for a Tech Retainer, MSP addition, Hardware or Home Deal. These need their appropriate manual handoff.
  • An MSP addition has no identified existing managed service.
  • The Deal includes both one-time and recurring Tech Project work.
  • Sequential recurring Delivery Models have overlapping dates or an unintended gap between Valid_Until and the next Valid_From.
  • MSP Delivery Models still have zero amount or zero labour after setup.
  • The first invoice or one-off invoice has not been handled through the Deal-led finance process.
  • A project CRM Invoice has both Commercial Deal and MSP Plan, or its Xero contact does not match the Deal Company.