Archetype Owner Positioning

Status: Draft - 2026-07-18
Scope: Owner-facing marketing opportunity, visual direction, and test-priority translation for the current 95 archetypes across 21 categories.
Related: Market Archetypes And Coworkers, Archetype Owner Quick Guide, Archetype Business Value Streams, Archetype Audit Plan, Customer Marketing Workspace Design

1. Positioning Thesis

DPF should speak first to the owner who is also doing the work: the plumber still answering calls, the clinic owner still handling forms, the salon owner still filling gaps in the schedule, the venue owner still chasing deposits, the nonprofit director still writing donor updates after dinner.

The promise is not “AI for small business” in the abstract. The promise is:

Keep doing the work customers pay you for. Give the work around the work to governed AI coworkers.

The broader market thesis is now:

Integrate at the edge. Simplify in the core. Generalize for the ecosystem.

DPF should meet owners where they are: QuickBooks for accounting, Stripe or Square for payments, Gusto or ADP for payroll, HubSpot or Salesforce for CRM, Zendesk or Jira Service Management for tickets, Slack or Microsoft 365 for communication, Shopify or POS systems for commerce, and vertical tools where regulation or specialization demands them. Those systems are bridges and benchmarks, not the final architecture. When a workflow is broadly useful across companies, DPF should absorb it into native company primitives so the next owner does not inherit the same brittle software stack.

The “work around the work” is the necessary-evil layer that steals owner time:

• capturing enough information to quote, book, dispatch, or qualify the work
• following up when a customer, patient, donor, resident, or client goes quiet
• keeping schedules, crews, assets, inventory, rooms, or service capacity from colliding
• drafting campaign ideas, proof assets, local content, reminders, and customer updates
• surfacing compliance, licensing, disclosure, or safety prompts before the owner promises the wrong thing
• turning inbox, portal, finance, customer, and operations data into a daily owner cockpit

This document turns the archetype catalog into two usable artifacts:

1. Marketing positioning: why DPF matters to the owner of each business type.
2. Testing emphasis: which owner promise must be verified before that positioning is safe to use.

2. Current State vs Planned Complete State

DPF should separate what can be marketed as available today from what belongs in planned-state positioning.

3. Owner Promise Diagram

flowchart LR
  A["Owner doing core work"] --> B["Necessary-evil jobs"]
  B --> C["Intake and follow-up"]
  B --> D["Scheduling, capacity, assets"]
  B --> E["Marketing and proof"]
  B --> F["Finance and compliance prompts"]
  C --> G["Governed AI coworkers"]
  D --> G
  E --> G
  F --> G
  G --> H["Owner cockpit"]
  H --> I["More time for customers, crew, and judgment"]
  H --> J["Testable promises per archetype"]

Use this diagram in internal strategy decks. For customer-facing collateral, replace it with photography or UI captures showing the owner moment: an after-hours inbox, a full schedule, a dispatch board, a donor campaign draft, a rental return queue, or a venue calendar.

4. Category Positioning Matrix

Each row names the business-specific reason DPF should matter, the visual story marketing can tell, and the highest-value use case the archetype audit should prove. Rows are source categories unless labelled as a spotlight; IT managed services is a required professional-services leaf spotlight, not a separate category in the canonical 95 / 21 inventory.

5. Marketing Assets And Proof Guidance

Owner-facing collateral should show a real burden being removed. Avoid generic AI imagery and vague productivity claims.

Use these asset patterns:

• Hero image: the owner at the worksite, front desk, shop counter, studio, van, venue, or yard with the DPF cockpit visible as a practical tool.
• Workflow diagram: core job in the center, surrounding admin jobs around it, AI coworkers attached to the admin jobs, owner judgment retained for approvals.
• Before/after storyboard: “5:45 PM after the last appointment” vs “tomorrow’s readiness board is already prepared.”
• Use-case close-up: one archetype-specific screen or diagram, such as emergency plumbing triage, dental missing forms, donor thank-you follow-up, builder draw milestone, rental return inspection, or venue date-hold conflict.
• Proof strip: what the customer can inspect: vocabulary fit, CTA fit, saved admin steps, coworker draft, compliance prompt, audit trail, and approval boundary.

Copy should use the operator’s language before platform language:

• trades: jobs, call-outs, quotes, techs, parts, emergency, planned maintenance
• clinics: patients, appointments, forms, practitioners, records, follow-ups
• retail: stock, orders, deliveries, returns, merchandising, repeat buyers
• nonprofits: donors, supporters, volunteers, beneficiaries, programs, receipts
• venues: dates, holds, rooms, packages, guests, access needs, settlement
• rental: reservations, assets, return, inspection, damage, availability, utilization

6. Test Translation Rules

Marketing promises become audit requirements when they touch one of these surfaces:

1. Vocabulary proof: the portal, coworker, inbox, workspace, and finance language must use the archetype’s business terms.
2. CTA proof: the public action must match the business model: book, buy, inquire, donate, apply, or reserve.
3. Burden proof: the promised necessary-evil job must be represented by real fields, states, tasks, drafts, reminders, or coworker responses.
4. Trust proof: regulated, licensed, financial, clinical, civic, and safety-sensitive claims must include the right boundary and refusal behavior.
5. Owner cockpit proof: the workspace/twin must surface the owner-relevant exception, not just generic CRM data.
6. Growth proof: marketing suggestions must reflect archetype, locality, route to market, proof assets, and capacity constraints.

If a claim cannot be tied to one of those proofs, treat it as planned-state copy, not current-state marketing.

7. Guardrails

• Do not say DPF replaces a licensed professional, clinical system, legal advisor, core banking system, official public-safety data system, full ticketing platform, payment rail, payroll system, or accounting ledger.
• Do not describe AI coworkers as autonomous publishers unless the publish_marketing approval path exists and the action is explicitly approved.
• Do not flatten every business into “customers” and “products”; use the archetype’s vocabulary.
• Do not lead with Build Studio for small-business customers. Lead with the owner, the business type, and the work they are trying to protect.
• Do not use market-size or ROI numbers in collateral unless they come from a cited, current source and are specific to the geography and archetype.

8. Documentation Maintenance Rule

When adding or changing an archetype, update this document if the change alters any of the following:

• owner-practitioner reality
• promised burden reduction
• image or diagram story
• test emphasis
• current-state vs planned-state boundary

The archetype seed remains executable truth. This document is the positioning and testing interpretation layer.