Sample plan: connecting approved CRM orders to ERP jobs.

Scenario: an established B2B field-service company tracks sales in a CRM, jobs in an ERP, and invoices in an accounting system. When sales marks an order approved, an operations coordinator rekeys the customer, service location, purchase order, promised date, and scope into the ERP. A billing specialist later creates or matches the accounting record.

Follow-up emails sometimes cause a second job to be opened. Address and scope corrections do not reliably reach every system. Dispatchers can schedule an outdated job, technicians can arrive without the latest instructions, and billing waits while staff determine which customer and job numbers belong together.

Proposed work: connect the order and job records. An approved CRM order creates or updates the correct ERP job and carries a shared reference into accounting. Records that cannot be matched safely stop in a queue for an operations coordinator. Sales, operations, dispatch, and billing can see what moved and what still needs attention.

Illustrative duration

8 weeks plus 30 days to correct defects in the agreed work

Commercial model

Fixed price with defined milestones

Working relationship

Direct access between Whisker Tech and the operations decision-maker

Included work

• A documented map of the approved-order workflow, field ownership, cross-system identifiers, and the exact conditions that permit automatic job creation.
• An integration that validates approved CRM orders, creates or updates ERP jobs without duplicating prior work, and writes the shared job reference to a uniquely matched accounting project.
• Company-specific readiness rules for required purchase orders, service locations, scope approval, and promised dates, limited to the rules confirmed during boundary review.
• An operations queue showing records that need a person to resolve, the reason they stopped, prior attempts, and a safe retry action.
• A status view for sales, operations, dispatch, and billing, plus production deployment, operating instructions, decision notes, handoff, and launch support.

Representative acceptance checks

• For each agreed test order that meets the readiness rules, one ERP job is created with the expected customer, location, purchase order, date, and scope fields.
• Reprocessing the same order or receiving a repeated CRM event does not create another ERP job.
• An approved correction updates only the fields assigned to the CRM; dispatcher-owned scheduling fields in the ERP remain unchanged.
• An order with a missing purchase order or an ambiguous customer match creates no job and appears in the operations queue with a specific reason.
• A uniquely matched accounting project receives the shared job reference; an ambiguous accounting match stops for billing review without changing either candidate.
• After an operations coordinator corrects the source or selects the documented match, retry completes the job and records who resolved the exception.
• The client’s designated operations administrator can review status, resolve a test exception, retry it, and follow the documented recovery procedure without Whisker Tech assistance.

Explicit exclusions

Replacing the CRM, ERP, or accounting platform; cleaning all historical customer data; merging suspected duplicate customers automatically; redesigning dispatch; a technician mobile app; custom financial reporting; tax or revenue-recognition logic; 24/7 response; uptime guarantees; and ongoing maintenance are outside this example phase.

1. Weeks 1–2: boundary confirmation. Observe how sales and operations open a job, confirm field ownership and readiness rules, examine representative records, map system access, and approve acceptance examples.
2. Weeks 3–4: connection checkpoint. Demonstrate validated CRM order intake, shared identifiers, repeat-event protection, and ERP job creation against agreed test cases.
3. Weeks 5–6: operations checkpoint. Demonstrate corrections, accounting references, exception reasons, role-appropriate status, and operator retry in a client-accessible environment.
4. Week 7: production readiness. Rehearse deployment and recovery, complete any client-required security review, train the designated administrator, and run client acceptance checks.
5. Week 8: launch and handoff. Release the accepted workflow to the agreed users, monitor initial processing, transfer operating knowledge, and begin 30 days of defect correction for the agreed work.

Access the client provides

The operations leader can decide how exceptions should be handled. A sales representative, operations coordinator, dispatcher, billing specialist, and IT or vendor contact are available to answer workflow questions. The client provides lawful access to representative records, application sandboxes or approved test accounts, API documentation, security requirements, and acceptance feedback within the agreed response times. Dependency delays move the milestone dates rather than reducing the implementation time.

Example weekly status

Change control

I record each requested change with its reason and its effect on acceptance, price, schedule, and exclusions. Work proceeds after written agreement. Changing the label for a known exception is a normal clarification. Adding inventory allocation or redesigning dispatch is new work and needs a scope change.

Handoff and ownership

The client receives the custom source, deployment instructions, a system and account inventory, field mappings, business-rule decisions, recovery instructions, and known limitations. Repositories and operational accounts are client-controlled where practical. I also hold a live or recorded handoff session. Ongoing support is optional and priced separately.