Keep the conversation at capability level
Discuss what the business needs before deciding how it should be implemented.
Founder alignment workspace v0.2
Hands and WorkPulse should become one business conversation.
This workspace helps both founders align on why Hands exists, what WorkPulse already provides, what must be extended, and what should be built first.
Overview
A discussion workspace, not product documentation
Create enough shared understanding to decide what Hands is, what WorkPulse remains, and what engineering should build first.
Business VisionAligned
Current WorkPulseAligned
Hands RequirementsDiscuss
Build MapDiscuss
MVPOpen
RoadmapOpen
DecisionsDiscuss
Discussion
Do both founders agree that Hands should create demand while WorkPulse protects operational truth?
Decision
Use this workspace to turn open points into explicit founder decisions.
Business Vision
Hands is a new revenue channel for SAS
Summarise why Hands exists and how it relates to SAS without restating the full original vision.
Hands gives SAS a consumer brand, a customer acquisition engine and a repeat relationship beyond enterprise field service work.
SAS already has operational depth through WorkPulse. The next opportunity is turning that delivery strength into consumer demand.
Hands can support booking, repeat services, membership, promotions, marketplace supply and future category expansion.
Build Hands as the business layer over SAS fulfilment
Hands should own the consumer promise. WorkPulse should continue to coordinate the service outcome.
Discussion
What is the first promise Hands should make to consumers: convenience, reliability, guaranteed outcome, membership value or all of the above?
Decision
Define the first consumer promise before expanding the product scope.
Current WorkPulse
WorkPulse already holds the operating foundation
Answer the question: what do we already have?
Customer Operations
- Clients
- Properties
- Requests
- Quotes
- Enterprise Portal
- Notifications
Fulfilment
- Jobs
- Visits
- Staff & Teams
- Scheduling
- GPS Tracking
- Service Reports
Finance
- Invoices
- Payments
- Quote Approvals
- Completion Records
- Commercial History
Platform
- Products & Services
- Permissions
- Company Management
- Operational Records
- Internal Controls
Reuse existing capabilities wherever practical
WorkPulse should be extended when the underlying capability already exists, instead of rebuilding the same operational behavior inside Hands.
Discussion
Which existing WorkPulse capabilities are strong enough for MVP, and which ones need a cleaner consumer-facing layer first?
Decision
Agree which capabilities are reused, extended or kept manual for launch.
Hands Requirements
Hands needs a clear set of capabilities before ownership is debated
Answer the question: what does Hands need?
Customer Login
Customer Dashboard
Booking
Tracking
Vendor Portal
Settlement
Voucher
Membership
Guarantee
Support
Promotions
Repeat Booking
Separate capability discussion from ownership discussion
First agree what Hands must enable. Then decide whether each capability belongs in Hands, WorkPulse or a shared layer.
Discussion
Which capabilities are needed for a real customer launch, and which are only needed once Hands becomes a marketplace?
Decision
Create one shared MVP capability list before engineering begins.
Build Map
The practical split: reuse, extend, build new or keep in Hands
Organise the product into capability groups that founders can discuss and reorder.
Existing WorkPulse
Capabilities already available and useful for Hands if exposed through the right customer experience.
Requests
Agreed- Recommendation
- Reuse the current request foundation.
- Reason
- It already starts the operational service flow.
- Suggested Phase
- MVP
Jobs & Visits
Agreed- Recommendation
- Keep fulfilment inside WorkPulse.
- Reason
- Field execution already depends on these records.
- Suggested Phase
- MVP
Scheduling
Under Discussion- Recommendation
- Reuse the assignment workflow.
- Reason
- The first launch needs reliable coordination more than automation.
- Suggested Phase
- MVP
Extend WorkPulse
Capabilities that exist today but need clearer consumer-facing behavior or marketplace-ready rules.
Quotes & Approvals
Under Discussion- Recommendation
- Support fixed-price and approval-led journeys.
- Reason
- Hands needs simple buying while operations still handles exceptions.
- Suggested Phase
- MVP
Customer-Safe Status
Under Discussion- Recommendation
- Create a smaller set of customer-visible states.
- Reason
- Internal status detail should not leak into the customer experience.
- Suggested Phase
- MVP
Invoice & Payment Records
Under Discussion- Recommendation
- Keep the final commercial record tied to WorkPulse jobs.
- Reason
- The job outcome should remain connected to the money flow.
- Suggested Phase
- MVP
Build New
Capabilities that do not exist as a mature shared layer today and should be designed deliberately.
Commerce
Under Discussion- Recommendation
- Create a shared commercial layer around WorkPulse jobs.
- Reason
- Hands will need pricing, margin and payment behavior beyond enterprise operations.
- Suggested Phase
- Stage 3
Settlement & Ledger
Deferred- Recommendation
- Build after the MVP proves repeat demand.
- Reason
- Marketplace money movement should be accurate before it is automated.
- Suggested Phase
- Stage 2
Voucher & Pricing Engine
Deferred- Recommendation
- Design as shared capability, not only a Hands feature.
- Reason
- Promotions will affect revenue, settlement and future channels.
- Suggested Phase
- Stage 3
Hands
Capabilities owned entirely by Hands because they define the consumer brand and relationship.
Consumer Brand Experience
Agreed- Recommendation
- Build inside Hands.
- Reason
- Hands should own discovery, trust and repeat purchase.
- Suggested Phase
- MVP
Customer Account
Under Discussion- Recommendation
- Create a simple customer profile and saved-address experience.
- Reason
- The relationship begins before the operational job exists.
- Suggested Phase
- MVP
Membership
Deferred- Recommendation
- Plan now, launch after the first buying loop is stable.
- Reason
- Membership only works once fulfilment and repeat value are clear.
- Suggested Phase
- Stage 3
Hands MVP
The MVP should be discussed as a customer journey
Follow the first buying loop from landing through completion.
01Landing
- Hands Responsibility
- Explain the service promise and convert interest into intent.
- WorkPulse Responsibility
- No direct responsibility at this step.
- New Capability Required
- Consumer pages, service catalogue and campaign routing.
- Discussion Notes
- Decide which services are simple enough for the first public launch.
02Register
- Hands Responsibility
- Create a customer identity, profile and saved address.
- WorkPulse Responsibility
- Receive the operational customer or property record when needed.
- New Capability Required
- Customer login and profile management.
- Discussion Notes
- Keep the profile simple until repeat purchase behavior is proven.
03Booking
- Hands Responsibility
- Capture service, address, photos, preferred timing and customer notes.
- WorkPulse Responsibility
- Create or link the request that starts fulfilment.
- New Capability Required
- Consumer booking flow and WorkPulse intake mapping.
- Discussion Notes
- MVP can support a narrow service set to reduce operational ambiguity.
04Confirmation
- Hands Responsibility
- Show clear next steps, price expectation and booking status.
- WorkPulse Responsibility
- Confirm quote, job or approval path.
- New Capability Required
- Customer-safe confirmation states.
- Discussion Notes
- Discuss whether the MVP uses fixed price, quote approval or both.
05Assignment
- Hands Responsibility
- Keep the customer informed without exposing internal details.
- WorkPulse Responsibility
- Assign staff, team or vendor and schedule the visit.
- New Capability Required
- Customer-safe assignment updates.
- Discussion Notes
- Manual assignment is acceptable if the status trail is clean.
06Tracking
- Hands Responsibility
- Display status, appointment timing and support access.
- WorkPulse Responsibility
- Maintain operational status, GPS and visit progress.
- New Capability Required
- Simplified tracking layer.
- Discussion Notes
- Tracking should build trust, not overwhelm the customer.
07Completion
- Hands Responsibility
- Collect payment, feedback, support needs and rebooking intent.
- WorkPulse Responsibility
- Close the job, store report, invoice and payment record.
- New Capability Required
- Checkout, completion and post-service loop.
- Discussion Notes
- This is where repeat purchase and membership signals begin.
Launch the smallest complete service loop
The MVP should prove that a consumer can discover, book, receive updates, complete a service and return for the next one.
Discussion
What can stay manual behind the scenes without weakening the customer promise?
Decision
Protect the customer journey while keeping operational automation phased.
Roadmap
Build the business in stages
Keep the sequence business-first so stages can be reordered as the founders align.
Launch Hands MVP
- Goal
- Prove that Hands can create consumer demand and complete the first service loop.
- Capabilities
- Landing, account, booking, request intake, assignment, tracking, completion.
- Business Value
- New customer acquisition without rebuilding the operating core.
Marketplace Operations
- Goal
- Make vendor participation and fulfilment controls more repeatable.
- Capabilities
- Vendor eligibility, assignment rules, quality controls, support workflow.
- Business Value
- Broader supply, better consistency and less manual coordination.
Commerce
- Goal
- Introduce stronger money, margin and incentive capabilities.
- Capabilities
- Pricing, vouchers, ledger, settlement, wallet, membership.
- Business Value
- New revenue mechanics and a clearer path to marketplace economics.
Scale
- Goal
- Expand channels, categories and partner opportunities.
- Capabilities
- More categories, partner demand, automation, performance loops.
- Business Value
- Hands becomes a growth engine while WorkPulse becomes the shared service platform.
Decisions
Important discussions should become explicit decisions
Track the founder calls that shape what engineering builds first.
Hands Product Role
Agreed- Recommendation
- Hands should be the consumer brand and acquisition product.
- Phase
- MVP
- Reason
- It creates demand and owns the customer relationship.
- Discussion
- Confirm the first customer promise and the service categories included.
WorkPulse Product Role
Agreed- Recommendation
- WorkPulse should remain the operating core.
- Phase
- MVP
- Reason
- It already coordinates the real-world service transaction.
- Discussion
- Agree where WorkPulse must become more consumer-ready.
MVP Scope
Under Discussion- Recommendation
- Launch with a narrow journey that proves booking through completion.
- Phase
- MVP
- Reason
- A focused launch gives faster learning and avoids premature marketplace complexity.
- Discussion
- Choose the minimum service set and what can remain manual.
Membership
Deferred- Recommendation
- Design for membership, but do not block MVP launch on it.
- Phase
- Stage 3
- Reason
- Membership depends on repeat value and fulfilment confidence.
- Discussion
- Define what members receive and when the offer becomes meaningful.
Marketplace Finance
Proposed- Recommendation
- Treat settlement, ledger and payouts as new shared capabilities.
- Phase
- Stage 2
- Reason
- Money movement affects Hands, WorkPulse, vendors and SAS margin.
- Discussion
- Decide which finance workflows are manual at launch.
Context
Supporting material belongs here
Keep references available without turning the workspace into documentation.
Original Business Vision
Placeholder for reference material, notes and source context.
Current WorkPulse
Placeholder for reference material, notes and source context.
Current Admin Panel
Placeholder for reference material, notes and source context.
Competitor Notes
Placeholder for reference material, notes and source context.
Legacy Context
Placeholder for reference material, notes and source context.
Glossary
Shared language keeps the discussion moving
Use concise definitions for terms that can otherwise mean different things to different people.
Marketplace
A service model where demand, supply, fulfilment and money flow are coordinated across multiple parties.
Commerce
The pricing, checkout, margin and payment behavior around a service transaction.
Capability
A business function the company needs, independent of where it is implemented.
Settlement
The process of calculating what each party is owed after a job is completed.
Guarantee
The promise SAS or Hands makes to give customers confidence in the service outcome.
Membership
A repeat relationship model that may include benefits, priority, savings or bundled value.
Vendor
A fulfilment partner or service provider in the SAS network.
Hands
The consumer-facing brand and product for demand, trust and repeat purchase.
WorkPulse
The operating platform that coordinates service delivery and operational records.
Fulfilment
The work required to assign, perform, complete and verify a service.
Customer Relationship
The ongoing connection between Hands and the person buying or rebooking services.