A structured intake and scoping document I built at Seton to standardize how the digital team initiated new work. Every section exists for a reason: to surface the questions that are expensive to answer at launch, and cheap to answer at kickoff. The annotations below explain the thinking behind the structure.
Built for
Ascension / Seton Healthcare Family — internal digital agency serving clinical, marketing, and operational stakeholders
Problem it solved
No consistent intake process. Scope, approvals, audiences, and analytics requirements were all discovered mid-project or at launch — when they were hardest to fix.
What happened to it
Adopted by management as the team's standard intake document. Used on every new program from the point it was introduced.
How to read this: Each section shows the fields in the original brief, plus an annotation explaining why that section exists and what goes wrong when it gets skipped.
Why this section exists
A template that doesn't explain its own workflow gets used inconsistently or not at all. This section made the brief an onboarding document as much as an intake form — marketing leads who had never worked this way before could understand the process, not just fill in the blanks.
Brief completion
Marketing lead works with the client and any other partners to complete the brief before any digital work begins. Not every section applies to every project — the Digital lead helps determine scope.
Kickoff meeting
All MarComDig team members involved in the project meet to discuss the brief — establishing shared understanding of roles, timelines, and priorities before work begins.
Digital schedules the meeting
Marketing updates the brief with any new information from the cross-org meeting
Digital creates the project schedule
Sitemap
Marketing and Digital work together to create a sitemap that supports the campaign while meeting Digital's standards for user-centered design and SEO. Review and approval cycle before anything is final.
Site content
Marketing supplies content or content direction per the approved sitemap. Review and refinement cycle between Marketing and Digital before content is final.
Homepage and promo design
Digital works with Marketing to design the homepage and any promotional elements needed. Review and approval cycle before design is final.
Build and launch
Digital works with AIS to build the required pages. Review cycle, final updates, custom URLs created, site goes live.
Why this section exists
In a regulated healthcare environment, discovering at launch that a compliance officer, legal reviewer, or clinical director was never looped in is not a minor inconvenience — it can pull a site offline and undo weeks of work. This section makes the approval chain explicit before the first page is built. It also names the budget owner, which surfaces scope conversations early rather than at invoice time.
Marketing Lead
Primary marketing point of contact for the project — the person who owns the brief and coordinates with the Digital team throughout.
Digital Lead
The Digital team's primary point of contact — responsible for schedule creation, sitemap development, and technical delivery.
Other Marketing Staff
Additional MarComDig team members involved and their specific roles.
Internal Communications and PR Leads
Named when the project involves public-facing communications or media coordination.
Client Service Line or Department
The clinical or operational team being served — including who supplies content and who has final say on it.
Additional Partners
All other Ascension Texas and external team members — vendors, agencies, IT partners — named upfront.
Approvals — Who must approve content before it goes live?
Every person who must sign off before the site publishes is named here, at the start. Compliance, legal, clinical leadership, communications — whoever it is, it is documented before a line of content is written. No surprises at launch.
Budget
Dollar amount and budget owner. If there is no budget, that is documented too — so scope expectations are set before work begins.
Why this section exists
Most projects arrive with a request: "we need a website for X." Strategy asks the prior question: what should happen because of this website, for which audiences, in what order of priority? Capturing this before the sitemap means the information architecture serves real goals rather than reflecting the org chart. Goals are defined as actions — things a user does — not intentions the organization has.
Strategic Priorities
How does this project relate to the organization's strategic priorities? Answered before any design or content work begins — grounds the project in business rationale rather than internal politics.
Primary audience
Who matters most
Who is the top-priority audience?
What do we want them to do when they arrive?
What do we want them to do after?
Goals listed in order of priority
Secondary audience
Who matters second
Who is the second most important audience?
Goals for this audience
How goals differ from primary
Tertiary audience
Everyone else
Third audience, if applicable
Goals for this audience
Any comments on audience overlap or conflicts
Why this section exists
Content decisions made after the information architecture is built are expensive. This section captures messaging, campaign integration, keyword direction, and translation requirements before the sitemap is created — so the structure serves the content, not the other way around. Spanish translation requirements in particular affect character counts, layout assumptions, and IA decisions that are much cheaper to address before design begins.
Messaging and Differentiators — by audience
Key messages and differentiators for the site as a whole, then differentiated by audience. What are the main ideas the site must express? What does each audience need to hear that is distinct from what the others need? Listed in priority order per audience.
Integration with Marketing Campaigns
Which campaigns will this site support? What tactics drive people to it — OOH, PPC, organic search, paid social, email, TV, print? What landing pages are needed and what are their calls to action?
Short / Marketing URLs
Redirect URLs needed for campaign tactics. Requested before build — not discovered after launch when they're already in print.
Keywords
Client's recommended keywords as a starting point. SEO research begins here and refines from the client's own language — capturing their vocabulary before the information architecture is finalized.
Translation Requirements
Spanish translation scope defined upfront. Affects character counts, layout assumptions, information architecture, and build estimates. Much cheaper to know before design begins.
Design Direction
Direction for graphics and visual treatment. Good site examples from the same line of business — what the client likes and why, captured before design begins.
Collateral and Assets
Links to all collateral and artwork being used online and offline for the campaign — collected before the build so design has what it needs.
Dates and Drivers
What is driving the schedule? Hard deadlines, campaign launches, clinical events, or compliance requirements — named explicitly so the schedule is built to the real constraint.
Why this section exists
Healthcare form requirements are not like other form requirements. A form that collects PHI has compliance, security, and legal implications that affect the build from the ground up. Discovering mid-development — or at security review — that a form touches protected health information is not a minor delay. This section surfaces the PHI question explicitly, before a line of code is written.
Purpose
What is the form for, and which audiences need to access it? Stated in plain language before any form design begins.
Subscribe Permission
Can a subscription opt-in be added to the form? Captures the email marketing opportunity upfront rather than as a late add-on.
Data Destination
Should form data go into the CRM system? Named before build so the integration is scoped correctly from the start.
Logic and Conditional Questions
Does the form have conditional logic, branching, or special functionality beyond basic fields? Surfaced before scoping so complexity is estimated accurately.
Form Data — Access and Format
Who needs to access the responses, how often, and in what format? Determines reporting and export requirements before the form is built.
Security — Will PHI be submitted through this form?
The single most important form question in a healthcare environment. Answered before any build decisions are made. If yes, security, compliance, and legal requirements reshape the entire form architecture.
Why this section exists
Analytics requirements asked at kickoff mean the tracking infrastructure is built in, not bolted on. When measurement needs are discovered after launch — the most common pattern — the tracking is retrofitted, the baseline data is already gone, and the reports don't answer the questions leadership is actually asking. This section also identifies who receives reports and why, which grounds the metrics in real decisions rather than vanity numbers.
What do you want to measure?
Goals identified in Section 3 map directly to measurement here. What user actions will tell us the site is working? Named before the sitemap is built so the information architecture can support the measurement model — not the other way around.
What is the purpose of the reports?
What decisions will these reports inform? Who is using the data and for what? Grounds the reporting in real organizational use rather than generating dashboards no one acts on.
Who needs to receive reports?
Named stakeholders with delivery cadence. Determines reporting format, frequency, and level of detail — and ensures the right people are seeing the data, not just the people who asked for it.