Job Resulting SOP (Internal)

Standard Operating Procedure

1 — PROCESS TABLE

2 — POLICIES

Job-Level Resulting

• Job Resulting applies to the entire job — not to individual estimates within a job.
• If separate outcomes are required for separate estimates, separate jobs must be created.

Field Configuration

• Every Job Resulting configuration must include at least one field per result type (Sale and No Sale).
• Field labels must be clear and user-friendly — no internal shorthand or ambiguous naming.
• Dropdowns are required when data standardization matters for reporting. Free text is only acceptable when open-ended input is genuinely needed.
• Required fields must be limited to what is truly necessary. Overuse of required fields blocks workflow and degrades adoption.

Email Behavior

• Every Job Resulting submission triggers an outbound email and a downloadable document.
• Each resubmission sends a new email and overwrites the previous result.
• Email recipients must be confirmed with the client during setup (Step 01) — not assumed.

Data Integrity

• Fields must be designed to capture consistent, reportable data.
• ⚠️ There is currently no system-level enforcement preventing a user from submitting a result without meaningful data in non-required fields — field design and training are the primary controls.

Editing & Resubmission

• Users may edit and resubmit a job result at any time.
• Each resubmission overwrites the prior result and generates a new email — teams must be made aware that historical results are not preserved.

Access & Activation Control

• ⚠️ Who has permission to enable or modify Job Resulting in Global Settings is not yet defined. Pending team confirmation.

3 — STEP BY STEP

Step 1 — Setup Review

Owner: Onboarding / AM

• Meet with the client to define their intended use of Job Resulting before any configuration begins.
• Confirm:
  • What constitutes a Sale in their workflow
  • What constitutes a No Sale in their workflow
  • What information they want to capture for each outcome
  • Who should receive Job Resulting emails
• Document the agreed use case before moving to configuration.
• Do not configure Job Resulting if the client's workflow does not require job-level outcome tracking.

💡 If the client is unsure what data they want to capture, walk them through common use cases (e.g. close reason, sale amount, loss reason) to help them define fields before configuration.

Step 2 — Configuration

Owner: Onboarding / CSR

• Navigate to Global Settings and enable Job Resulting.
• Configure both Sale and No Sale result types. For each:
  • Select a Pattern
  • Define Email Recipient(s) — confirmed in Step 01
  • Add at least one Field
• Field setup guidelines:
  • ☐ Labels are clear and user-friendly
  • ☐ Dropdowns used wherever data standardization is needed
  • ☐ Required fields limited to what is truly necessary
  • ☐ At least one field added per result type

⚠️ Configuration is not validated until Step 03 is complete — do not train users on an untested configuration.

Step 3 — Validation

Owner: Onboarding / CSR

• Using a sample job, test the full Job Resulting flow:
  • ☐ Result the job as a Sale — confirm fields appear, required logic enforces, email is received, download works
  • ☐ Result the job as a No Sale — confirm same checks pass
  • ☐ Edit and resubmit a result — confirm overwrite behavior and new email generation
• If any check fails, return to Step 02 and correct configuration before proceeding.

⚠️ Do not proceed to user training until all validation checks pass.

Step 4 — User Training

Owner: Onboarding / AM

• Train end users on the following:
  • Where Job Resulting lives — the Information Tab on a job
  • The difference between Sale and No Sale and when to use each
  • How to complete required and optional fields
  • What happens after submission — email sent, data recorded
• Set clear expectations:
  • Job Resulting applies to the entire job, not individual estimates
  • Results can be edited and resubmitted — but each resubmission sends a new email
  • Required fields must be completed before submission is allowed

Training confirmation checklist:

• ☐ Users know where to find Job Resulting
• ☐ Users understand Sale vs. No Sale distinction
• ☐ Users know what each field means and how to complete it
• ☐ Users understand submission behavior and email output
• ☐ Users understand job-level (not estimate-level) scope

💡 If users are confused about the estimate-level limitation, clarify early — this is one of the most common points of friction.

Step 5 — Usage

Owner: End User

• During their normal workflow, users result jobs by:
  1. Opening the job and navigating to the Information Tab
  2. Selecting Sale or No Sale
  3. Completing all required fields
  4. Submitting the result
• Expected system behavior after submission:
  • Job is marked with a result
  • Email is sent to configured recipients
  • Data is captured and available for reporting

⚠️ There is no system prompt or reminder that forces users to result jobs — adoption depends on workflow discipline and training. Pending confirmation: is there a mechanism to flag unresulted jobs for follow-up?

Step 6 — Monitoring

Owner: AM / CSR

• Review Job Resulting usage regularly. Check for:
  • ☐ Fields being completed correctly and consistently
  • ☐ Users skipping or misunderstanding fields
  • ☐ Emails reaching the correct recipients
  • ☐ Unusual resubmission patterns (possible user confusion)
• If issues are found, take corrective action:
  • Simplify or relabel confusing fields
  • Adjust required field settings
  • Retrain users if behavior issues persist
  • Update email recipients if contacts have changed

💡 Monitoring cadence is not yet defined. Recommend establishing a regular review interval (e.g. monthly during first 90 days post-launch).

4 — BEST PRACTICES

1. Define the use case before touching configuration. Job Resulting only works well when the client has a clear picture of what a Sale and No Sale mean in their workflow. Rushing into configuration without that alignment leads to fields that don't match reality and data that can't be used for reporting.

2. Keep fields simple and intentional. Every field added to Job Resulting is a field a user has to complete. Design for the minimum necessary data to support reporting. Extra fields create friction, reduce adoption, and often go incomplete — which defeats the purpose of capturing outcomes.

3. Default to dropdowns over free text. Dropdowns enforce consistency and make data reportable. Free text fields produce spelling variations, abbreviations, and edge cases that are hard to aggregate. Use free text only when open-ended input genuinely cannot be standardized.

4. Validate before training. Never train users on a configuration that hasn't been tested end-to-end. A broken required field or a missing email recipient discovered during training damages credibility and requires retraining.

5. Set expectations about job-level scope early. The most common point of confusion is users expecting to result individual estimates separately. Address this explicitly in training — before users run into it on their own — and explain why separate jobs are the correct approach when separate outcomes are needed.

6. Treat resubmission behavior as a training topic, not a footnote. Because every resubmission sends a new email and overwrites the previous result, users need to understand this before they start editing results. Unexpected emails reaching stakeholders erode trust in the process.

8. Align Job Resulting to reporting goals, not just workflow. Job Resulting is most valuable when its output feeds into meaningful reporting. During setup, confirm what reports the client intends to run and work backwards to ensure the fields and values will support that analysis.