Name the ServiceTitan admin
Owner: ServiceTitan admin
Future API work needs an admin who can confirm tenant eligibility, modules, scopes, app review, and authorization.
Access checklist
A customer-safe checklist for confirming admin contacts, modules, acceptable manual artifacts, and future authorization gates without collecting ServiceTitan credentials before approved access exists.
Owner: ServiceTitan admin
Future API work needs an admin who can confirm tenant eligibility, modules, scopes, app review, and authorization.
Owner: Operations
Scheduling Pro, Marketing Pro, pricebook, memberships, dispatch, and accounting availability determines which claims are manual-now versus future API-gated.
Owner: Shared
The website needs a safe conversion path whether the customer uses Scheduling Pro, phone-first CTAs, or PageToJob's request fallback.
Owner: Shared
The first pilot can run from redacted exports, screenshots, and review notes while API access remains gated.
Owner: PageToJob
The product should request only the access needed for purchased features after partner and customer approval.
Owner: PageToJob
Marketplace, app key, sandbox, webhook, and scope details must come from the actual ServiceTitan approval path.
Manual use: Install or align existing scheduler embeds when the customer already has them.
Future API use: Webhook and scheduler event handling after app approval, signature validation, replay protection, and sandbox proof.
Manual use: Create UTM/source plans and campaign landing pages from customer-provided campaign references.
Future API use: Read approved campaign and attribution data for campaign revenue proof where licensed.
Manual use: Map offer and service pages to customer-reviewed pricebook intent without exposing sensitive pricing details publicly.
Future API use: Read services/categories for drift checks and offer alignment. Writes stay approval-gated.
Manual use: Build maintenance plan and recurring-service pages from approved membership offers.
Future API use: Read eligible membership and recurring-service data for reactivation or tune-up campaigns.
Manual use: Use customer-reviewed zones, ZIPs, cities, and capacity notes for service-area pages and CTA rules.
Future API use: Read dispatch/zone data for drift monitoring and capacity-aware CTA checks where scoped.
Manual use: Use supplied aggregate reports or redacted exports for proof packets with visible match-quality labels.
Future API use: Read approved invoice/payment outcome data for closed-loop revenue attribution where authorized.
Outcome: Confirm admin contact, modules, booking path, pilot package, and first manual artifacts.
Outcome: Record which redacted exports, screenshots, or notes can be used for Titan Map, launch packet, drift report, and outcome proof.
Outcome: Separate manual-ready features from module-dependent and API-gated features.
Outcome: Identify the later authorization path, minimum scopes, sandbox evidence, support owner, and disconnect/deletion requirements.
The offline product is designed to sell and deliver value before approved app access exists.
Sales copy must stay aligned with actual authorization, scopes, sandbox validation, and customer eligibility.
The partner product should be narrower than the roadmap and defensible in security review.
The website should not stop converting visitors because ServiceTitan access is unavailable.