Shared Product Blueprint

Consulting Client Intake

A read-only Product Blueprint created with IdeaMade.

Client intake and submission review app

Consulting Client Intake

A public request form where prospective clients submit their details and needs without signing in, plus a private area where the consultant reviews submissions, tracks status, adds internal notes and records status history.

Users and roles

The people who interact with the product.

Visitor

A prospective client who is not signed in and submits a request through the public form.

  • Submit a request with contact details and a description of the need
  • Choose a service type and preferred start period

Consultant

The practice owner who signs in and manages all submissions.

  • Review incoming submissions
  • Move submissions through statuses
  • Add internal notes and decline reasons

Key workflows

The main paths users take to reach an outcome.

Submit a requestVisitorCore
1

Open the request formThe visitor opens the public form without signing in.

2

Fill in and submitThe visitor selects a service type, completes the fields required for it, and submits.

Outcome: A new submission is created with status New and appears in the consultant's list.
Review and decide on a submissionConsultantCore
1

Sign inThe consultant signs in to reach the internal area.

2

Review the listThe consultant scans submissions, filters by status and notices duplicate-email flags.

3

Open a submissionThe consultant reads the original answers and status history and adds internal notes.

4

Change statusThe consultant moves the submission to accepted or declined, supplying a decline reason when declining.

Outcome: The submission is accepted or declined, with notes and a full status history recorded.
Manage service typesConsultantSecondary
1

Open service typesThe consultant opens the service types page.

2

Edit a service typeThe consultant adds or updates a service type and its required fields.

Outcome: Service types and their required fields are up to date for the public form.

Pages

5 pages in the MVP

Request formPublic, no-sign-in form where a visitor enters name, email, company, service type, description of the need and preferred start period, then submits. Required fields adjust to the selected service type.
Public
Request form
Sign inLets the consultant sign in to reach the internal review area.
Public
Sign in
SubmissionsInternal list of all submissions with name, service type, status and submitted date, filterable by status, with duplicate-email flags.
Signed in
Submissions
NameEmailCompanyService type
Submission detailShows a submission's original answers, status, internal notes, decline reason and status history; the consultant changes status and adds notes here.
Signed in
Submission detail
Service typesInternal page where the consultant maintains service types and which request form fields are required for each.
Signed in
Service types

Product decisions

Choices you can confirm directly in the Blueprint.

How should the required fields for each service type be defined and applied?ConfirmedHow should the required fields for each service type be defined and applied?
Base fields always required
Which status transitions should the consultant be allowed to make?ConfirmedWhich status transitions should the consultant be allowed to make?
Any status to any status

Assumptions

Items that should be verified before implementation.

Name, email, company, description and preferred start period are always required; the selected service type adds extra required fields.

Medium impactAccepted

The consultant can move a submission to any status at any time, with Declined always requiring a decline reason.

Medium impactAccepted

Only one consultant account exists; multi-consultant access is out of scope for the first version.

Low impactAccepted