The Solution Workshop guide
Learn how drafts, approvals, job records and payment evidence fit together, and which parts are still prototypes.
Capability review: September 17, 2026. Status applies to the specific action described.
The trade proof of concept organizes intake, job states and estimate revisions. A professional can prepare an estimate change and review it before treating it as customer-approved work. The demo uses fixtures; it is not a universal price book for every business.
A useful estimate identifies the scope, what is included, exclusions and the approval still needed. A typical range is guidance, not a firm quote. An uncertain repair may need diagnosis before a repair price can be agreed.
Receipt-photo drafts explore another part of this workflow: keep actual purchase cost separate from the customer price, select only the customer’s items and confirm any markup. A receipt alone does not authorize an invoice or charge.
The text-first POC demonstrates short commands for the schedule, active job, estimate and job status. Those controls show how a professional might move work forward without navigating a large application.
The playground is the best place to explore these stages with fictional work. Changes there are not instructions to a real crew.
Open the fictional Pipes playgroundA single-account Stripe Checkout proof of concept exists, with sandbox testing and signed payment-status handling when configured. A test payment is not revenue.
PLANNED
The tenant model is for each Pro to onboard their own Stripe Connect account. Tenant-specific Connect money movement is not implemented. No automatic payouts or connected account are created by selecting a tier.
Solution Workshop’s subscription is a separate charge for the platform. Subscription billing is not active. The service tiers are unpriced conversations about scope, not live checkout products.
The planned model may use a capped platform percentage on successful homeowner-to-Pro job payments, with lower percentages at higher subscription tiers. No amount, cap or active entitlement is established here.
Refunds, disputes, failed payments and reconciliation must have explicit handling before a payment workflow is called ready. Payment processing costs and platform charges also need to be explained separately.
An optional future customer-initiated checkout option may be available only when the payment provider and transaction are eligible. We do not promise financing, a customer credit limit or prequalification. Present the itemized repair or replacement estimate first; any payment-option exploration is a separate choice.
The target is tenant-scoped access: the right business, person and role for each action. Owners, dispatchers and technicians need different views. Public demos must not expose private customer records.
Server-side ownership checks exist in parts of the tenant workspace, but the older phone-keyed implementation is not a complete privacy guarantee. Broad conversational access to historical accounts remains unavailable until independent authorization and privacy tests are complete.
A carrier can give a retired number to a new person. If that person asks, “What address do you have for me?”, the assistant must not reveal or confirm the previous owner’s records. It can capture a new request without retrieving the old one.
A spouse’s arrival-contact number is also a limited contact instruction, not authority to inspect invoices, cancel work or recover an account. Contacts and permissions should be separate and revocable.
These questions stay useful as a prototype becomes a connected product. They also help identify the one step that needs to work before adding another integration.
