{{Project title — what this engagement delivers}}

02 The bigger idea

{{Your reframe in a short phrase — e.g. "Start with the data layer"}}

{{name the order a project like this usually follows, then say you would start somewhere else.}}

{{explain why — their ecosystem is bigger than any single platform and a lot of their data has no clear home today. Reference the conversation where this surfaced, and name what is deliberately still open going into discovery.}}

Phase 01

Discovery & configuration

{{Mon–Mon YYYY}} · Your team: {{X–Y}} hrs/week (higher during workshops)

Discovery sets the foundation for everything that follows. We start by understanding {{Client}}'s mission, audiences, and content, and by mapping the current technical landscape across both {{PrimaryProperty}} and {{SecondaryProperty}}.

From there we agree on what the connected ecosystem needs to do and how its systems should link, then turn that into a technical plan: the data architecture and DAM/{{data layer}} approach, the Engaging Networks configuration, and the integration logic between the website, Salesforce, and {{VendorSystem}}. It's the phase that lets the build start on evidence instead of assumptions.

Phase 02

UX & brand application

{{Mon–Mon YYYY}} · Your team: {{X–Y}} hrs/week for reviews and approvals

Structure first, then surface. Bringing two established website properties together is a chance to give visitors one clear, connected experience across {{Client}} and {{SecondaryProperty}}, so before any visual design we map what content exists, how it should be organized, and how people move between the two.

Wireframes then define layout, hierarchy, and the conversion paths for desktop and mobile, reviewed in Figma and approved before visual design begins. From there we apply your finalized brand into high-fidelity, responsive pages and a bespoke design system with a reusable component library, so the site stays consistent and easy for your team to build on.

Phase 03

Website build & system integration

{{Mon–Mon YYYY}} · Your team: {{X–Y}} hrs/week for testing and user acceptance testing (UAT)

Development turns the approved designs and the technical plan into a working site. The {{data layer}} is built first, since everything else reads from it: we implement the record types and metadata structure {{Client}}'s team defines for {{their content types}}, resources, and assets, then expose them through the API layer. The CMS and page templates are built on a staging environment your team can review throughout, and the remaining connections follow in sequence — the {{VendorSystem}} connection, and the {{remaining platform-to-CRM sync}}.

Each integration is field-mapped and tested in a sandbox with your team before it is enabled in production, and live donation processing is not touched until the full path has been validated. Structured data and page performance are implemented in each template as it is built.

Phase 04

Migration, QA, training & launch

{{Mon–Mon YYYY}} · Your team: {{X–Y}} hrs/week for migration, UAT, and training

Migration and launch, sequenced so live donation processing is never at risk. Content has already moved through writing, editing, and review alongside design and development, so the site isn't waiting on it now; this phase brings everything together for final integration and QA.

We don't launch until it's ready: functionality, performance, accessibility, and search all go through rigorous QA, and redirects and indexing are coordinated for a clean cutover. We also train your team — roughly {{20}} EN users, tiered by level — and hand off full documentation, so {{Client}} can run the site with confidence. Launch is the starting point, not the finish line, so we stay with you through the first weeks of live traffic.

Website Infrastructure

WordPress, built by a team that knows it deeply

A CMS decision is really a decision about who can change the site. When every publish depends on a developer, good content waits in a queue and the site slowly falls behind the work it is meant to represent. WordPress is a strong fit for {{Client}} on exactly that point: it's the platform your team already knows and has told us it prefers, it's the platform we build on every day, and it gives {{Client}} real ownership of code and content rather than files locked inside a proprietary system — so your communications team can publish and restructure on their own schedule, and the site keeps pace with your programs.

WordPress is a great CMS choice and likely our pick, but we'll confirm again in discovery. The front-end landscape is moving quickly and we'd rather validate the CMS decision against the full data and integration picture than assume it. In all likelihood that picture points right back to WP; discovery just means the decision is made with the complete picture in view.

{{data layer}} + Ecosystem (API & Data Management)

Where your data lives, and how the systems connect

Today {{Client}}'s most valuable material lives in various hubs: {{list where each kind of thing lives today — content, brand and photo assets, resources, supporter records — and who owns each.}}

That layer is the {{data layer}}, and it goes a meaningful step past the DAM the RFP describes. A DAM stores files; a hub stores structured records — a {{content item}} with its ingredients, its scaling data, and its images, rather than a document someone has to go find — and publishes them through one API that both websites, Engaging Networks, Salesforce, and {{VendorSystem}} all read from. That structure is also what makes this a future-facing model: AI assistants read structure rather than layout, so the same records that keep your systems in sync are what let an assistant answer a {{nutrition director}}'s question with {{Client}}'s material instead of someone else's.

SEO + AEO Optimization

Findable by people and by AI

Search is changing. People increasingly ask an AI assistant before they ever reach a search box, and the resources that get surfaced are the ones built to be read by machines as well as people. So {{Client}}'s resources now have three audiences to satisfy at the same time: the person searching, the search engine indexing, and the AI assistant answering on someone else's behalf.

That means clean, semantic markup and structured data so AI engines can quote {{Client}}'s {{their content types}} and resources accurately (AEO), the technical and on-page fundamentals that keep you ranking in traditional search (SEO), and clear navigation with fast pages so a real person finds what they need in seconds. We also keep the AI tooling small and cheap enough that it earns its place rather than adding cost for its own sake.

Additional Services

Optional Services: ongoing strategy & platform growth

Standing up this type of tech stack is a significant investment, and getting full value from it takes time and intention. The {{data layer}} will grow as {{Client}} is ready to connect more to it. {{Engagement platform}} Networks has capabilities your team will want to explore as you get comfortable with it. And the new infrastructure opens up marketing and fundraising possibilities that didn't exist before.

Beyond the core engagement, we're available to stay on as strategic and technical partners as the work evolves. This could mean supporting marketing and fundraising campaigns built on the new infrastructure, building out donor journeys and email nurturing sequences in Engaging Networks, or picking up the {{data layer}} roadmap as new connections to Airtable, Qualtrics, and other systems get phased in.

These services are scoped separately and none of them need to be decided now. They're here so you know we're committed to helping you get it right over time.