Skip to content

Deal Process

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

This process is mainly for MSP and Tech Project Deals. Hardware and Home deal still require a deal and a QWILR, but the project and delivery-model automations do not run for Home and Hardware Deals.

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.
    • Business Category: MSP, Tech Projects, Home, or Hardware.
    • 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 and Tech Project Deals should get a linked Zoho Project.
    • The project should have a Scoping tasklist, a Scoping task, and a Scoping Delivery Model.
    • Hardware and Home Deals are skipped by the project setup automation.

  4. Create the Qwilr page from the Deal.

    • Use the Create Qwilr Page action on the Deal record.
    • Select the right template and folder.
    • 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 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 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.

  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.

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 recurring Tech Project, convert the model to recurring tracking.

    • Set Revenue Model to Recurring.
    • Use the expected monthly amount.
    • Set the monthly labour unit and labour amount from the Qwilr.

  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.

Reporting assigns each timelog to the Delivery Model that was valid on the log date. This keeps the historical monthly comparison under the expired model and continues it under the replacement model without moving the work to a new Zoho Project.

Review MSP Delivery Models

When an MSP 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: 0.25 hours per user.
      • Level 2: 0.5 hours per user.
      • Level 3: 1.5 hours per user.
    • Adjust the estimate when the contract has a different support expectation.

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

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.
  • The Deal is not MSP or Tech Projects, but someone expects project or delivery-model automation.
  • 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.