# Show who performs each design task and what it produces.

An in-house design page should identify who performs each design task, what the buyer receives and which approvals remain separate. Define employed capability, retained specialists and outside collaborators using verified records. Describe work by role and output. Keep credentials, technical review and permission to release drawings explicit rather than implied by a team label.

## What does in-house mean here?

Define the phrase before you describe its benefits. State which design tasks your employees perform and which tasks involve retained or outside roles. A buyer should be able to read the page without guessing whether the same team discusses ideas, produces drawings and authorizes their use.

Use your own verified service description. If employees coordinate selections while an outside collaborator prepares drawings, describe that arrangement. Do not expand a coordination role into a promise of complete design services. If the employment or collaboration scope is unknown, confirm it before publishing the claim.

The [FTC Truth In Advertising guidance](https://www.ftc.gov/news-events/topics/truth-advertising) says advertising must be truthful and non-misleading. Use that principle when reviewing an in-house design claim. The guidance does not establish your team's capabilities or require the responsibility map proposed here.

Give the page a clear place in your [builder sales process](/articles/sales-process/). It should help buyers understand the proposed working relationship before they interpret a service label as a project commitment. Detailed drawing revisions belong in the later design-phase record.

### How should you describe the working relationship?

Use separate descriptions for employed capability, retained specialists and outside collaborators. Employed capability describes the work your employees perform. Retained specialists describe a documented engagement for a stated task. Outside collaborators describe a separate contribution whose scope and approvals need confirmation. These are proposed editorial categories, not legal classifications.

Explain the relationship at the task level. One outside role might contribute only to a defined review. Another arrangement might cover a broader deliverable. Keep the public statement within the actual documented scope. Do not turn one project arrangement into a builder-wide promise.

## Which roles perform the work?

Map the work before writing team copy. Identify who receives the buyer's question, who prepares the output and who reviews it. Use role names your team already uses. Do not invent departments to make a small team appear larger.

| Task | Role question | Output to confirm | Boundary to record |
| --- | --- | --- | --- |
| Concept discussion | Who records the buyer's aims? | Discussion brief or agreed equivalent | Ideas remain separate from approved drawings |
| Drafting | Who prepares each drawing? | Named drawing issue and status | Preparation does not imply every required approval |
| Selections coordination | Who organizes the buyer's choices? | Selection record or comparison | Preference remains separate from release |
| Technical review | Which qualified role reviews the question? | Review record within that role's scope | Other technical and project reviews remain distinct |
| Release | Who authorizes the next use? | Release record linked to the current issue | Permission applies only to the stated next action |

The table is a set of discovery questions. It does not assert that your team performs every task. Remove an inapplicable service from your proposed public description. Keep the responsibility record for work that remains within your process.

A single role may own several tasks. State each task separately so buyers can understand the [handoff](/process/handoff/). Where two roles share a task, identify who handles the buyer's next question. Avoid a general instruction to “ask the design team” when no one owns the answer.

Do not treat the label “designer” as proof of an architectural license. Verify any credential claim with the relevant primary record before publishing it. Keep questions about licensing scope and technical responsibility with qualified review. This page does not establish a regulatory conclusion.

Use the [builder About page guide](/articles/builder-websites/builder-about-page/) for the broader team presentation. The design service page needs task boundaries and outputs rather than a repeated company history. Both pages should use matching role descriptions.

## What does the buyer receive?

Name the deliverable at each stage and explain its intended use. A discussion brief, a drawing issue and a selection comparison serve different purposes. Use the names in your actual process. Do not promise a particular document package until its scope has been confirmed.

Describe how a buyer recognizes the current version. Identify the status information your process uses, such as an issue label or revision reference. Explain where questions about that issue go. Leave the delivery schedule unknown until the responsible role confirms it.

Give each output a boundary. A concept record can capture direction while leaving technical questions open. A selection comparison can organize preferences while leaving purchasing authorization separate. A reviewed drawing can still require another named approval before its next use. Confirm those distinctions against the project process.

### How can you make deliverables understandable?

1. **Name the task.** Use the term the buyer will encounter in meetings.

2. **Identify the responsible role.** Confirm the work that role performs.

3. **Describe the output.** Explain what the buyer receives and its stated purpose.

4. **State the limit.** Identify the approval or review the output does not establish.

5. **Connect the next action.** Explain which role receives questions before the work advances.

For drawing examples, show the status in adjacent text. Use approved material with confirmed publication rights. Keep private project details out of the example. An illustrative drawing should never look like an issued document for the visitor's project.

For an informative illustration, give a text alternative that conveys its meaning in context. The [W3C informative-image guidance](https://www.w3.org/WAI/tutorials/images/informative/) explains context-dependent alternatives and supporting text. It does not verify the drawing, its permissions or its technical adequacy.

The [design-phase communication guide](/articles/sales-process/design-phase-communication/) covers control of current drawings and decisions. Link that later process after explaining the service relationship. Buyers should know who produces a document before reading how its revisions move.

## Which reviews are separate?

List the reviews that your documented process treats separately. Buyer acceptance, internal coordination, technical review and release authorization should each have a stated scope. Do not use a broad “approved” label when the reader needs to know who approved what.

Keep unresolved technical, permit, zoning, structural and other project questions with qualified project review. Do not imply that an in-house team label settles them. Name a specific review only when your records support the statement. Otherwise describe the question as pending assignment.

Distinguish a buyer agreeing with a concept from permission to use a drawing for another purpose. The public page can explain this boundary without reproducing private approval records. Use a plain description of the handoff and the role that confirms the next step.

### How can you copy a design responsibility map?

Use this original worksheet to prepare your public description. Repeat the fields for each task. Keep evidence references in the internal copy. Publish only wording the responsible roles have checked.

**Design responsibility map**

Task: [The work being described]

Responsible role: [Role or unknown]

Employment or collaboration scope: [Verified relationship and task boundary]

Output: [Named deliverable and intended use]

Approval boundary: [What remains separate or pending]

Evidence: [Current record and verification status]

Public wording: [The supported buyer-facing sentence]

An incomplete map is useful because it exposes an unanswered question. Keep “unknown” in the working record until someone verifies the answer. Do not replace it with a common industry arrangement. Your page describes your business, not an assumed model.

Capture these responsibilities in your [Operating profile](/process/operating-profile/). Before using the resulting description, compare it with the actual handoffs. The [guide to writing down your build process](/guides/writing-down-your-build-process/) explains how to collect that process from your team.

## How should outside plans enter the discussion?

State whether your team discusses outside plans only after that intake policy is confirmed. Explain what information the responsible role requests. Do not promise acceptance, adaptation or construction from a plan before the necessary review.

Ask the responsible party to confirm publication rights before you display a supplied drawing. Possession of a file is not a verified permission record. Keep permission to show an example separate from questions about adapting or using the underlying plan. Route unresolved rights questions to qualified review.

The page needs a service boundary rather than a full outside-plan intake procedure. Say who considers the request and which answer remains pending. Do not infer that an outside drawing removes the need to define responsibilities for your own team.

### What does a fictional responsibility map show?

This unnamed example is fictional. Suppose a builder's employee records concept questions and coordinates selections. An outside collaborator prepares a drawing issue under a documented task scope. Specialist review and release authority remain unassigned in the example. No credential, project approval or actual service arrangement is established.

The map gives the concept task to the employee role. Its output is a discussion brief. The approval boundary says that the brief does not authorize drawing release. A separate row records the collaborator's drawing task. Its evidence field requires the engagement scope before any public description is used.

The unknown review and release roles stay unknown. The team cannot support a statement that all design work happens in-house from those rows. It can prepare narrower wording about the recorded discussion and coordination tasks. That wording still needs confirmation before publication.

### What could the public excerpt say?

This fictional excerpt assumes the described roles have been verified. Replace every role and output with your confirmed arrangement before using it.

Our employee team records concept questions and coordinates selections. A documented outside collaboration covers drawing preparation for the stated scope. Your discussion brief and drawing issue have separate purposes. Technical review and permission to release drawings remain separate steps. We identify unresolved responsibilities before the next action.

If your service includes a studio discussion, the [design studio visit page guide](/articles/sales-process/builder-design-studio-visit-page-content/) explains how to prepare buyers. Keep that visit description aligned with the same task boundaries. A place to view samples does not expand the documented design service.

## What else should an in-house design page clarify?

### Does in-house design mean all design work is performed by employees?

An in-house design claim needs a verified scope. State which tasks employees perform and which involve retained specialists or outside collaborators. Do not imply that every task is internal when the records support a narrower arrangement.

### Does a designer label establish an architectural credential?

A designer label alone does not verify an architectural credential. Confirm any public credential claim from the relevant primary record. Keep licensing scope questions with qualified review rather than drawing conclusions from a job title.

### What should the responsibility map record?

A design responsibility map records the task, responsible role, working relationship, output, approval boundary, evidence and proposed public wording. Leave unverified fields unknown. Check the map against the actual service before publishing its description.

### Can the page promise to accept outside plans?

An in-house design page should describe outside-plan acceptance only when the responsible role has confirmed the policy. Keep project review and permission questions separate. Do not promise adaptation or use from an unreviewed file.