Services at customer locations

Can this mobile appointment happen?

Check the address, access, staff, equipment, and full travel window before confirming the visit.

First checks

  1. Qualify the address

    Capture a usable customer address and resolve inside, boundary, or outside service-area state.

  2. Qualify the work

    Confirm that this service may happen there and that an eligible worker can perform it.

  3. Protect the whole interval

    Include preparation, service duration, cleanup, inbound travel, and outbound travel around adjacent work.

  4. Recheck the promise

    After a material change, recalculate feasibility, price or fee disclosure, and every dependent view.

A mobile-service worker finishes one home visit, packs equipment into an unbranded vehicle, travels to another address, and approaches the next customer while a dispatcher monitors the day.
A customer-address appointment consumes more than visit time.Worker eligibility, equipment, cleanup, travel, arrival promises, and the next booking belong to one feasibility decision.
Customer-location feasibility checker

Which gate stops this invented appointment?

Choose only declared synthetic states. The checker returns feasible, boundary review, blocked, or invalid and names the shared owner of the first unresolved gate.

Your result

Review one unresolved boundary

Do not confirm yet: dependent customer and staff views disagree or remain unchecked.

Reason
VIEWS_UNRECONCILED
Check next
Customer-location reconciliation, then message, calendar, and export delivery

Address and area

inside

The service address must resolve to inside, boundary, or outside.

Service at location

mobile allowed

The chosen service must allow customer-location delivery.

Worker eligibility

eligible

A currently qualified worker must cover the area and schedule.

Full time chain

current fit

Preparation, service, cleanup, inbound travel, and outbound travel must fit.

Fee disclosure

disclosed

The current fee state must be known before confirmation.

Material-change recheck

current

A changed address, service, worker, duration, time, travel, or fee needs a fresh result.

Cross-view state

not checked

Customer, dispatcher, worker, message, calendar, export, and history views must agree.

Override

none

Any override needs an attributable actor and reason.

The checker stores nothing and performs no address lookup, route calculation, booking, assignment, fee calculation, message, calendar write, product test, or compliance review.

Understand the complete feasibility rule

Test one customer-location appointment before comparing software.

A free-looking time is not enough for work at a customer address. The address, service area, service, worker, full travel-and-buffer interval, fee, and every customer and staff view must describe one feasible appointment.

Why an open calendar slot can still fail

Customer-location work is a conjunction, not a single availability check.

An address may sit outside the service area. A service may be fixed-location only. The available worker may lack the right qualification. Travel can overlap the previous or next job. A fee may remain unknown, or a changed address may leave old confirmations active.

The combined feasibility rule

Feasible mobile appointment = valid address + eligible service area + service allowed at that location + eligible worker + current full time chain + disclosed fee state + material-change recheck + reconciled views

The invented worksheet below uses non-geographic address tokens, two workers, fixed travel values, and made-up appointments. It identifies the first unresolved gate; it never geocodes, routes, books, charges, messages, or tests a named product.

Follow the complete customer-location workflow
  1. Capture one service address

    Keep the service address distinct from billing, contact, branch, and worker-origin addresses. Reject missing or malformed input before promising availability.

  2. Resolve the service-area result

    Use the shared service-area owner to return inside, boundary-review, or outside. Do not silently turn a boundary case into eligible.

  3. Match service and worker

    Confirm that the chosen service is deliverable at the customer location and that at least one currently eligible worker covers the area and time.

  4. Protect the consumed interval

    Use the shared duration, buffer, and travel owners to protect preparation, service, cleanup, inbound travel, and outbound travel around adjacent work.

  5. Disclose the current fee state

    Show no fee, a known disclosed fee, or an unresolved fee before confirmation. A changed location must not retain an obsolete promise.

  6. Change, recheck, and reconcile

    Re-run every affected gate after address, service, worker, duration, time, travel, fee, or schedule changes, then compare customer, dispatcher, worker, message, calendar, and export views.

Compare the four honest outcomes

Feasible

Every required input is current and the customer, dispatcher, and worker views agree.

Watch for

This permits only the next controlled step; it is not proof that a real product or route will work.

Boundary review

A boundary address, missing or stale travel value, unresolved fee, unreconciled view, or material change needs a human decision or recalculation.

Watch for

Do not offer or confirm the time while an essential input is unknown.

Blocked

The address is outside, service is fixed-location only, no worker qualifies, the time chain overlaps, or an override is unattributed.

Watch for

Return a clear reason and safe alternative instead of exposing an impossible slot.

Invalid

A required synthetic input is missing or unsupported.

Watch for

Repair the input before interpreting any downstream result.

Review the eight connected records

Service address

Owns the normalized customer-location input and explicit validation state.

Failure to test

A billing or contact address is mistaken for the place where work will happen.

Service-area result

References the current inside, boundary, or outside decision from the shared area rules.

Failure to test

A ZIP prefix or map picture becomes an unexplained universal approval.

Service-at-location rule

States which service and delivery mode may happen at the selected location.

Failure to test

A fixed-location service appears for customer-address booking.

Worker eligibility

References the current worker, qualification, zone, origin, schedule, and assignment state.

Failure to test

An available person is assigned without the required service or area eligibility.

Consumed interval

Owns preparation, duration, cleanup, inbound travel, and outbound travel around adjacent work.

Failure to test

Only the visible service minutes are blocked.

Fee state

Keeps no fee, a disclosed current fee, or an unresolved fee attached to this appointment version.

Failure to test

The customer and staff see different or stale travel charges.

Change history

Preserves actor, channel, old state, new state, reason, and the recheck result for every material edit.

Failure to test

A dispatcher override or mobile edit silently changes the promise.

View reconciliation

Connects customer, dispatcher, worker, message, calendar, export, and history views to the same appointment state.

Failure to test

One screen looks correct while another still sends or displays the old visit.

Inspect the complete invented mobile-service day

All names, addresses, travel values, fees, and appointments below are invented and stay inside this page.

01

Address

No geocoding

ADDRESS-IN, ADDRESS-BOUNDARY, and ADDRESS-OUT are invented non-geographic tokens.

02

Service

Delivery rule explicit

SERVICE-MOBILE-60 may occur at a customer location; SERVICE-FIXED-90 may not.

03

Workers

Eligibility separated

WORKER-A and WORKER-B have different synthetic zones, qualifications, origins, and adjacent appointments.

04

Time chain

Both sides protected

Use fixed 0, 15, 30, or impossible travel values plus 15-minute before and after buffers.

05

Fee

Disclosure state only

Compare no fee, one disclosed flat fee, and one unresolved fee without calculating money.

06

Change

No external write

Change address, worker, duration, time, travel, and fee; preserve the old result and require a fresh one.

Review appointment changes and demo warning signs

When the mobile appointment changes

The address changes

Re-run area and travel

Preserve the old address state, then recheck area, worker coverage, route values, fee state, and customer promise.

The service changes

Re-run delivery eligibility

Confirm customer-location eligibility, worker qualification, duration, buffers, travel, fee, and instructions for the new service.

The worker changes

Re-run both route legs

Use the new worker's zone, qualification, origin, adjacent appointments, travel values, and mobile assignment state.

The duration or time changes

Rebuild the full interval

Protect preparation, service, cleanup, inbound travel, and outbound travel before offering the replacement.

Travel or fee changes

Withdraw stale promises

Mark the previous result stale, disclose the new known state, and obtain review when travel or fee remains unresolved.

A dispatcher or worker overrides

Attribute and reconcile

Record actor, reason, old and new states, then compare every customer, dispatcher, worker, message, calendar, export, and history view.

Warning signs in a software demo

Address is just a notes field

The demo cannot distinguish service address, validation state, service-area result, or the appointment version it belongs to.

Any worker can take the job

Area, qualification, origin, delivery mode, and schedule do not participate in assignment.

Travel is display-only

A map or route estimate appears after scheduling but never protects availability before confirmation.

Only inbound travel is checked

The visit fits after the previous job but makes the next appointment impossible.

A change keeps the old promise

Address, worker, duration, time, travel, or fee changes do not force a full recheck and fresh confirmation state.

One view silently wins

Customer, dispatcher, worker, message, calendar, export, or history views disagree without a visible reason and recovery path.

Prepare the next controlled rehearsalOne controlled mobile-service rehearsal

Test the combined gate before testing products.

Use the invented address, service, worker, interval, fee, and change states to define what software must prove.

  1. Write the owner and allowed states for the service address, area result, service-at-location rule, worker eligibility, full consumed interval, fee, change history, and reconciled views.
  2. Run inside, boundary, outside, fixed-only, no-worker, travel-overlap, stale-travel, unresolved-fee, changed-without-recheck, and view-mismatch cases.
  3. Carry the same fixture into every later product test and record pass, boundary, blocked, invalid, workaround, unknown, plan, version, date, and limitation without forcing a winner.

Keep the rehearsal controlled

  • Use invented address tokens, people, services, appointments, travel values, fees, messages, calendars, exports, and records only.
  • Do not enter a real customer, address, worker, route, payment, account, message, calendar, tax, safety, insurance, license, or regulated record.
  • Do not convert a documentation note or checker result into live availability, arrival accuracy, product capability, recommendation, affiliate route, purchase, implementation, or publication approval.

Detailed guides for each shared rule

Next steps