Support runbooks

ServiceTitan-ready support center.

Manual pilot runbooks for keeping leads safe, website promises accurate, and customer proof honest before any ServiceTitan API connection exists.

Support controls
6
runbooks
2
lead-safety paths
3
owners
3
safe messages
Manual support is part of the product. A captured lead, visible fallback, and honest support note are acceptable proof before API access exists.

Incident runbooks

Failed lead or booking handoff

Owner: PageToJob

sev 1manual ready

A booking request, contact lead, Scheduling Pro handoff, export, or future API sync cannot be delivered.

Customer impact: A visitor may be waiting for a response, but the website lead record and notification fallback stay intact.

First response: Confirm the PageToJob lead exists, send or resend the business notification, and mark the handoff manual if automation is unavailable.

Do not claim a ServiceTitan write, booking creation, or job creation unless approved API logs prove it.
Response steps
  • - Confirm source URL, form type, contact fields, Titan Map binding, and idempotency key.
  • - Check whether the business notification fallback was delivered.
  • - If ServiceTitan is not connected, complete the handoff manually and mark the record manual-complete.
  • - If future API sync is enabled, retry only when the failure is transient and the idempotency key is present.
  • - Record last error, owner, customer-safe state, and next action in the support note.
Lead recordNotification statusTitan Map bindingIdempotency keyManual-complete note
The website captured the request and the manual notification path is active. We are reviewing the handoff state now.

Customer disconnect or revoked access

Owner: Shared

sev 2customer required

A customer revokes future ServiceTitan authorization, changes admin ownership, removes scopes, or fails an eligibility check.

Customer impact: API-backed imports, sync, or outcome matching would pause, while the public website and manual fallback continue.

First response: Disable API-backed claims for the account, confirm the manual booking path, and ask the customer to identify the ServiceTitan admin.

Token revocation, encrypted token removal, and reconnect audit logs are future API requirements.
Response steps
  • - Record disconnect time, affected features, missing scopes, and customer admin contact.
  • - Keep local forms, phone CTAs, notification fallback, Titan Map review, and drift review active.
  • - Remove API-backed language from proof packets until access is restored.
  • - Request customer authorization only after the required scope and module list is clear.
Disconnect noteAffected featuresAdmin contactManual fallback statusUpdated proof packet
Your website remains active in manual mode. API-backed ServiceTitan features are paused until the admin connection is restored.

Website and ServiceTitan drift conflict

Owner: Shared

sev 2manual ready

A job type, business unit, zone, campaign, offer, membership, or pricebook item does not match the live website.

Customer impact: The site may promote a stale service, paused zone, expired offer, or untracked campaign.

First response: Create a drift finding and keep the public site unchanged until the customer confirms the operational change.

Imported taxonomy should remain read-only and should not automatically rewrite public pages.
Response steps
  • - Identify affected URL, CTA, form, offer, or page section.
  • - Compare the current website copy against the manual Titan Map and customer-supplied source.
  • - Assign severity, owner, recommended fix, and review state.
  • - Publish only after customer approval or documented operating confirmation.
Affected URLCurrent copySource artifactRecommended fixApproval note
We found a possible mismatch between the site and your operating setup. We will not change the public page until you confirm the correct direction.

Booking path or scheduler outage

Owner: PageToJob

sev 1manual ready

The embedded scheduler, booking form, phone CTA, or appointment request path is unavailable or misconfigured.

Customer impact: Visitors may be unable to book through the preferred path, so the fallback path must become obvious immediately.

First response: Switch the affected page to the safest working CTA: phone-first, request appointment, or manual form notification.

Scheduling Pro installation and webhook behavior require customer module eligibility and approved setup.
Response steps
  • - Confirm which page, CTA, embed, or form path is failing.
  • - Verify whether the local form and notification fallback still work.
  • - Remove or de-emphasize a broken scheduler embed until it is restored.
  • - Document the fallback path and retest on desktop and mobile.
Affected routeFallback testNotification recipientDesktop checkMobile check
We are routing visitors through the working fallback path while the preferred booking path is reviewed.

Privacy, redaction, or deletion request

Owner: Shared

sev 2manual ready

A customer asks to delete, redact, or stop using lead details, exports, screenshots, or proof artifacts.

Customer impact: PII and operational screenshots must be handled without weakening public website operation.

First response: Identify the affected artifact class, redact shared materials, and confirm whether deletion or anonymization is required.

Future API mode must include disconnect, token deletion, retention logs, and audited deletion workflows.
Response steps
  • - Classify the request as lead data, booking envelope, manual Titan Map, export, screenshot, or future token reference.
  • - Remove direct personal details from customer-facing proof packets.
  • - Delete or anonymize retained artifacts according to the implementation data policy.
  • - Record what was removed, what remains, and why any retained non-PII evidence is needed.
Artifact listRedaction noteDeletion noteRetained non-PII reason
We can redact or remove the requested materials while preserving non-sensitive operational proof where needed.

Revenue proof or attribution dispute

Owner: Shared

sev 3manual ready

A customer questions lead, booking, job, invoice, payment, campaign, or revenue matching in a proof packet.

Customer impact: The customer may distrust the report if uncertain matches are not clearly labeled.

First response: Move disputed records to needs-review and remove them from closed-loop revenue claims until the source is confirmed.

Live closed-loop attribution requires approved outcome data access and visible match-quality evidence.
Response steps
  • - Show source path, UTM fields, campaign binding, submitted lead time, and candidate booking or invoice references.
  • - Separate matched, unmatched, and needs-review records.
  • - Ask for corrected export fields when invoice, job, or booking IDs are missing.
  • - Republish the proof packet with match-quality labels and a clear exclusion note.
Source fieldsCandidate IDsExport columnsMatch-quality labelExclusion note
We are excluding uncertain records from revenue totals until the source and match quality are confirmed.

Escalation matrix

PageToJob support owner

Triage website, form, notification, Titan Map, drift, and proof packet issues.

Same business day for standard issues; immediate review for lead-safety or booking-path outages.
Affected URLCurrent customer impactFallback statusSupport note

Customer operating owner

Confirm service, zone, capacity, offer, membership, and campaign business decisions.

Within 2 business days for normal drift review; faster for launch blockers.
Decision neededRecommended fixPublic-page impact

Customer ServiceTitan admin

Confirm future app authorization, modules, scopes, Scheduling Pro setup, exports, and revoked access.

Required before any API-backed claim or reconnect can be represented as available.
Requested module or scopeAdmin contactConnection statusAPI-gated feature

Evidence rules

Lead safety beats integration status

A captured lead plus a manual notification fallback is a valid support success; do not wait for ServiceTitan automation.

No false sync claims

Never describe a handoff as written to ServiceTitan unless the account has approved access and the external IDs prove it.

Customer review protects the website

Drift findings and imported taxonomy should create reviewable fixes, not surprise changes to public pages.

Revenue proof needs match quality

Reports must separate matched, unmatched, demo, and needs-review records before showing revenue claims.

Customer-safe language

The account has no approved ServiceTitan connection yet.

Say: Your site is operating in manual ServiceTitan-ready mode with a reviewed Titan Map, booking fallback, and support runbooks.

Do not say: Your site is integrated with ServiceTitan.

A future sync or export handoff fails.

Say: The request is preserved and the manual fallback is active while we review the handoff.

Do not say: The booking was created in ServiceTitan.

A proof packet has uncertain revenue matches.

Say: Uncertain records are labeled needs-review and excluded from revenue totals until confirmed.

Do not say: All reported revenue is closed-loop ServiceTitan revenue.

API-gated support work

  • - OAuth token refresh, revocation, and encrypted token deletion.
  • - Webhook signature verification, replay windows, and idempotent event storage.
  • - Persisted worker retry queues with external ServiceTitan IDs.
  • - Sandbox validation evidence for imports, writes, reconnects, and disconnects.

Support disclaimers

  • - PageToJob is not affiliated with or endorsed by ServiceTitan.
  • - ServiceTitan is a trademark of its respective owner.
  • - This support center describes a manual pilot product and does not claim marketplace approval, live tenant access, or granted scopes.
  • - API-backed support runbooks require customer authorization, eligible ServiceTitan products/modules, approved app access, secure token storage, and sandbox validation.