Rescheduling a Marketplace or Private Network Site Visit
Once a technician has accepted a marketplace or Private Network Site Visit, the schedule is a commitment on both sides. Neither party can simply overwrite it — a date change has to be proposed and agreed. That is what the schedule change request is for.
This applies only to marketplace and Private Network visits with an assigned technician. Visits your own employees are running are edited normally.
Why it works this way
A technician who has accepted a visit has blocked out that window, possibly turned down other work for it, and may be travelling to reach you. If the date could be changed from your side alone, they would find out by accident. The same is true in reverse: if the technician could move it, you would be telling a customer to expect someone who isn't coming.
So the schedule only moves when both sides have agreed. Until the other party accepts, nothing changes — the visit keeps its original date and time, and everyone continues to see the schedule they already planned around.
Requesting a change
Open the Site Visit and choose Request Schedule Change from the menu at the top. You propose the new date and time — and an end date and time if the visit uses an arrival window — and you can add a note explaining why. The note is the useful part: "the site's network cutover slipped to Thursday" gets accepted; a bare new date gets questions.
Either side can start this:
You (the dispatching company) use Site Visit Actions → Request Schedule Change, and the assigned technician accepts or declines. This option is only there until the technician checks in.
The technician uses Tech Actions → Request Schedule Change, and you accept or decline. They can do this until they check out. While a request is already pending, their option is greyed out with A change is already pending.
Once sent, a banner appears on the Site Visit for both parties showing what has been proposed and who is waiting on whom. The other party is notified in the app and by email. Until it's answered, whoever sent it can take it back with Cancel Request on the banner.
When your customer sees it too
If the Site Visit belongs to a project you've shared with your own customer, a pending request from either side also shows on their shared page as a new date for them to approve, and the people on the project's Client Notifications list are emailed about it. If your customer approves a date the technician asked for, that accepts the technician's request — the same as you clicking Accept.
Accepting or declining
Whoever receives the request sees the proposed date and time alongside the current one and chooses:
Accept — the Site Visit moves to the new date and time immediately. The calendar, notifications and reminders all follow.
Decline — the visit keeps its original schedule. The banner stays visible for seven days so the request isn't silently forgotten, and either side can propose something different.
A declined request is not a dead end. It usually means the proposed slot doesn't work, not that the change is refused — send another with a different date.
Requests expire 30 minutes after the proposed start
A schedule change request lapses 30 minutes after the start time it proposed, measured in the site's own local time. After that it can no longer be accepted, and the banner shows it as expired for the next 24 hours.
The 30-minute grace exists on purpose. Expiring exactly at the proposed start punished a technician who tapped Accept a few minutes late — the request vanished and the whole exchange had to be repeated for something harmless. A visit accepted slightly late simply reads as running late, which happens anyway.
If a request expires, just send a new one.
The one exception is a request from your side that was already in the past when you sent it — a deliberate backdate. Those never expire on their own; see the next section.
Setting a date and time after the visit has happened
Sometimes a Site Visit is worked before it is scheduled — the technician goes to site anyway, and the real date and time only get recorded afterwards. The client side can request a start that is already in the past, and that request will not expire on its own: it stays open until the technician accepts or declines it. The technician side is unchanged — a request from the technician for a start that has already passed simply expires under the usual 30-minute rule, so only the client side can record a backdated schedule.
Timing matters. Request Schedule Change leaves the Site Visit Actions menu as soon as the technician checks in. So send a backdated request before the technician checks in on the Site Visit. After check-in, the only way to send one is Submit New Request on the banner of an earlier request of yours that was declined or expired.
Once a backdated schedule is accepted, Service Envoy treats it as what it is: a time nobody could have been early or late for. On that Site Visit —
On Time and DB Check In read Schedule Set Retroactively instead of Late, and neither lowers the technician's on-time rate.
No "technician hasn't checked in" email goes to the client.
No no-show is recorded against the technician — not automatically, and not by hand either.
This applies only when the schedule was written down more than 15 minutes after its scheduled start had already passed. A schedule saved a few minutes late, or any schedule entered before its start time, is scored the usual way.
Only the most recent request counts
When you (the dispatching company) send a new request while one is still pending — yours or the technician's — it replaces it. The older request is superseded and disappears from the banner — you will never have two live proposals competing on the same visit, and nobody is asked to choose between them.
A technician can't replace a pending request this way: their menu option stays greyed out until the pending one is answered, expires or is cancelled.
This is also why a superseded request leaves no banner behind. Its history is in the Site Visit's activity feed if you need it; the banner is reserved for what is actually live.
Moving a visit more than 24 hours out resets the technician's confirmation
This is the part most worth knowing. If the technician has already submitted their 24-hour confirmation and an accepted change pushes the visit more than 24 hours into the future, that confirmation is cleared and the technician is asked to confirm again for the new date.
That is intentional. A 24-hour confirmation is a promise about a specific, imminent day. Once the visit is three days out, the promise no longer refers to anything — carrying it forward would show a confirmed visit that nobody has actually confirmed.
What you will see after such a change:
The Tech 24 Hour Confirmation Submitted badge disappears from the Site Visit.
The technician's confirmation task reopens, and they are prompted again as the new date approaches.
A note is written to the Site Visit's activity feed recording that the confirmation was reset and why.
So if a confirmation seems to have "disappeared" after a reschedule, this is why — the technician has not gone quiet, they simply have not yet confirmed the new date.
A change that keeps the visit within the next 24 hours — moving a morning appointment to the afternoon of the same day — deliberately keeps the confirmation. It is still a promise about imminent work, and asking again would be noise.
If the technician comes off the visit
If the assigned technician is removed or unassigned while a request is pending, that request is cancelled automatically. There is nobody left to agree to it, and leaving it live would let a schedule move by the consent of someone no longer on the job.
Quick reference
Request sent — Schedule unchanged until accepted; other party notified
Accepted — Date and time move immediately
Declined — Original schedule kept; banner visible for 7 days
Not answered — Expires 30 minutes after the proposed start (site local time)
Client request for a start already in the past — Never expires on its own; stays open until the technician answers
Schedule recorded after its start had passed — On Time and DB Check In read Schedule Set Retroactively; no late alert, no no-show
Dispatching company sends a new request while one is pending — The older one is superseded
Technician checks in — Dispatching company's Request Schedule Change option disappears
Technician checks out — Technician's Request Schedule Change option disappears
Customer approves a technician's requested date on their shared page — The technician's request is accepted
Accepted change lands more than 24h out — Technician's 24-hour confirmation resets
Accepted change stays within 24h — Confirmation is kept
Technician unassigned — Pending request is cancelled
Good practice
Always write the note. A reason gets a fast yes; a bare date gets a slow question.
Send it as early as you know. A technician who learns on the day has already committed the day.
Don't chase a silent request — resend it. If the proposed start has passed, the request is gone and a new one is the only way forward (unless you deliberately backdated it — those stay open until the technician answers).
After a big move, expect the confirmation to reset. Build the re-confirmation into what you tell your customer, rather than treating its absence as a problem.