Canonical intake, built out into concrete steps, fields, branches, and flags.
This page turns Phase B into a reviewable build artifact. It shows the real intake structure that should sit between the public funnel and the future TCM, including what is required, what branches conditionally, and which answers should trigger review flags or pricing-lane outputs.
Canonical steps
11
Review flags
9
Recommendation outputs
4
Decision questions for Ryan
8
Step 1
Welcome + protection type
Orient the client, reduce anxiety, and identify the broad mark type before deeper intake begins.
2 fields
• Keep copy plain-English and reassuring.
• This step should feel fast and confidence-building for ad traffic.
What would you like to protect?
welcome.protectionType
Single choiceRequired
Brand nameLogoName and logoNot sure yet
Is this for a U.S. trademark application?
welcome.usApplicationIntent
Single choiceRequired
YesProbably yes, but I have questionsNot sure
Step 2
Owner / applicant
Identify the legal owner correctly and surface ownership complexity early.
11 fields
• If the filer is acting for an organization, collect authorized representative details and a power of attorney document authorizing representation.
Who should legally own this trademark?
owner.ownerType
Single choiceRequired
Me personallyMy LLCMy corporationMy partnershipAnother business or nonprofitNot sure
Legal owner name
owner.legalName
Short textRequired
Different DBA or brand name, if any
owner.dbaName
Short textOptional
State or country of organization
owner.stateOrCountryOfOrganization
Short textRequired
Branching
• depends on owner.ownerType (Show for business owners instead of individual citizenship.)
Country of citizenship
owner.citizenship
Short textRequired
Branching
• depends on owner.ownerType = Me personally
Are there multiple owners?
owner.hasMultipleOwners
Single choiceRequired
YesNo
Authorized representative name
owner.authorizedRepresentativeName
Short textOptional
Use when the person filling out the intake is authorized to act for the owner organization.
Authorized representative title or role
owner.authorizedRepresentativeTitle
Short textOptional
Additional owner entries
owner.additionalOwners
Generated / repeating summaryOptionalRepeatable
For now, capture detailed additional-owner information plus authorized-representative context when someone is signing on behalf of the organization.
Branching
• depends on owner.hasMultipleOwners = Yes
Review flags
ownershipComplexity
Is there anything unusual about the ownership?
owner.unusualOwnership
Single choiceRequired
YesNo
Review flags
ownershipComplexityneedsAttorneyReview
Explain the ownership issue
owner.unusualOwnershipExplanation
Long textRequired
Branching
• depends on owner.unusualOwnership = Yes
Step 3
Contact + address
Capture the filer/contact person and the mailing details needed for downstream prep.
5 fields
Best contact name
contact.contactName
Short textRequired
Best email
contact.email
EmailRequired
Best phone number
contact.phone
PhoneRequired
Your role in relation to the owner
contact.role
DropdownOptional
OwnerEmployeeAssistantAttorneyOther
Mailing address
owner.mailingAddress
Address blockRequired
Collect line 1, line 2, city, state/province, postal code, and country.
Step 4
Mark details
Capture what the mark is and identify any special statements needed later.
11 fields
• Word mark protects the wording itself. Design/logo mark protects the visual presentation.
What are you trying to protect?
mark.markFormat
Single choiceRequired
Just the words or nameJust the logo or designA logo that includes wordsNot sure
Enter the exact wording
mark.exactWording
Short textRequired
Branching
• depends on mark.markFormat (Show whenever wording is part of the mark.)
Briefly describe the logo or design
mark.designDescription
Long textRequired
Branching
• depends on mark.markFormat (Show for design or combined marks.)
Review flags
markDescriptionNeeded
Does the mark use color you want to claim?
mark.colorClaimed
Single choiceRequired
YesNoNot sure
Branching
• depends on mark.markFormat (Show for design or combined marks.)
Color description
mark.colorDescription
Short textRequired
Branching
• depends on mark.colorClaimed = Yes
Does the mark include non-English wording?
mark.hasNonEnglishWording
Single choiceRequired
YesNoNot sure
Review flags
translationReviewNeeded
What does it mean?
mark.translationText
Short textRequired
Branching
• depends on mark.hasNonEnglishWording = Yes
Does the mark use a different alphabet or unusual script?
mark.hasTransliterationIssue
Single choiceRequired
YesNoNot sure
Review flags
translationReviewNeeded
Transliteration details
mark.transliterationText
Short textRequired
Branching
• depends on mark.hasTransliterationIssue = Yes
Does the mark include a person’s name, portrait, or signature?
mark.hasPersonNamePortraitSignature
Single choiceRequired
YesNoNot sure
Review flags
needsAttorneyReview
Upload logo or design file
uploads.logoFiles
File uploadOptional
Branching
• depends on mark.markFormat (Show for design or combined marks.)
Step 5
Goods / services
Collect a lighter first-pass description of goods and services, with the eventual build moving toward USPTO-style classes and description structure.
11 fields
• Ryan selected a lighter first-pass intake here.
• The eventual implementation should still follow the structure of USPTO classes and descriptions rather than staying purely freeform forever.
• Preferred direction: use a guided plain-English narrowing flow that helps the client land on likely class families and identifications before final internal selection.
• Taxonomy direction: start with common category families and subcategories plus Other, then expand as real intake patterns emerge.
In plain English, what does your business do?
goodsServices.businessDescription
Long textRequired
Which best fits what you offer?
goodsServices.offerType
Single choiceRequired
Products or goodsServicesBothNot sure
Is this a good or a service?
goodsServices.offerKind
Single choiceRequired
GoodServiceBothNot sure
What type of good or service is it?
goodsServices.categoryFamily
DropdownRequired
Start with a curated set of the most common plain-English families, plus an Other option, and expand the taxonomy over time.
More specific category
goodsServices.subcategory
DropdownRequired
Use a hybrid taxonomy: common narrower categories first, plus Other / not sure, with room to expand over time.
Primary product or service #1
goodsServices.primaryOfferingOne
Short textRequired
Primary product or service #2
goodsServices.primaryOfferingTwo
Short textOptional
Closest USPTO class or description, if known
goodsServices.usptoClassHint
Short textOptional
Future implementation should evolve toward USPTO class-aligned selection and description support, using the guided answers to narrow likely classes and IDs.
Provide a clear next action while preserving the intake record for downstream review and future TCM ingestion.
3 fields
• Save-and-finish-later is desired, but not required for the first working version.
Continue to consultation
handoff.continueToConsultation
Generated / repeating summaryRequired
Save and finish later
handoff.saveAndFinishLater
Generated / repeating summaryRequired
Request attorney review
handoff.requestAttorneyReview
Generated / repeating summaryOptional
Decision questions to answer before implementation
Question 1
When should pricing appear in the intake flow?
This controls whether the funnel feels more consultative or more self-serve, and changes the recommendation screen design.
A. After the landing page but before the detailed intake
Adds early transparency, but may reduce consult-first momentum.
B. Only after the recommendation screen
Best matches consult-first positioning and service-lane triage.
Selected
C. Show a range early, then precise lane later
Balanced option with softer sticker shock.
Chosen: pricing appears only after the recommendation screen.
Recommended leaning: B or C are the strongest fits for the direction you approved.
Question 2
Should foreign applicants stay in the same intake flow or branch earlier?
This changes how much of the intake can stay shared and when attorney-review cues appear.
A. Keep them in the same flow, branch only when foreign answers appear
Simplest UX and easiest to maintain.
B. Split them into a dedicated foreign review lane as soon as foreign filing is detected
Cleaner internal routing for complex matters.
C. Keep shared intake, but change the recommendation/handoff aggressively for foreign matters
Good middle ground.
Selected
Chosen: keep a shared intake, but route foreign matters to a meaningfully different recommendation and handoff.
Recommended leaning: C is probably the best balance unless you want a visibly separate foreign product lane.
Question 3
How much detail should we collect for multiple owners during intake?
More detail up front reduces follow-up later, but increases intake friction for edge cases.
A. Collect full owner details for every additional owner during intake
Most complete, but heavier UX.
B. Collect only legal name and type for additional owners, fill in the rest later
Faster intake, more internal follow-up.
C. Collect a short summary first, then open a detailed sub-step only if needed
Best adaptive UX.
Resolved custom direction: collect authorized representative details and a power of attorney document when someone is acting on behalf of the organization.
Recommended leaning: C feels strongest for this funnel.
Question 4
How deep should the goods/services section go on first pass?
This is one of the biggest tradeoffs between conversion and filing readiness.
A. One plain-English business description plus 1 to 2 example offerings
Lightest intake, more follow-up later.
B. Require a repeatable offering list with descriptions and sold-now status
Best filing-prep quality, moderate effort.
C. Start light, then ask for more only if multiple classes or ambiguity appear
Adaptive and likely best for conversion.
Refined direction: use a guided plain-English funnel, for example good/service → broad family → narrower category → freeform description, then internally map to likely USPTO classes and identification candidates.
Recommended leaning: C is my default recommendation, with B for obviously serious/legal-intake traffic.
Question 5
When should first-use dates be required?
Dates are valuable, but forcing them too early can slow users who are unsure.
A. Require them immediately whenever the user says the mark is already live
Most complete intake.
B. Ask for them, but allow unknown / approximate answers at intake stage
Reduces abandonment while keeping the topic in scope.
Selected
C. Do not ask for dates until after review or consultation
Fastest UX, weakest filing-prep readiness.
Chosen: ask for dates, but allow approximate or unknown answers at intake stage.
Recommended leaning: B is probably the right compromise.
Question 6
How hard should we push uploads during intake?
Uploads improve review quality, but mandatory file collection can hurt completion rates.
A. Make relevant uploads required before submission
Higher-quality files, lower completion rate.
B. Strongly encourage uploads, but allow submission without them
Better conversion, still useful intake.
Selected
C. Skip uploads entirely at intake and request them later
Fastest intake, more manual follow-up.
Chosen: uploads are encouraged, not required.
Recommended leaning: B is the best default unless a specific lane requires hard evidence up front.
Question 7
How visible should legal-risk questions be to the client?
More visible legal questions can feel serious and careful, but can also spook ad traffic.
A. Keep them as a normal intake step
Most transparent and complete.
B. Collapse them behind optional or advanced wording
Softer UX, still collects edge cases.
Selected
C. Collect only the biggest red flags and leave the rest for internal follow-up
Higher conversion, less complete intake.
Chosen: legal-risk questions should feel softer or more advanced in the UI.
Recommended leaning: B probably fits the approved visual and tone best.
Question 8
How important is save-and-finish-later in the first build?
This changes both backend persistence and how much friction we can tolerate in the full intake.
A. Critical in v1 of the intake app
We should design persistence from the start.
B. Nice to have, but not required for the first working version
Lets us ship sooner.
Selected
C. Not needed if the intake stays short enough
Simplifies the first build heavily.
Chosen: save-and-finish-later is nice to have, not required for the first working version.
Recommended leaning: If the flow stays this thorough, A or B. If you want rapid implementation first, B.