Customer handoff packet

ServiceTitan-ready customer handoff packet.

A single onboarding packet that connects the pilot flow, proposal, intake, access checklist, security review, Titan Map audit, implementation plan, support path, and launch proof without asking for ServiceTitan credentials or claiming live API access.

Give the buyer one place to see what happens after a pilot is accepted, what PageToJob needs, which roles own each review, and what evidence must be attached before launch or future API work.
Packet summary
9
artifacts
5
milestones
4
controls
4
ready now
5
customer/review
7
signoffs
No ServiceTitan credentials, app keys, tokens, client secrets, tenant secrets, or admin logins are requested or accepted in this handoff.

Handoff artifacts

Owner: Owner

Buyer pilot flow

ready now

Shows the buyer path from audit through demo, package choice, proposal, intake, access checklist, and launch proof.

Customer: Confirm the preferred pilot path and first pages, campaigns, or service areas to map.

PageToJob: Use the selected path to keep sales, onboarding, and launch artifacts aligned.

Evidence to attach
Selected pilot laneDecision gate ownerFirst mapped pages or campaigns
Open artifact
Owner: Owner

Pilot proposal packet

review required

Defines fixed-scope pilot terms, customer responsibilities, exclusions, and acceptance gates.

Customer: Approve scope, term, package, exclusions, and launch acceptance criteria.

PageToJob: Translate accepted terms into onboarding tasks and launch proof requirements.

Evidence to attach
Accepted packageScope exclusionsLaunch acceptance gates
Open artifact
Owner: Shared

Customer intake packet

customer input

Collects operating context, artifact requests, redaction rules, and manual mapping questions.

Customer: Provide reviewed service, zone, campaign, offer, membership, and booking-path inputs.

PageToJob: Convert approved inputs into Titan Map candidates and website requirements.

Evidence to attach
Reviewed intake answersRedacted screenshots or exportsNamed review owners
Open artifact
Owner: ServiceTitan admin

ServiceTitan access checklist

customer input

Names admin contacts, module checks, artifact sources, no-credential boundaries, and future authorization gates.

Customer: Name the ServiceTitan admin and confirm which modules, reports, exports, or screenshots can be reviewed.

PageToJob: Keep manual artifacts separate from any future tenant authorization or API scope request.

Evidence to attach
ServiceTitan admin contactModule inventoryApproved artifact sources
Open artifact
Owner: Shared

Security, privacy, and consent packet

review required

Sets credential, data retention, deletion, consent, and API-gated claim boundaries.

Customer: Acknowledge redaction, no-credential mode, and the difference between manual artifacts and API authorization.

PageToJob: Keep sales, onboarding, launch, and support language inside approved claim boundaries.

Evidence to attach
No-credential acknowledgementRedaction agreementData owner approval
Open artifact
Owner: Operations

Manual Titan Map audit packet

ready now

Turns customer artifacts into repeatable mapping checks, drift findings, scoring prompts, and signoff gates.

Customer: Review findings and confirm whether pages, zones, campaigns, and offers match the operating model.

PageToJob: Attach findings to the build plan and separate launch blockers from follow-up fixes.

Evidence to attach
Artifact logFinding templatesCustomer signoff
Open artifact
Owner: PageToJob

Implementation playbook

ready now

Shows delivery phases, review gates, retention policy, support promises, and no-API operating rules.

Customer: Confirm launch owner, review cadence, and what artifacts can be retained for proof.

PageToJob: Run the manual build, QA, launch proof, and review process against the approved scope.

Evidence to attach
Implementation phase ownerReview datesRetention preference
Open artifact
Owner: Shared

Support center and incident runbooks

ready now

Defines the support path for failed handoffs, drift conflicts, booking outages, privacy requests, and revenue disputes.

Customer: Name the escalation contact and approve support language for manual-mode incidents.

PageToJob: Use runbooks to respond without over-claiming ServiceTitan access or automation.

Evidence to attach
Escalation contactIncident communication ownerSupport SLA expectation
Open artifact
Owner: Shared

Launch packet

review required

Collects final website coverage, booking path, drift baseline, API boundary, and launch proof.

Customer: Approve launch proof, unresolved risks, and the first 30-day review date.

PageToJob: Package launch evidence and schedule the first monthly proof review.

Evidence to attach
Launch proofKnown risks30-day review date
Open artifact

Delivery milestones

After proposal acceptance - PageToJob

Sales handoff

Entry criteria
  • - Pilot package selected
  • - Scope and exclusions approved
  • - Buyer owner named
Exit criteria
  • - Onboarding packet sent
  • - Customer review owners named
  • - No-credential boundary acknowledged
Before Titan Map build - Shared

Onboarding complete

Entry criteria
  • - Intake started
  • - ServiceTitan admin named
  • - Artifact sources identified
Exit criteria
  • - Redacted artifacts approved
  • - Module inventory reviewed
  • - Security packet acknowledged
Before website build lock - Operations

Audit and Titan Map review

Entry criteria
  • - Artifacts collected
  • - Services, zones, campaigns, and offers reviewed
  • - Booking path known
Exit criteria
  • - Mapping gaps documented
  • - Launch blockers separated
  • - Customer signs off on manual Titan Map
Before public launch - Shared

Build and launch review

Entry criteria
  • - Implementation playbook accepted
  • - Support owner named
  • - Launch proof requirements set
Exit criteria
  • - Launch packet approved
  • - Support path live
  • - Known API-gated claims remain blocked
30 days after launch - Owner

30-day proof review

Entry criteria
  • - Website launched
  • - Manual booking and campaign context reviewed
  • - Drift baseline captured
Exit criteria
  • - Findings reviewed
  • - Renewal or next-scope decision made
  • - API-gated roadmap updated if relevant

Risk controls

No-credential boundary

Risk: A customer mistakes manual onboarding artifacts for ServiceTitan tenant authorization.

Control: The handoff packet points every buyer to the security packet and access checklist before any artifact review.

Open control

Pilot scope drift

Risk: The build expands beyond the accepted pilot package before the first launch proof review.

Control: The proposal, pilot flow, and implementation playbook define accepted scope, exclusions, and change review.

Open control

Bad or stale artifacts

Risk: The Titan Map is built from stale screenshots, incomplete exports, or unreviewed service/zone details.

Control: The intake packet, audit packet, and access checklist require named owners and artifact review before build lock.

Open control

Support ownership gap

Risk: A booking, drift, privacy, or attribution issue has no clear owner after launch.

Control: The support center names escalation paths and the launch packet captures customer-side owners.

Open control

Signoff checklist

  1. 1. Pilot scope, package, exclusions, and launch acceptance gates are approved.
  2. 2. Customer review owners are named for marketing, operations, ServiceTitan admin, launch, and support.
  3. 3. No ServiceTitan credentials, app keys, tokens, client secrets, or admin logins are requested or accepted.
  4. 4. Customer-supplied artifacts are redacted or explicitly approved before PageToJob review.
  5. 5. Titan Map reviewer signs off on services, zones, campaigns, offers, memberships, and booking path.
  6. 6. Implementation, support, and launch packet owners agree on known risks and API-gated claims.
  7. 7. The 30-day proof review owner and date are set before launch.

Handoff disclaimers

  • - PageToJob is not affiliated with or endorsed by ServiceTitan.
  • - ServiceTitan is a trademark of its respective owner.
  • - This handoff packet does not grant ServiceTitan tenant access, collect credentials, create app approval, or authorize API calls.
  • - Future API-backed features require customer authorization, eligible ServiceTitan products/modules, granted scopes, approved app access, secure storage, and sandbox validation.