1
The payment
Money has been received. Someone needs to pick up the job and keep it moving.
No changes have been applied to Zoho CRM. This was purely a diagnostic exercise.
Sales → Operations · Zoho CRM
When the deposit
arrives first.
Why an early deposit can leave a job stuck in Sales, and my proposed way to move it into Operations while the proposal awaits a signature.
Lewis and Andrew, following my conversation with Andrew about deposits arriving before a signed proposal, I used the AI diagnostic tool I built to investigate the process in Zoho. I traced the current rules and existing record history to understand where the handover gets stuck.
If you hit another problem, send me a detailed description and the background around it. I can use the tool to investigate, which could save you hours, or potentially days, of digging.
I’ve set out what I found, the changes I recommend and where to apply them. Andrew, I’ve included the rule links and technical detail for your review. Lewis, I’ve highlighted the decisions we need to make about when Operations can start and when we count a sale as won.
Jules
01
WHY
A customer can pay a deposit before Shaun has finished the proposal. That is a real step forward, but it is a different fact from having a signed proposal.
2
The signature
The customer has accepted the actual proposal. This is the proposed point at which the sale is counted as won.
3
The handover
Operations needs a clear place to see a paid job that is still waiting for its signed proposal.
What we want: an early deposit should put the job in front of Operations while the sale waits for its signed proposal.
The inspected rules do not provide that route today. I recommend an Open stage in Operations for this purpose, subject to our agreement on when a sale counts as won.
A second problem matters just as much: “Job in Progress” already means “Closed Won” in Zoho.
Simply pushing an unsigned job there would make it a won opportunity. The proposed fix needs an open place in Operations for jobs awaiting a signature.
Verified configuration The deposit rule accepts only Prospect or Closed Won. At Sales / Prospect, it asks for Job in Progress, a stage on the Operations board, while leaving Pipeline unchanged. The existing record history supports this mismatch. Decision needed Operations preparation and the won-sale date are separate decisions. The proposed changes and decisions are set out below.
02
WHAT
Here is what I found in the CRM.
An opportunity is the customer’s job record. A pipeline is the board it sits on. A stage is its step on that board. A workflow is an automatic “when this happens, do that” rule.
The usual path: a sale is marked Closed Won
Verified CRM path
Sales pipelineConsultant works through the sale.
Consultant records Closed WonThe CRM history identifies this as a manual change.
Operations pipelineThe rule changes Pipeline to Operations.
The rule is “Closed Won - Change Pipeline”. It uses a standard Zoho field update to set Pipeline to Operations.
Verified handover: In the sale I traced, Zoho’s Manual history filter shows Cole setting Stage from Appointment Booked to Closed Won at 3:46 pm on 21 September. The “Closed Won - Change Pipeline” workflow then moves the opportunity from Sales to Operations. This is the CRM sequence the deposit route needs to work alongside.
The early-deposit path: two reasons it can stop
Most sales stages are excluded
The deposit rule accepts only Prospect or Closed Won. Deposits entered at Appointment Booked, Rebooking Required, To Be Quoted, Quote Sent/Followup, Hot, Warm or Cold fall outside that condition.
The destination is on another board
Even at Sales / Prospect, the action only sets Stage = Job in Progress. That stage belongs to Operations. The opportunity remains in Sales because the action leaves Pipeline unchanged.
Current deposit route · two different stops
Appointment Booked through Cold
Deposit date entered
↓
Stage fails the rule’s condition
↓
The job stays in Sales.
Sales / Prospect
Deposit date entered
↓
The condition passes, but Job in Progress is on the Operations board
↓
The action leaves Pipeline unchanged.
The excluded stages are Appointment Booked, Rebooking Required, To Be Quoted, Quote Sent/Followup, Hot, Warm and Cold.
The field-update screen explicitly says the stage can only be updated where the record’s Pipeline/Layout contains that stage. The listed triggers watch payment and funding fields. This creates a second risk to test: after an early deposit, a later Closed Won change may leave the job at Operations / Closed Won because the deposit rule may not run again.
Later signature · risk to test
Deposit already recordedThe payment field has already changed.
Closed Won recorded laterThe handover rule moves the job to Operations.
Does the funding rule run again?Stage is outside its listed triggers. The job may wait here.
This is a risk identified from the rule settings. It needs checking against customer history and controlled tests.
Same deposit rule · different pipeline
Sales / Prospect
Deposit date entered
↓
Rule asks for Job in Progress
↓
Stops: the destination belongs to the Operations board.
Operations / Prospect
Deposit date entered
↓
Rule asks for Job in Progress
↓
Works: that stage is on this board.
The existing history below shows how the deposit rule’s outcome changes with the pipeline.
The existing history backs this up
Record history Open the apparent test opportunity · 23 September 2026. The repeated edits appear to be testing. I have treated this as an apparent test record, pending Andrew’s confirmation.
- 11:17 · Deposit entered in Sales
The record remained at Sales / Prospect. - 11:21 · Stage changed to Closed Won
The existing handover rule moved the record from Sales to Operations. - 11:22–11:23 · Prospect, now in Operations
The stage was changed back to Prospect. Entering the deposit then triggered the rule and moved it to Job in Progress. - 11:24 · Reset to Sales / Prospect
The deposit was cleared, the record was moved back, then the deposit was entered again. The inspected current record remained in Sales / Prospect with a deposit date.
Why this is useful: the deposit rule worked when its destination stage was available in Operations. In Sales, the record stayed at Prospect. I traced this sequence from the existing history.
A separate normal-sale record shows Cole manually changing Stage to Closed Won on 21 September, followed by the automatic move to Operations. I confirmed the manual entry using the Timeline’s Sources filter. The history also shows a closing-date update, technical-review status, operations-board status, a welcome email, an internal celebration email and a celebration SMS function call. SMS delivery would need checking in the sending service.
Reporting: moving the job can change the sales result
Why a simple shortcut would change reporting
Unsigned customerDeposit is recorded.
Shortcut: Job in ProgressZoho category is Closed Won.
Looks like a won saleThe inspected sales report includes this stage.
The proposed holding stage needs an Open category so preparation and confirmed sales stay distinct.
| Stage / report | Live setting | Why it matters |
|---|---|---|
| Prospect | Open category; Pipeline forecast; 10% probability. | An Open stage in Operations can hold work that is still awaiting acceptance. |
| Closed Won and Job in Progress | Both are Closed Won category / Closed forecast / 100% probability. | An unsigned opportunity moved directly to Job in Progress is classified as won. |
| Later Operations stages | Install Unscheduled through Completed are also Closed Won / Closed / 100%. Archived is Closed Won / Closed, with 70% probability. | An unsigned sale needs an Open holding stage. Archived’s 70% is a separate setting to review. |
| Sales This Month | Saved Closing Date filter: Current and Previous FY. Explicit stage list includes Job in Progress; it omits Install Completed. | The saved date range covers the current and previous financial years. This report can count an unsigned job moved to Job in Progress, and can drop a signed job at Install Completed. Confirm which report the team actually uses. |
The inspected report’s complete stage list is Closed Won, Job in Progress, Install Booked, Completed, Install Unscheduled, Archived and Install in Progress. Its columns are Opportunity Name, Account Name, Closing Date, Opportunity Owner, Created Time and Lead Source; the report lists individual jobs and their dates rather than adding up sales revenue.
How far can Operations progress today?
Existing Operations sequence
Closed WonJob in ProgressInstall UnscheduledInstall BookedInstall in ProgressInstall CompletedCompletedArchived
The next rule after Job in Progress checks technical review and grid approval. A signature check is missing from its conditions. The archive rule also has an unrestricted starting stage. I recommend adding an acceptance check to the release into installation and a Completed-stage check to the archive rule.
Evidence register: the rules and settings I inspected
Open the panels for the precise names, triggers and destinations. CRM links require the organisation’s normal access. All listed workflow rules are active unless marked inactive.
1. Pipeline stages and stage categories
Setup → Pipelines · layout Sales. Sales layout → Stage-Probability Mapping contains the category settings.
Sales
ProspectAppointment BookedRebooking RequiredTo Be QuotedQuote Sent/FollowupHotWarmColdClosed WonClosed Lost
Operations
ProspectClosed WonJob in ProgressInstall UnscheduledInstall BookedInstall in ProgressInstall CompletedCompletedArchivedClosed Lost
The other visible sales stages are Open / Pipeline: Appointment Booked, Rebooking Required and To Be Quoted at 20%, 10% and 20%; Quote Sent/Followup 50%; Hot 80%; Warm 70%; Cold 30%. Closed Lost is Closed Lost / Omitted / 0%. The master stage list also contains Proposal Submitted (Open / Pipeline / 10%), which is outside both displayed pipelines.
2. Handover, deposit and related workflow rules
Closed Won - Change Pipeline
When: Stage modified to Closed Won; repeats; all opportunities.
Action: Native field update: Pipeline = Operations. Choose Stage was blank.
Meaning: This is the working bridge. It relies on the Closed Won stage as its signal.Rule ID 2342503000092065044
Stage Transition: 1.Closed Won to Job in Progress
When: ANY: Deposit Paid Date becomes nonempty; Finance Status becomes Conditionally Approved or Approved; Deposit not required becomes selected. Repeats. Condition: Stage Prospect OR Closed Won.
Action: Move Stage to Job in Progress. Sets Stage only.
Meaning: Most pre-win stages are excluded. Sales lacks the destination. Last modified shown as 23 September 2026.Rule ID 2342503000109264338
Unsigned Proposal
When: JOB STATUS modified to any value; contains Awaiting Signed Proposal.
Action: Unsigned Proposal email and Sales P to chase up signed proposal task.
Meaning: Description mentions an unsigned paid job; the rule runs when JOB STATUS changes.Rule ID 2342503000010943140
Deposit Paid - No progress - Email SalesP
When: Once, 5 days after Deposit Paid Date at 08:00. Deposit populated AND Grid App Submitted empty.
Action: Grid Connect Not Submitted reminder email.
Meaning: Its conditions cover the deposit and grid fields only, so it can chase grid paperwork while a proposal is still missing.Rule ID 2342503000015236379
Prospect - Change Pipeline · INACTIVE
When: Stage modified to Prospect; repeats; all opportunities.
Action: Pipeline Operations AND Stage Closed Won.
Meaning: Keep this rule inactive: its action would turn prospects into won opportunities.Rule ID 2342503000092065062
Closed Won - Set closing Date
When: Stage modified to any value; condition Stage Closed Won.
Action: Field update closed won - closing date.
Meaning: Existing test history shows 22 September changed to 23 September on the Closed Won event. The date of the Closed Won event needs comparing with the actual signature date.Rule ID 2342503000022607007
Set Field on Closed Won - Tech Review required
When: Created or edited while meeting Stage Closed Won.
Action: Tech Review Required field update; normal record history shows JOB STATUS = TECH REVIEW - Required.
Meaning: Use a separate acceptance fact because other rules also write JOB STATUS.Rule ID 2342503000116853313
3. Downstream Operations rules: stages 2 to 7
Stage Transition: 2. Job in Progress to Install Unscheduled
When: Created or edited to meet the conditions. Stage Job in Progress AND Tech Review contains Passed AND (Grid App Approved is populated OR Grid App Instructions contains NOT Required).
Action: Move Stage to Install Unscheduled. The conditions contain no signature check.Rule ID 2342503000110418343
Stage Transition: 3. Install Unscheduled to Install Booked
When: Customer Booked becomes selected. Stage Install Unscheduled.
Action: Move Stage to Install Booked.Rule ID 2342503000109264800
Stage Transition: 4.Install Booked to Install in Progress
When: On Install Date at 07:00, once. Stage Install Booked.
Action: Move Stage to Install in Progress.Rule ID 2342503000109264871
Stage Transition: 5.Install in Progress to Install Completed
When: Created or edited to meet conditions. Stage Install in Progress AND Wifi Status populated AND Install Completed selected.
Action: Move Stage to Install Completed.Rule ID 2342503000110431044
Stage Transition: 6. Install Completed To Completed
When: Edited to meet conditions. Stage Install Completed AND Install Completed selected AND Owners Handbook populated AND (Metering Email Sent populated OR Meter Request No) AND Post Install Call Complete populated.
Action: Progress Stage to Completed.Rule ID 2342503000016574569
Stage Transition: 7. Completed to Archived
When: Created or edited to meet conditions. Post Install Call Complete, Owners Handbook, Wifi Status and Paid In Full Date populated; STCs Submitted selected; Tech Review contains Passed; (Grid App Approved populated OR Grid App is Not Required); (Metering Email Sent populated OR Meter Request No).
Action: Move Stage to Archived. Starting Stage and Pipeline are unrestricted in the displayed criteria.Rule ID 2342503000116853195
Rule 2 uses “Grid App Instructions”; rule 7 uses “Grid App”. Those are different fields in the displayed criteria. “Meter Request No” means Meter Request has the value No.
4. Fields, checks and reminders
| Area inspected | What was found | Practical limit |
|---|---|---|
| Opportunity fields | Deposit Paid Date is Date; Deposit Amount is Single Line; Deposit not required is Boolean; Finance Status is Pick List. | The progression rule reads Finance Status. Finance Approved is a separate field. Andrew, please confirm how the payment process populates Deposit Paid Date and whether that method triggers the workflow. |
| Sales layout | A dedicated signed-proposal field is absent from the active layout I inspected. Unused items include Date Terms and Conditions Accepted, Proposal Submitted, Proposal Submitted Date and Sold Date. Layout showed 145 unused items and 3 custom fields left. | Inspect existing fields before adding more. Confirm that any reused acceptance field relates to the current proposal. Grid App Signature records a different document. |
| Built-in gates | Opportunity validation rules: none configured; Opportunity layout rules: none configured; Blueprints: none configured. | The proposed acceptance check belongs in the CRM fields and progression rules. |
| Existing scheduled reports | Active weekly schedules were visible for Closed Won - Deposit Not Paid and SALES - TSI Needed (Jobs In Progress). | The new holding stage needs a work queue and reminders suited to proposal follow-up and preparation. |
A temporary search found 23 Sales records with a deposit date: 18 Closed Lost and 5 open. One open record appears to be a test; the other four are older open records. Each record needs review to establish whether it is affected.
03
HOW
I recommend giving early deposits their own Open stage in Operations, with payment and proposal acceptance recorded as separate facts.
Proposed design only. My recommendation is that Operations can begin agreed preparation after a deposit, and we count the sale once the proposal is signed. The decisions in NEXT STEPS must be settled before implementation.
The proposed path
Deposit first · proposed route
Sales receives depositProposal still unsigned or not yet created.
Operations: awaiting signatureNew stage: Deposit received – awaiting signature.Open category. Preparation only.
Proposal acceptedConfirm the won sale once. Then use the existing funding and job-readiness checks.
The new stage should be classified Open, with an agreed forecast setting and probability. Keep the existing Job in Progress category unchanged so current won jobs retain their meaning.
| Facts known | Proposed destination | Count as won? |
|---|---|---|
| No deposit; no signed proposal | Sales, at its current sales stage. | No. |
| Deposit received; no signed proposal | Operations → Deposit received – awaiting signature. | No. |
| Signed proposal; funding condition not met | Operations → Closed Won. | Yes, under the proposed signature policy. |
| Signed proposal; funding condition met | Operations → Job in Progress, after the acceptance event has been processed once. | Yes. Count the opportunity once, using the agreed acceptance date. |
Funding condition means the current rule’s deposit date, Approved / Conditionally Approved Finance Status, or Deposit not required. Keep those existing alternatives visible in the design. Lewis and Andrew, please also confirm whether conditional finance or a waived deposit should allow preparation while the proposal is unsigned.
Try the proposed logic · illustration only
Current setup
Proposed setup
Choose an example to see how the proposed rules would handle it. This is an offline illustration.
Four examples: current and proposed
| Example | Current setup | Proposed setup |
|---|---|---|
| Paid, not yet signed | The condition can fail, or the target stage is on the other board. | Operations / awaiting signature; still Open. |
| Paid, then signed | Closed Won can move the pipeline. Whether the funding rule runs again needs testing. | Confirm acceptance once; progress the signed, funded job. |
| Signed, then paid | Closed Won moves to Operations. A qualifying funding update can advance the job. | Wait at Closed Won until funding qualifies, then progress. |
| Neither yet | Current Sales stage. | Current Sales stage. |
Andrew, here is where I recommend applying the fix
| Place | Proposed change | Reason / condition |
|---|---|---|
| Pipelines and Stage-Probability Mapping | Add Deposit received – awaiting signature to Operations only. Set category Open; agree probability and forecast handling. | Makes the job visible in Operations while it remains Open. Preserve the existing Job in Progress stage and category. |
| Opportunity fields / proposal acceptance | Record when the current proposal was signed, with a link or reference to the accepted proposal. Audit the unused Date Terms and Conditions Accepted field first. | Confirm who or what writes it. Link acceptance to evidence of the current proposal. Reuse an appropriate existing field where possible; three custom slots were shown. |
| New early-deposit workflow | On create/edit, when deposit is populated, proposal acceptance is absent and the opportunity is at an eligible open Sales stage: set Pipeline = Operations AND choose the new awaiting-signature stage in the same native Pipeline field-update action. | List the permitted open Sales stages explicitly. Exclude Closed Lost, cancelled and completed jobs. The inactive Prospect - Change Pipeline rule shows that one native Pipeline update can also select a Stage; keep that old rule inactive. |
| Stage Transition: 1 | Revise or replace the rule so it checks both event orders. Remove Prospect from its permitted starting stages. Progress only from Operations / Closed Won when the current proposal’s acceptance is verified AND the existing funding condition is met. | At Operations / Prospect, the existing rule can make a deposited job won without checking a signature. The revised rule must check again after either funding or acceptance arrives. Test its interaction with the Pipeline update. |
| Acceptance processing and Closed Won handover | Make the confirmed acceptance event set the correct won state and retain the intended handover. Verify the existing closing-date, welcome, celebration, technical-review and board actions run correctly once. | Test the rule sequence and its messages together, including the case where Closed Won is immediately followed by Job in Progress. |
| Stage Transition: 2 and Stage Transition: 7 | Add acceptance protection to the release into Install Unscheduled. Limit archive to Operations / Completed plus acceptance and the existing completion checks. Review the other stage rules for the same boundary. | Keep unsigned jobs in preparation even when technical or grid fields are already populated. Restrict archive to the intended Completed stage. |
| Unsigned Proposal and Deposit Paid - No progress | Use the verified unsigned state to create one signature-chase task for the salesperson. Review reminder timing and grid-email wording; stop signature reminders after acceptance. | Keep the signed-proposal record separate from JOB STATUS, preserve TECH REVIEW flags and create the chase task once. |
| Operations views and ops_kanban | Show the new holding stage in the Operations work queue and any mirrored board field. Keep a named salesperson responsible for the proposal. | Check owner assignment and board-sync actions alongside the pipeline transfer. |
| Sales This Month and the team’s official sales report | Use the agreed acceptance date and a true calendar-month range; exclude unsigned holding records. Include all intended won stages, including Install Completed, or use an approved won classification filter. | Confirm the official report, revenue field, cancellation treatment and month cut-off. Fix the inspected report’s FY-range mismatch only if it is meant to be monthly. |
Keep payment and acceptance separate
Proposed information flow
Payment input
Receipt or approved payment process
↓
Deposit Paid Date
“We have recorded payment.”
Acceptance input
Evidence that this proposal was accepted
↓
Signed-proposal record
“The customer accepted this proposal.”
The agreed rules check both factsThey choose the pipeline and stage, then prevent repeated welcome and celebration messages.
A possible field label is Proposal Signed Date. This is a proposed label; Andrew needs to check suitable existing fields and agree who or what records the date and proposal evidence.
Make the order of events safe
The same final facts should lead to the same final state, whether the deposit or signature arrives first. The rule must also cope with both facts arriving together, or a record being created with the deposit already filled in.
Order A · deposit first · proposed
DepositOperations / awaiting signature
SignatureProcess the acceptance event once
Signed + fundedOperations / Job in Progress
Order B · signature first · proposed
SignatureOperations / Closed Won
DepositRe-check the funding condition
Signed + fundedOperations / Job in Progress
Both orders should reach the same final state automatically, retaining the original deposit entry.
Check the facts each time
Payment present? Acceptance verified? Current pipeline and stage eligible? Then choose the correct destination. Once the job has moved on, the handover rule should stop matching it.
Protect the one-time actions
Keep the first genuine acceptance date stable. Record or otherwise reliably guard that the acceptance actions have been processed, so welcome and celebration actions run once.
Prefer standard Zoho rules and field updates where they can meet these checks. If the current rule cannot be changed to the required trigger type, prepare a replacement and retire the old rule only after testing. If a function is needed to process acceptance reliably, Andrew, I recommend one small function that checks the result and prevents the same actions happening twice.
Zoho documents create/edit triggers and rule ordering, and notes that some actions run in parallel. The test plan therefore needs to confirm the sequence and its visible results. Zoho: Configuring Workflow Rules.
Define what “Operations can start” means
Suggested starting boundary: Operations can review the information, identify missing details and prepare the job. The salesperson still completes and obtains acceptance of the proposal. Installation release remains blocked until acceptance and the existing technical, grid and funding requirements are met. Lewis, please define which preparation tasks your team can start at that point.
Proposed release gate
Preparation areaPaid, but awaiting signature.Review details. Chase proposal.
Check before releaseAcceptance verified?
Funding requirement met?
Technical and grid checks passed?
Funding requirement met?
Technical and grid checks passed?
Installation pathOnly when the agreed checks are met.
If a check is missing, hold the job and show what needs attention. Require the proper source stage before moving a job to Archived.
Apply the acceptance guard in workflow criteria as well as any manual-entry checks. Zoho says workflow and API updates can take precedence over layout rules, so the workflow conditions need the same protection. Test each way the team or an integration updates the record. Zoho: Layout Rules.
Keep these boundaries in the fix
- Keep unsigned deposits Open until the agreed acceptance point.
- Keep the old Prospect - Change Pipeline rule inactive because it also sets Closed Won.
- Use evidence of the accepted proposal to confirm the sale.
- Review the 23 candidate records individually, separating lost jobs and test records from affected customers.
04
NEXT STEPS
I suggest we agree the business rule first, prepare the CRM changes, then test both event orders before release.
| Owner | Decision or check | Evidence needed before implementation |
|---|---|---|
| Andrew + I | Confirm whether signature is the won-sale event and which date controls monthly sales. | Agreed definition, official report link and a deposit-in-September / signature-in-October example. |
| Lewis + I | Define allowed work while the proposal is unsigned. | A short preparation checklist, release boundary and named owner for chasing acceptance. |
| Andrew | Select a genuine affected opportunity for testing. | One real Shaun opportunity, its deposit date, proposal status and CRM timeline. |
| Andrew | Choose the signed-proposal field, the responsible person or system, and the action that marks the sale won. | Audit existing fields and what writes to them. Agree who or what records acceptance, then test the stage change, rule order, repeated events and board updates together. |
| Andrew | Prepare the change in a safe test environment. | Baseline of touched rules/actions/reports, a rollback plan and controlled test recipients. Use designated test records. |
Andrew, three checks before preparing the change
- Stage Transition 1 shows a change on 23 September. Please confirm what changed that day so this proposal fits any work already underway.
- Does the team already set JOB STATUS to Awaiting Signed Proposal? Check how the existing chase process is used.
- Review Operations / Closed Won records with a deposit date or another qualifying funding value. Check their timelines to see whether any are waiting for the rule to run again.
Show the sales month clearly
Example under the proposed signature policy
SeptemberDeposit received.
Proposal unsigned.0 won sales from this jobIt appears in the unsigned Operations queue.
Proposal unsigned.0 won sales from this jobIt appears in the unsigned Operations queue.
OctoberProposal accepted.
Record acceptance date.1 won sale from this jobIt appears in October’s sales report.
Record acceptance date.1 won sale from this jobIt appears in October’s sales report.
Later install stagesJob progresses.No extra saleKeep the original acceptance month through later stage changes.
Acceptance tests for the proposed fix
I recommend the following tests before release. For each test, check the visible opportunity, its timeline, Operations board, sales report and the actual notifications received.
| Test | Expected result |
|---|---|
| Deposit first at each eligible Sales stage | Moves to Operations / awaiting signature. Still Open. Won celebration and install release stay on hold. Test Prospect, Appointment Booked, Rebooking Required, To Be Quoted, Quote Sent/Followup, Hot, Warm and Cold. |
| Signature arrives after that deposit | Acceptance actions occur once. Moves into the signed/funded job path without clearing and re-entering the deposit. |
| Signature first, then deposit | Operations / Closed Won while funding is pending; advances to Job in Progress once funding qualifies. |
| Both facts together; create with deposit already filled | Same final outcome as the separate events. One successful transfer and one set of actions. |
| Repeated edits or repeated source event | One welcome, celebration, chase task and reporting count; the original acceptance date stays intact. |
| Approved / conditional finance; waived deposit | Existing funding alternatives work under the agreed policy; unsigned jobs remain Open. |
| Unsigned record already has technical/grid/completion data | Remains in the awaiting-signature stage. Test the archive rule’s added source-stage restriction. |
| CRM entry paths | Apply the same acceptance checks through each way records are updated. Include an attempt to mark Closed Won without valid signed-proposal evidence; agree and test how that is prevented or flagged. |
| Missing proposal or acceptance of a different proposal version | Stays pending and exposes a clear follow-up. Acceptance must relate to the current proposal before the job becomes won. |
| Month boundary | Deposit in September, signature in October: no September won sale; one October sale, under the proposed policy. A job at Install Completed remains in the sales month it belongs to. |
| Refund, cancellation, Closed Lost or reopened job | Reopening requires a deliberate decision based on current customer intent. Apply the agreed cancellation/refund rule and preserve an audit trail. |
| Existing signed jobs and Operations board | Normal handover and stages 2–7 still work; owner, ops_kanban, reminders and monthly results remain correct. |
Then review the backlog carefully
Start with the five open Sales records that have a deposit date. Separate the apparent test from customer records, then confirm each customer’s payment, proposal and current intent. Review the 18 Closed Lost records only where there is a specific reason. Confirm current customer intent before reopening a lost job.
Release and rollback
Proposed implementation order
1 · AgreeWin policy, CRM acceptance field and allowed preparation.
2 · PrepareStage, signed-proposal record, rules, boards and reports.
3 · ProveBoth event orders, no duplicates, correct sales month.
4 · Release laterSmall approved group, then monitor.
Before a later release, keep the exact previous rule definitions and affected record values. Limit the first release using agreed rule conditions, such as designated test records or a named pilot group. Verify both event orders, and watch the customer-facing messages and sales totals. If the change fails, disable the replacement logic, restore the previous definitions and review changed records individually. Any messages already sent remain sent, and affected records need individual review and correction.
My findings and recommendation
I found a mismatch between the deposit rule’s Stage action and the pipeline the opportunity is in. I also found that Job in Progress is already classified as won. My recommendation is an Open awaiting-signature stage in Operations, supported by revised transfer rules, acceptance checks and reporting.
Once we agree the decisions above, Andrew can prepare and test the CRM changes. Lewis’s preparation checklist will set the boundary for the new Operations stage.
I based this report on a live read-only inspection of CRM organisation 641354533, the Sales layout, both pipelines, the listed workflow definitions and native actions, existing record timelines, the Manual source filter, field controls and the saved Sales This Month report. Record dates and times are as displayed in CRM. Relevant settings are a snapshot as at 26 September 2026.