How does the chosen architecture maximise TEQ’s discoverability, citation, and entity surfacing in AI environments (Gemini, ChatGPT, AI Mode, Claude)?

How does the architecture support structured, entity-first content modelling? What level of control does TEQ have over Content Fragment models, schema design, and entity relationships? How does AEM Content & ATDW Product Content come together?

How does the authoring experience work for TEQ’s content team? What are the implications for content author productivity, in-context editing, and content governance?

How easy is it to maintain the front-end? What is the developer experience for building new components, making styling changes, and deployment? What is the level of effort to maintain back-end processes and any middle-ware?

How does the architecture enable AI-driven generation and workflow automation (e.g. AI-generated creative, GenAI-technical development, ability to use agents to drive workflows)? How well does the architecture leverage Adobe’s on-going roadmap? How easily can other similar third-party integrations be added if required?

How effectively and efficiently can the architecture match our current design features as well as extend these into an updated design? This includes highly interactive, visually stunning storytelling (immersive video, animations, maps etc…)

What is the relative complexity and cost of the migration from the current AEM Enterprise + React SPA architecture? How much is reusable?

How easy is it to extend the content architecture into other platforms – eg. building a new progressive web app and/or iOS/Android app using the content framework?

What are the ongoing hosting, licensing, infrastructure, and operational costs? How does TCO scale with traffic growth and AI bot activity?

If TEQ wished to change architectures or vendors in the future, how portable is the front-end, content, codebase, and infrastructure? What are the lock-in risks?

What are the known limitations, trade-offs, or risks of the recommended architecture for TEQ’s specific use case?

The Queensland Government Supplier Code of Conduct sets out the expectations that government has of businesses that want to sell their goods or services to the government, and outlines what constitutes a responsible supplier.

Compliance with the Queensland Government Supplier Code of Conduct is a mandatory requirement of this ITO Process.

Your organisation warrants adherence to the Queensland Government Supplier Code of Conduct.

For the next 6 questions, Suppliers are required to demonstrate that they have the financial capability to provide all the requirements over the term of the Contract. Short-listed Suppliers may be asked to provide further financial information if required.
Are there any significant events, matters or circumstances which have arisen within the past 12 months that could significantly affect the operations of the Supplier?

If answered "Yes" to the above question, please insert details here.

Are there, or have there been any:

a). Bankruptcy and/or de-registration actions; or

b). Insolvency proceedings (including voluntary administration, application to wind up, or other similar action)

either actual or threatened, against the Supplier in the past three years? If so, what (if any) remedial action has been taken?

If answered "Yes" to the above question, please insert details here

Are there any other factors that could adversely impact the financial ability of the Supplier to successfully perform the obligations contemplated by this ITO?

If answered "Yes" to the above question, please insert details here

Does the Supplier acknowledge that, if they are shortlisted, they may be required to provide further financial information (including audited financial statements for the past three years) to verify the Suppliers financial capacity?

If answered "No" to the above question, please insert details here

Provide details of any actual, potential or perceived Conflict of Interest that exists or may arise in relation to the Invitation Process or performance of the Contract (including any conflict of interest with department staff or other suppliers).

If there is nothing to declare, insert “Nil”.

Is the Supplier a small to medium enterprise?

Small – a business employing less than 20 people.

Medium – a business employing 20 or more people, but less than 200 people.

Note: people are both employees and contractors employed by the Supplier.

Provide a brief description of the business and its overall qualifications to meet the requirements. Background information may include the number of years of relevant experience, rate of growth, size, locations, annual turnover etc.

Provide details of 2 other government customers to which the Supplier has provided Services under the Contract.
CUSTOMER #1

Contact Name:

Position:

Phone number:

Email address:

Description of Goods and/or Services supplied:

CUSTOMER #2

Contact Name:

Position:

Phone number:

Email address:

Description of Goods and/or Services supplied:

Question:
To provide improved performance, AI - generative optimisation, with a lower developer cost overhead. Will Tourism and Events Queensland accept alternate platform options to replace costly, legacy AEM technology?

Answered on 09/Jun/2026 01:15 PM:


Good afternoon,

Thank you for your question. No, vendors must choose between one of the 3 architectures noted in Section 3 of the RFP.

Thank you,

TEQ

Question:
Is TEQ wanting answers to the 24 questions listed in VendorPanel? We note that some are in the RFP document, and some not. For the questions that aren't in the RFP document, does TEQ have a preference of how (format / document etc) they would like these answered? Thanks.

Answered on 12/Jun/2026 11:22 AM:


Good morning Helena,

Thank you for your interest. Questions that are not specifically in the RFP document are standard TEQ procurement questions. TEQ does not have a preference on the format you use to submit your answers.

Thank you,

TEQ

Question:
Question: Whether TEQ will consider a non-AEM architecture where it better delivers the stated AI-first outcomes

The RFP requires respondents to choose one of three AEM-based architecture options. We understand TEQ’s current investment in AEM, Adobe Analytics, Adobe Target, AEM Assets and the broader Adobe ecosystem.

However, the RFP’s stated objectives appear to point to an outcome-led architecture, not necessarily an Adobe-led architecture. TEQ is seeking a platform that is AI-ready, API-first, highly performant, portable, cost-controlled, easy to maintain, and suitable for a small internal development team.

In that context, continued reliance on AEM as the primary CMS and delivery platform appears to work against several of TEQ’s own stated objectives.

AEM is a heavy enterprise platform with high implementation complexity, specialist resourcing requirements and a comparatively high total cost of ownership. It also creates meaningful platform lock-in across content modelling, authoring, asset management, deployment, delivery and ongoing support. This appears difficult to reconcile with TEQ’s stated requirements for future portability, cost control, developer velocity, ease of extension and maintainability by a two-person internal development team.

AEMaaCS also introduces Adobe-specific operational constraints, including Content Request limits, Cloud Manager quality gates, Adobe-specific deployment patterns and ongoing licensing dependency. These constraints may make the platform less flexible than a modern composable architecture for an AI-first, outward-facing content model.

For an AI-optimised tourism platform, the critical capabilities appear to be structured entity-first content, fast pre-rendered HTML, server-side schema generation, an outward-facing content API, strong ATDW integration, search performance, analytics continuity, accessibility, content governance and simple long-term maintainability. These outcomes do not inherently require AEM, and may be delivered more cleanly through a modern composable architecture using a headless CMS, Next.js and AWS.

Would TEQ accept a response based on a modern composable architecture if it can deliver the required outcomes with less complexity, lower long-term cost and greater strategic flexibility than an AEM-led solution?

The primary benefit would not simply be technical compliance. It would be a cleaner operating model for TEQ: faster content production, faster development cycles, easier maintenance by TEQ’s small internal team, stronger content portability, lower platform lock-in, and more of the project budget directed towards the outcomes TEQ is seeking - AI visibility, structured content, content velocity, search performance, user experience and industry lead generation.

In this model, the website would be treated as an AI-ready content and distribution platform, rather than an AEM migration project. The architecture would be designed around TEQ’s future needs: structured canonical content, pre-rendered HTML, server-side schema, outward-facing content APIs, ATDW integration, search, analytics, multilingual content and multi-channel reuse.

A non-AEM composable architecture could also reduce delivery and operating risk by separating content, presentation, search, data integration, analytics and AI-readiness into cleaner, more maintainable layers. This would allow TEQ to evolve each part of the platform over time without being constrained by a single enterprise suite or vendor-specific implementation pattern.

Given this, will TEQ consider a non-AEM architecture if a respondent can demonstrate that it meets or exceeds the required business, technical, AI-readiness, performance, accessibility, analytics, migration, governance and integration outcomes?

If TEQ is open to this, should respondents submit such an approach as:

a compliant primary response;

a secondary architecture appendix;

a formal compliance exception; or

a clarification alongside one of the three nominated AEM options?

If TEQ is not open to a non-AEM alternative, could TEQ please confirm whether AEM is mandatory due to an existing Adobe commercial commitment, internal technology policy, procurement constraint, or another non-negotiable requirement?

Answered on 12/Jun/2026 02:46 PM:


Good afternoon Dan,

No, vendors must choose between one of the three architectures noted in Section 3 of the RFP. 

Thank you,

TEQ

Question:
1. Can TEQ clarify “UI uplift; component and template restyle”? Any visual references of target state designs would be beneficial.

2. Are there acceptable trade-offs between page source completeness and architectural simplicity?

Ensuring all content is available in the initial page source improves SEO and AI discoverability but may introduce additional architectural complexity. Certain elements such as header, footer or JSON-LD could potentially remain on the client-side.

3. Is it acceptable to use model.json as the primary content API, with GraphQL as a supplementary service?

In this approach, pages can be constructed in AEM using the standard page component that comes with features designed for managing pages of content including page properties, hierarchy and navigation, templates, and flexible content authoring. AEM's built-in GraphQL service cannot query page content, only content fragments. However, using model.json, the content within content fragments used within a page will still be included. GraphQL persisted queries will still be available for more complex querying.

4. Can Adobe Universal Editor JavaScript libraries be used to enhance the authoring experience?

Universal Editor libraries are required for a seamless real-time authoring experience. These libraries only affect the authoring experience and are not utilised for rendering pages for end-users. However, a strict interpretation of this requirement could restrict their use. Clarification is required to balance usability and architectural constraints.

Reference: Section 6.2 – "Zero Adobe client-side runtime libraries"

5. Can Adobe Target remain client-side rendered, provided Core Web Vitals thresholds are maintained?

6. Is a combined AEM and ATDW aggregation API mandatory, or can composition occur at the edge?

Introducing a unified aggregation API adds architectural complexity. Edge-based composition may simplify backend design but could have implications for governance and consistency.

7. What is the preferred migration sequencing (Corporate vs Consumer)?

8. Can RTL support be deferred if not immediately required?

RTL implementation introduces additional complexity across design, development, and testing. Deferring may simplify delivery if not required immediately.

Reference: Section 6.11

9. Is the “reviews” feature expected to be built in-house within AEM, or can it utilise a third-party platform (with the features mentioned in Section 6.7 and 6.15), including client-side loading?

Answered on 19/Jun/2026 10:04 AM:


Can TEQ clarify “UI uplift; component and template restyle”? Any visual references of target state designs would be beneficial.



TEQ: The focus for the UI uplift is a re-skin or re-theme of components and page templates. Outside of any required changes elsewhere in the RFP resulting from the rebuilding of the front end, for this uplift requirement we are looking at visual styling uplift (colour, type, spacing, imagery). Consistency is required between Consumer and Corporate Sites with subtle differences based on the audience of each site. TEQ is not issuing target-state comps as a design guidance. Vendors should represent their own interpretation of the uplift, informed by TEQ brand guidance, the current site, and global tourism best practice, and should show how they would partner with TEQ’s in-house creative team through defined feedback rounds. Noting also that correcting the current boxed desktop layout to full-bleed is a specific deliverable required within this broader work.

2. Are there acceptable trade-offs between page source completeness and architectural simplicity?

Ensuring all content is available in the initial page source improves SEO and AI discoverability but may introduce additional architectural complexity. Certain elements such as header, footer or JSON-LD could potentially remain on the client-side.


TEQ: The non-negotiable here is that the header and footer navigation links are server-rendered into the initial HTML so as to not impact SEO GEO outcomes. At a broader level, all elements that are critical for driving SEO and GEO should be server-rendered to achieve our objectives. Client side rendering is acceptable for interactive fragments that have no discoverability value.


3. Is it acceptable to use model.json as the primary content API, with GraphQL as a supplementary service?

In this approach, pages can be constructed in AEM using the standard page component that comes with features designed for managing pages of content including page properties, hierarchy and navigation, templates, and flexible content authoring. AEM's built-in GraphQL service cannot query page content, only content fragments. However, using model.json, the content within content fragments used within a page will still be included. GraphQL persisted queries will still be available for more complex querying.


TEQ: TBD - TEQ would need more information on why you would be recommending this approach of using model.json rather than GraphQL (as the primary content API) before TEQ can provide any feedback. A detailed analysis of the pros and cons now and into the future vs our stated objectives in the RFP would be required.


4. Can Adobe Universal Editor JavaScript libraries be used to enhance the authoring experience?

Universal Editor libraries are required for a seamless real-time authoring experience. These libraries only affect the authoring experience and are not utilised for rendering pages for end-users. However, a strict interpretation of this requirement could restrict their use. Clarification is required to balance usability and architectural constraints.

Reference: Section 6.2 – "Zero Adobe client-side runtime libraries"


TEQ: Yes, Universal Editor libraries are permitted under that scoping.


5. Can Adobe Target remain client-side rendered, provided Core Web Vitals thresholds are maintained?


TEQ: Yes


6. Is a combined AEM and ATDW aggregation API mandatory, or can composition occur at the edge?

Introducing a unified aggregation API adds architectural complexity. Edge-based composition may simplify backend design but could have implications for governance and consistency.


TEQ: Yes, composition at edge can be used providing it still meets the requirements of the RFP - eg. data freshness, schema consistency, one API for AI-chatbot consumption etc...


7. What is the preferred migration sequencing (Corporate vs Consumer)?


TEQ: As discussed consumer is the priority however both need to be delivered within the available time based on the contract and our time-boxed availability to dual environments in Adobe.


8. Can RTL support be deferred if not immediately required?

RTL implementation introduces additional complexity across design, development, and testing. Deferring may simplify delivery if not required immediately.

Reference: Section 6.11


TEQ: Yes, not immediately required and can be deferred.


9. Is the “reviews” feature expected to be built in-house within AEM, or can it utilise a third-party platform (with the features mentioned in Section 6.7 and 6.15), including client-side loading?



TEQ: Third-party platform is permitted and preferred; client-side hydration fine for interactivity; aggregate rating, review schema and a content sample must be server-rendered.

Question:
1. LCP performance target

Sections 4.2 and 5.1 state a Largest Contentful Paint (LCP) target of 2.0s, while Addendum A (Domain 10 — SEO & Structured Data) states 2.5s. Could TEQ please confirm the authoritative LCP target that will apply to acceptance across all key page types?

2. WCAG conformance level

Section 6.14 and Addendum A reference WCAG 2.1 AA, while the Phase 3 design acceptance criteria (Appendix C) reference WCAG 2.2 AA. Could TEQ please confirm the target conformance level, and whether WCAG 2.2 AA applies to the design stage only or to the full delivered platform?

3. Current-state reference material

Given the fixed-price requirement, would TEQ consider sharing the current-state architecture diagram and a current component/template inventory with all responding vendors, to improve scoping accuracy at the proposal stage?

Answered on 19/Jun/2026 09:12 AM:


Hi Ray,

Thank you for your interest. Please find the response below. We have also attached some documents showing the Current state.

1. LCP performance target

Sections 4.2 and 5.1 state a Largest Contentful Paint (LCP) target of 2.0s, while Addendum A (Domain 10 — SEO & Structured Data) states 2.5s. Could TEQ please confirm the authoritative LCP target that will apply to acceptance across all key page types?

TEQ: Largest Contentful Paint (LCP) target of 2.0s is the correct target.

2. WCAG conformance level

Section 6.14 and Addendum A reference WCAG 2.1 AA, while the Phase 3 design acceptance criteria (Appendix C) reference WCAG 2.2 AA. Could TEQ please confirm the target conformance level, and whether WCAG 2.2 AA applies to the design stage only or to the full delivered platform?

TEQ: Target level - WCAG 2.2 AA. Applies to full delivered platform. TEQ are open to discussion on any particular areas that are unachievable within a reasonable budget/time/effort level.

3. Current-state reference material

Given the fixed-price requirement, would TEQ consider sharing the current-state architecture diagram and a current component/template inventory with all responding vendors, to improve scoping accuracy at the proposal stage?

TEQ: Yes - please find included our current-state architecture diagrams and component inventory.

Question:
URL inventory - Can TEQ provide the full current URL inventory across both the Consumer and Corporate sites, broken down by: authored pages, ATDW dynamic product pages, Live Copy market variants, translated-language pages, active redirects, and unpublished or archived pages?

Digital asset inventory - Can TEQ provide a breakdown of the current DAM by asset type (images, video, PDFs and documents, icons, campaign assets), indicating how many are actively in use on the current sites, and confirm whether assets are presently managed in Scene7, AEM Assets / Dynamic Media, or both?

Access to current materials - During the proposal period, can TEQ provide access to the current source repositories, AEM packages, AWS Lambda code, Adobe Launch rules, analytics data-layer documentation, and architecture diagrams? If these are available only to the successful vendor post-award, please confirm. Access during the proposal period would materially improve the accuracy of migration estimates.

Binding performance and accessibility figures - The RFP references different figures in different places: both WCAG 2.1 AA and WCAG 2.2 AA, and Largest Contentful Paint thresholds of both under 2.0 seconds and under 2.5 seconds. Can TEQ confirm the binding requirement in each case?

Consumer and Corporate commonality - Will the Consumer (queensland.com) and Corporate (teq.queensland.com) sites share a single design system, component library, analytics and data-layer model, and content model, or are they expected to be delivered as separate implementations?

Content migration responsibilities - Section 6.1 and the Phase 1 acceptance criteria reference a migration plan covering vendor and TEQ responsibilities. For pricing purposes, can TEQ indicate whether a TEQ content team will perform content entry and QA, or whether the vendor is expected to perform all content migration, entry and QA?

Bunji AI chatbot - For the existing Bunji AI chatbot, does TEQ wish it to be retained as-is, re-skinned, rebuilt, or replaced as part of this engagement? Can TEQ also confirm its current data source or sources and the index it draws on?

Technical Integrations - Can you provide a full list of technical integrations: Bunji, Maps, Mapbox/Google Maps, Holiday Finder, Adobe Campaign forms, OneTrust, Target, Hotjar, Profound, OpenSearch? (anything other than this)

ATDW images - Are ATDW images managed through ATDW, AEM Assets, Scene7, or both?

Translations - Are the translated-language pages currently human-translated, machine-translated, or a mix? If machine translation is used, is a third-party translation provider involved?

ATDW freshness SLA - The RFP references front-end updates within 15 minutes of an ATDW or AEM content change. Can TEQ confirm whether 15 minutes is a contractual SLA, and whether it applies uniformly across all content types?

Scope of booking and transactional functionality. We understand the sites surface tourism products, events and deals with outbound booking links, and that the transactional booking and payment journey itself is completed off-site on third-party platforms. Can TEQ confirm that building or migrating any transactional commerce functionality (cart, checkout, payment) is out of scope, and that the requirement is limited to maintaining outbound booking links?

Answered on 23/Jun/2026 11:09 AM:


Good morning,

Please find the responses to your queries. We have also uploaded 2 extra documents related to this query as well.

1. The attached workbook ("url _report_RFP_Question.xls") provides the full URL inventory across both the Consumer and Corporate sites, broken down by authored pages, ATDW dynamic product pages, Live Copy market variants, and translated-language pages for the Germany, France, Taiwan, Japan, Hong Kong, and Korea markets. Unpublished and archived pages are included within these listings.

Redirects are excluded: they are distributed across CloudFront, Dispatcher, and application layers with no single registry, and are largely rule-based or dynamically generated (e.g. HTTPS enforcement, product expiry), so no fixed count is meaningful.

2. The attached reports ("DAM_report_RFP_Question.xls") provide a DAM breakdown by asset type: images, video, PDFs/documents, icons, and campaign assets across the Consumer, Corporate, Campaign, and Content Fragment folders, with each asset's management status confirmed as AEM Assets-only or synced to Dynamic Media/Scene7 (derived from Dynamic Media metadata).

Active usage cannot be read deterministically from the DAM itself, since references span multiple property types, rich text, and Scene7-delivered URLs that bypass the asset path. Please revert if you require this additional detail.

3. Yes, access to these items can be provided at various levels of granularity.

AEM packages: there is a current upgrade to Adobe Experience Manager 6.5 LTS, SP2 that will be complete by 25 June 2026. This change also includes the following upgrades to our stage and prod environments:

Operating System - Red Hat Enterprise Linux 8.10

OS Kernel - 4.18.0-553.el8_10

Java - 21.0.7-8 (JDK 21.0.7)

Apache Jackrabbit Oak - 1.68.1

Dispatcher - 4.3.7

Apache web server - 2.4.37

AWS Lambda Code access can be arranged.

Adobe launch rules: Read Access can be granted during the proposal period

Analytic data layer: Master Implementation SDR can be shared during the proposal period

Architecture Diagrams:

These are now available on Vendor Panel if you download the Tender Package again.

4. Confirming Target level - WCAG 2.2 AA. Applies to full delivered platform. TEQ are open to discussion on any particular areas that are unachievable within a reasonable budget/time/effort level.

Confirming LCP benchmark is under 2.0 seconds.

5. Consumer (www.queensland.com ) and Corporate (teq.Queensland.com) will have substantial shared foundations rather than two independent builds.

Both sites share a single AEMaaCS instance, component library, deployment pipeline, and infrastructure - it is one architecture with two site configurations, not two separate implementations. The Corporate site (~200 pages, no ATDW, no Live Copy variants) represents incremental effort on top of the Consumer build, with its own templates, content migration stream, and go-live window.

Design system and component library:shared. Both sites draw on a common design system and component library, with Corporate's visual design and component usage being a smaller subset of the Consumer set rather than a separate system. Component and design work is therefore largely reused, not duplicated.

Data-layer model: shared. Both sites use the same Adobe event-driven client data layer, giving a consistent data-layer contract across the two.

Analytics: separate. Implementation diverges here: Consumer uses Web SDK (service-side), while Corporate uses Adobe AppMeasurement, and each site maintains its own Adobe Launch/Tags container. The analytics tooling and configuration are delivered independently, even though the underlying data layer is common.

Content model: expected to differ. The two sites serve different audiences and content types, so their content models are likely to diverge.

6. For pricing purposes, the vendor should assume responsibility for all content migration, content entry, and QA. TEQ will not be resourcing a content team to perform entry or QA; these activities, migration of content into the new platform, initial authoring/entry, and quality assurance against the agreed acceptance criteria are to be scoped and priced by the vendor.

TEQ's role is limited to providing source content access, clarifying requirements, and final review and acceptance sign-off against the Phase 1 acceptance criteria, rather than performing the migration, entry, or QA work itself.

7. The Bunji AI chatbot is to be retained as-is. There is no expectation for the vendor to re-skin, rebuild, or replace it as part of this engagement, and no such effort should be included in pricing.

The vendor should, however, preserve Bunji's existing integration and embed point on the replatformed site so that current chatbot functionality carries over without regression. Beyond maintaining that integration so it continues to operate as it does today, no work on the chatbot itself is in scope.

Bunji’s current retrieval layer draws from the queensland.com consumer website OpenSearch/Elasticsearch index. The index contains vectorised website page content, with embeddings appended to the relevant JSON records for retrieval by the chatbot’s RAG model.

The primary structured content source currently included is ATDW operator data, limited to BOQE (Best of Queensland Experience) operators to preserve response quality. ATDW events are also included.

Bunji uses Azure OpenAI services for embedding/tokenisation and conversational response generation. Conversation logs are stored separately in Google BigQuery and backed up to S3; these logs are used for reporting and analysis, not as the primary retrieval index for chatbot answers.

8. The full inventory of technical integrations across the Consumer and Corporate sites is as follows:

Content & Data: ATDW / ATLAS API (primary structured data source — 11 product categories; delta import pipeline into OpenSearch), Adobe Dynamic Media / Scene7 (image and video rendition delivery).

Adobe Experience Cloud: Adobe Launch (tag management — separate containers per site), Adobe Analytics (Consumer via Web SDK server-side; Corporate via AppMeasurement), Adobe Target (client-side personalisation/experimentation), Adobe Audience Manager (audience segmentation).

AWS Services: 8 AWS Lambda functions (googlePlaces, elasticsearchAtdwUpdate, elasticsearchAtdwDelete, saveItem, dealsQueryHandler, chat, elasticsearchHolidayFinderQuiz, elasticsearchHolidayFinderResult), AWS CloudFront (CDN with CloudFront Functions and Lambda@Edge for GeoIP routing, vanity URLs, .html stripping, domain redirects), AWS API Gateway, AWS S3 (Bunji log backups, static assets), AWS Secrets Manager, OpenSearch/Elasticsearch (search index, listings, Holiday Finder, Bunji RAG retrieval).

AI / ML: Azure OpenAI (Bunji chatbot embedding/tokenisation and GPT response generation), Google BigQuery (Bunji conversation log storage and reporting).

Maps & Location: Google Maps API, Google Places API (via Lambda), Mapbox SDK (currently being integrated).

Analytics & Tracking: Google Analytics GA4 (via Adobe Launch tags, alongside Adobe Analytics), Hotjar (heatmaps and session recordings).

Consent & Privacy: OneTrust (cookie consent management, controls tag loading).

Forms & Security: Adobe Campaign (marketing campaign forms), ReCAPTCHA (bot protection on competition forms and chatbot).

Translation: Transperfect (translation management for international language sites within AEM).

Social & UGC: Crowdriff (social media / user-generated content aggregation feeds).

Search & Discovery: Profound (site search), Holiday Finder (quiz-based trip recommendation tool powered by Lambda and OpenSearch), Bunji AI chatbot (RAG over OpenSearch index using Azure OpenAI, with BigQuery logging).

9. ATDW product images are not held in TEQ's AEM DAM or Scene7. They are managed within the ATDW (Australian Tourism Data Warehouse) platform, which remains the source of truth for product imagery. Images are imported into the site via the ATDW asset API as part of the product data sync, and delivered through CloudFront, where they are cached at the CDN edge.

ATDW imagery therefore sits outside the AEM DAM asset inventory and is governed by ATDW's own asset lifecycle rather than by TEQ's asset management.

10. Translated language pages are human translated; machine translation is not used. Translation happens through two channels:

In-house: TEQ's existing international team performs translations, drawing on their in-market language expertise.

Third-party (TransPerfect): pages requiring manual translation are sent directly from AEM. The GlobalLink Connect adaptor sits within AEM and communicates with TransPerfect's Project Director via web services, dispatching content for human translation and returning the translated pages into AEM.

11. The 15-minute figure is not a contractual SLA. It reflects a configuration within TEQ's AWS platform, the interval at which ATDW product changes are detected and propagated to the front end. Rather than a committed service level, and as a configuration it can be adjusted.

It also does not apply uniformly across all content types: the 15-minute behaviour relates specifically to ATDW content. Other content types are updated through their own mechanisms and are not governed by this setting.

12. TEQ confirms your assessment. The sites surface tourism products, events, and deals with outbound booking links, and the transactional booking and payment journey is completed off-site on third-party platforms.

Building or migrating any transactional commerce functionality, cart, checkout, or payment is out of scope for this engagement. The requirement is limited to surfacing and maintaining outbound booking links to those third-party platforms.

Question:
Section 8.4 requests "Adobe Platinum/Gold partner status including any specific accreditations for relevant products." Could TEQ please confirm whether holding Adobe Platinum/Gold partner status is a mandatory eligibility requirement? Will a proposal be excluded from evaluation if the respondent does not hold this status, or whether it is an evaluation criterion that respondents without that specific partner tier may still respond against (for example, on the strength of relevant accreditations, AEM delivery experience and Adobe roadmap alignment)?

Answered on 19/Jun/2026 02:59 PM:


Good afternoon,

Please note the response from TEQ:

Adobe Platinum/Gold partner status including any specific accreditations for relevant products will be well received in proposals, however it should not exclude vendors from responding should they not have these specific partner statuses. Other aspects of the vendor's experience will be heavily considered in tandem.

Question:
Hi, just have some clarification questions from the team. Have a good weekend!

1. Can an extension be provided for clarification questions please?

2. Can you provide the high-resolution current architecture diagram referenced in Appendix Z prior to submission, rather than only to shortlisted vendors?

3. Can you provide any known technical debt in the existing components (the 40+ referenced)?

4. What is the current Adobe Target implementation scope, how many activities, what types (A/B, XT, Automated Personalisation, etc.), and which pages/components are currently personalised?

5. What is the current redirect inventory, how many active 301/302 exist today, and where are they managed (cloudfront, dispatcher, application-level)?

6. What is the current AEM workflow configuration? How many workflow models, approval steps, and roles are defined?

7. What is the current ATDW API contract (rate limits, data freshness guarantees, schema/field documentation, and authentication method)?

8. What is the current OpenSearch cluster configuration (instances, index count, document count, query volume, any custom plugins)?

9. What forms exist on both sites? What are the form types, submission volumes, and downstream integrations?

10. Is there any user-generated content, member login, or authenticated experience on either site currently?

11. For the 6 translated language variants, are they human-translated or machine-translated or combination? Can you confirm that these 6 variants are in english, including SG? Who manages translation workflows now and moving forward?

12. For the live copy inheritance model, which fields/components are typically overriden per market variant? Is this well-documented today, or will it require discovery?

13. How much of the existing 2.4K pages of content is considered current and high-quality vs outdated and potentially eligible for archival/consolidation? Is content audit/rationalisation in scope or should we assume 1:1 migration of all pages?

14. For the reviews integration (section 6.15), which specific review source do you intend to integrate? Is this ATDW-sourced, Google, TripAdvisor, or another platform? Are API contracts already in place or do we need to evaluate and recommend?

15. For the pricing data layer (section 6.3), does ATDW currently provide structured pricing, seasonal bands, and availability data, or will this require a new source of data enrichment?

16. What is the ATDW data update frequency? How often does the ATDW database change, what is the typical volume of changes per day?

17. Regarding content freeze during migration, what is TEQ's tolerance? Can the business sustain a content freeze on specific site sections, and for how long?

18. How do you envision the "incremental migration by site section", is there a preferred order of sections, and what defines a section (i.e URL path, by template, by market)?

19. The 40K assets, what proportion are actively used on the current site vs orphaned? Have you completed any asset audit recently, or should we assume a full audit is required or migrate everything?

20. What is the current Scene7/Dynamic Media Hybrid configuration? How many image presets, viewer presets, and video profiles exist? Are there any custom Scene7 configurations?

21. What do you define as "medium-level creative uplift"? Is this a new design system/design token, or primarily a visual refresh of existing components within the current brand guidelines?

22. Can TEQ share details on the design approval process, including: key stakeholders and expected feedback cadence

23. Is there an existing design system or component library (e.g. Figma) available for the current sites?

24. For the maps and directions component enhancement, what is the preferred mapping provider going forward? Are there existing API contracts and usage limits?

25. For the outward facing content API, have you identified consumer/partners who will use this API at launch, or is this being built for future consumption? What are the expected API call volumes?

26. How many content authors do you have? What is your current authoring operating model (distributed vs centralised)?

27. What is the expected cadence of TEQ sign-offs, i.e for design approvals, content model approval, UAT? How many stakeholders are involved in each approval gate?

28. Do you have a formal accessibility audit by a 3rd party assessor (i.e Vision Australia), or is vendor self-assessment to WCAG 2.2 AA sufficient?

29. What is your preferred defect management tool and process (i.e JIRA)?

30. For the "Confluence-based Playbook", do you have an existing Confluence instance and are we expected to work within your Confluence, or deliver and handover?

31. Is SEO content strategy in scope for us, or is it managed by you or a separate agency?

32. Are there any other TEQ digital properties (i.e campaign microsites, event-specific sites) that share the AEM instance or infrastructure and may be affected by the migration?

33. Is the outward-facing content API expected to have a developer portal, public documentation, and self-service API key registration, or simply be a documented, secured endpoint?

34. Are there specific pages or experiences where a higher level of visual enhancement is expected (e.g. homepage, campaign or destination landing pages)?

35. What are the priority user journeys TEQ would like to optimise (e.g. inspiration, trip planning, event discovery)? Are there known pain points or underperforming areas in the current experience that should be prioritised?

36. Should we assume the existing information architecture will largely be preserved, or is there scope for refinement and optimisation?

37. Has TEQ conducted any recent information architecture review, analytics analysis, or user testing that should inform the design approach?

38. Are there known challenges with: Navigation structure, Content hierarchy, Discoverability of key content

39. What is the expected role of TEQ’s in-house creative team in shaping design direction?

40. Should we assume a 1:1 migration of existing templates, or is there opportunity for template rationalisation and improvement?

41. Are there any components or content structures that must remain unchanged during migration?

42. How distinct should the experiences be between: qld.com and qldteq.com. Are there specific requirements for localised or market-specific variations in design?

Answered on 25/Jun/2026 02:46 PM:


Thanks Helena.

Please find our answers below:

1. The current advised timeline will not be adjustable.

2. This is available on Vendor Panel if you download the Tender Package again.

3. Known technical debt in the existing platform includes the following:

React / JavaScript codebase

The React codebase has recently been upgraded from React 16 to React 18, alongside related upgrades to Storybook, Webpack, styled-components, and React scripts. This has resolved a major dependency risk, but the platform still relies on Adobe’s deprecated SPA Editor libraries, including @adobe/aem-react-editable-components, @adobe/aem-spa-component-mapping, and @adobe/aem-spa-page-model-manager. This creates a longer-term maintainability risk because Adobe’s SPA Editor approach is deprecated and may make future package upgrades or security remediation more difficult.

Maps components

New maps components are currently being implemented using Mapbox, replacing or supplementing the legacy Google Maps implementation. This work reduces dependency risk around older map components, but it introduces a transition period where both Google Maps / Places and Mapbox may need to be supported. Technical debt remains around ensuring consistent map authoring, ATDW product integration, API usage patterns, and cache/API behaviour across old and new map experiences.

AEM 6.5 LTS / Java upgrade

The AEM 6.5 LTS upgrade requires a Java uplift from Java 8 to Java 21, along with related dependency and infrastructure updates including Dispatcher, Oak, Core Components, Guava, Mockito, and the javax to jakarta namespace migration. This work is in progress with an expectation of completion by 24 June 2026

Adobe SPA Editor / client-side rendering

The current site is heavily client-side rendered through the AEM React SPA model. This creates SEO, performance, and AI/LLM crawlability limitations because crawlers and AI bots may not reliably execute JavaScript. A pre-rendering workaround exists, but it is fragile and dependent on bot/user-agent handling. This is a significant architectural debt item and should be considered in any future platform redesign.

Dynamic Media

Adobe Dynamic Media is running in Hybrid mode rather than Scene7 mode. This limits access to Smart Imaging capabilities such as automatic WebP/AVIF optimisation. Further investigation is required before image optimisation improvements can be fully delivered.

Operational debt

Cache clearing, deployments, and some infrastructure maintenance remain operationally heavy. CloudFront, Dispatcher, and browser cache behaviours need to be managed separately. Dev and QA environments also require more manual management than Stage and Production.

4. 6 to 10 test per financial year

All of the tests were A/B Tests predominantly on ATDW product pages

Personalisation test at this stage is planned to use GEO targeting only (e.g. NSW, VIC, QLD)

5. Redirects are are distributed across CloudFront, Dispatcher, and application layers with no single registry, and are largely rule-based or dynamically generated (e.g. HTTPS enforcement, product expiry), so no fixed count is meaningful.

6. 11 TEQ-specific (2 custom publishing + 1 customised DAM + the GlobalLink set), of which the two v1.0 GlobalLink models look like inactive legacy.

Custom publishing workflows follow the same process:

Dam workflow

GlobalLink : all GlobalLink processes are a duplicate of the below or with one step less.

Roles: Author (Content Creator); Editor (Reviewer/Approver); Admin

7. The 15-minute figure quoted in the RFP is not a contractual SLA. It reflects a configuration within TEQ's AWS platform, the interval at which ATDW product changes are detected and propagated to the front end. Rather than a committed service level, and as a configuration it can be adjusted.

8. Cluster Summary

Domain

Environment
Instance Type

Node Count Storage
Zone Awareness
Status

teq-backend--dev
Development
m5.large.elasticsearch
2

10 GB
Single AZ

Active

teq-backend--staging
Staging
r5.large.elasticsearch
2

75 GB
Single AZ

Active

teq-backend--prod
Production
r5.large.elasticsearch 2

75 GB
Multi-AZ

Active

No custom plugins

Information regarding index count, document count, query volume TBC

9. Consumer siteForm: A single-column, mobile-first React component rendered inside AEM as part of the SPA. This form can be configured for a range of uses but primarily for competition entries. Used in frequently but configured to handle high volume spikes.

a) Form submit ? reCAPTCHA verification ? Campaign API endpoint

b) Data written to Azure Table (source of truth for Power BI reporting)

c) Data written to AWS S3 (JSON format)

d) A cron job copies data to a second S3 bucket as CSV, batch-sent to Adobe Campaign Standard (ACS) to trigger confirmation emails

e) ACS checks if the profile exists: creates new, appends, or rejects duplicates — response returned to the React form.

Corporate site: forms from CRM dynamics via embed frame

10. No user-generated content currently. The Corporate Site currently features low-security authenticated portals utilizing shared, universal password access.

11. The translated sites are a mix of human and machine translated. They are managed mostly in market (overseas) through a combination of content authored by our staff, via Transperfect (through the AEM GlobalLink plug-in) or via LLM tools (eg. DeepL).

12. For the English locale variants (NZ, US, GB, SG, IN), Live Copy inheritance is the operative model and per-market overrides are limited in scope. Overrides typically cover a small proportion of editorial text, campaign-specific content and requirements, and market-specific visuals. Page structure, templates, and evergreen content remain inherited from the /au/en master, with inheritance cancelled only where a market deliberately diverges.

Non-English locales also inherit structure and layout from /au/en via Live Copy, but their in-page content is translated and managed independently (in-market teams or via TransPerfect GlobalLink Connect) rather than overridden through Live Copy. For these locales, inheritance applies to structure, not content.

13. Please note the 2.4k compromises of approximately 1.2k English pages, 200 translated pages (6 markets x 200), and 300 corporate pages. At this stage assume 1:1 migration of all pages.

14. This is TBC but likey an established and trusted source such as Google and/or TripAdvisor. API contracts are not currently in place. A recommendation would be welcomed.

15. ATDW does not currently provide structured pricing. Iniitally the pricing data layer wil utilise the available pricing in ATDW however over time, it is expected that ATDW will enhance their pricing and availability data. We are not expecting vendors to provide a new source of data enrichment in this scope.

16. The 15-minute figure quoted in the RFP is not a contractual SLA. It reflects a configuration within TEQ's AWS platform, the interval at which ATDW product changes are detected and propagated to the front end. Rather than a committed service level, and as a configuration it can be adjusted. In addition to the 15 minute polling, there is a Delta reconciliation once per 24 hours. The volume of requests varies depending on seasonality or campaign activity. The daily average volume for the past three months is 225 changes per day.

17. Yes - the business can sustain content freezes. What we would aim for is to minimise the number and the duration. A content freeze for up to 3 days per migration stage would be suitable depending on the frequency.

18. The migration is envisioned by market (for Consumer Sites) and the whole Corporate Site.

19. An audit would be required in this scope. A significant portion is likely unorphaned. A migration can then happen on the updated assets database.

20. Mode and configuration. Adobe Dynamic Media is running in Hybrid mode (not Scene7 mode). The cloud configuration delivers assets via Scene7's Akamai-backed CDN. The integration is predominantly out-of-the-box: DAM workflows follow standard AEM publish-to-DM replication, the Dynamic Media package workflow duplicates assets into DM on publish, and no custom asset renditions are in place.

Preset and profile counts. Based upon AEM Author tools ? Assets there are [0] image presets, [30] viewer presets although these appear unused, [2] video profiles .

Custom configurations. No known bespoke Scene7 configurations exist beyond the standard cloud config. No custom renditions are defined.

Delivery-coupling note (relevant to the target architecture). In the current implementation, Dynamic Media references surface through the SPA component model, components emit Scene7 parameters into the page's JSON delivery output. Vendors should note that this preset reference currently travels via the SPA Editor delivery mechanism. Re-expressing Dynamic Media delivery under proposed RFP outcomes is part of scope and should not be assumed to carry across unchanged.

Known limitation. Hybrid mode does not support Smart Imaging (automatic WebP/AVIF format negotiation). An investigation into switching to Scene7 mode exists but is unresolved; vendors should treat next-gen format delivery as an open item rather than an existing capability.

21. The focus for the UI uplift is a re-skin or re-theme of components and page templates. Outside of any required changes elsewhere in the RFP resulting from the rebuilding of the front end, for this uplift requirement we are looking at visual styling uplift (colour, type, spacing, imagery). Consistency is required between Consumer and Corporate Sites with subtle differences based on the audience of each site. TEQ is not issuing target-state comps as a design guidance. Vendors should represent their own interpretation of the uplift, informed by TEQ brand guidance, the current site, and global tourism best practice, and should show how they would partner with TEQ’s in-house creative team through defined feedback rounds. Noting also that correcting the current boxed desktop layout to full-bleed is a specific deliverable required within this broader work.

22. Creative director, art director, brand lead (TEQ), digital content lead (TEQ), product lead (TEQ).

3 rounds of feedback. TEQ to supply feedback within 48 hours of receipt (business days)

23. The current component library is available on Vendor Panel if you download the Tender Package again. TEQ has a strong visual guidelines guide which will be available to the winning vendor.

24. Mapbox is the current preferred solutions provider. Contract is already in place. Vendor is welcome to propose alternatives if there’s a strong business case.

25. No specific third-party partners have been confirmed as launch-day API consumers. The API is being built for two immediate purposes and one strategic purpose. Immediately, it serves TEQ's own front-end applications and provides structured data feeds that AI systems (ChatGPT, Gemini, Perplexity, Google AI Mode) can crawl and ingest to improve Home | Queensland 's citation rates - this is a core strategic objective, not a future aspiration. Strategically, it establishes Home | Queensland as the canonical, machine-readable source of truth for Queensland tourism data, positioning TEQ to onboard partners, agentic travel platforms, and emerging distribution channels without requiring a rebuild. Expected API call volumes at launch are modest and should be modelled against AI crawler traffic patterns rather than high-throughput partner integrations. The vendor should design for scalability but should not over-engineer for volumes that don't yet exist - TEQ is not seeking an API-as-a-product at launch.

26. Approximately 20 authors across TEQ - distributed model.

27. Design - as above

Content model -five days; approx 5 - 10 stakeholders dependent on item.

28. We have not had a recent accessibility audit. Open to this if within budget.

29. Jira, Confluence

30. Yes - vendor will work within TEQ’s Confluence.

31. SEO content strategy is out of scope and is managed by another agency. If there are SEO and GEO opportunities identified during the project, TEQ will welcome those ideas, however it does not form part of the core scope.

32. No.

33. At launch, a documented and secured endpoint with rate limiting and API key management is sufficient. TEQ does not require a full developer portal with self-service registration, interactive documentation, or automated onboarding for this phase. The API must be clearly documented (endpoint schemas, authentication, rate limits, versioning policy), with API keys issued and managed by TEQ rather than via self-service registration. The architecture must not preclude a developer portal being added later, but building one is not in scope for this project.

34. Similar to our current site approach.

35. queensland.com serves users across the full funnel from inspiration all the way through to the final moment before purchase (via ATDW pages). Design should serve different types of content. The primarily focus for the site is the mid-to-upper funnel stages of the consumer journey. Consideration should be taken that many pages such itineraries, listicles and guides are increasingly LLM sources rather than traffic drivers.

Search pages currently rank well but offer limited filtering to support user interests or travel styles. Lack of content density around key topics such as Brisbane have led to some areas of underperformance.

36. Existing will be largely preserved, however we are open to ideas on refinement and optimisation and would welcome these.

37. TEQ conducted a thorough UX review in 2024 which will be available to the winning vendor. TEQ also has extensive analytics set up which can be access by the winning vendor.

38. Lack of governance means nav structure is not unified across content. Significant amount of semantically similar content / near duplicate content which is being manually updated at the moment.

39. TEQ’s inhouse creative director and art director will offer guardrails (style guide, colours, fonts etc), and have final say over design direction.

40. Assume 1:1 migration however we would be open to template rationalisation and improvement where it makes sense.

41. The engagement is a re-platform: as set out in Sections 6.16, 8 and 10, existing components and templates are to be rebuilt into the selected architecture. On that basis, no component or content structure is required to remain technically unchanged at the implementation level. The relevant requirement is preservation of functionality, SEO equity, and data continuity to a defined standard, not preservation of the existing implementation.

Respondents are referred to Addendum A (Capability Register), which sets the preservation priority for each existing capability (MUST = preserved or replaced with like-for-like or better; SHOULD; NICE). In addition, the following continuity requirements apply and are defined in the tender documents: URL structure and 301-redirect preservation across all 30,000 pages with zero 404s (Sections 5.3 and 10.6); Live Copy inheritance and canonical/hreflang integrity (Sections 6.11 and 10.6); Adobe Analytics data-layer continuity with zero reporting gap (Sections 6.10 and 7.1); retention of Adobe Target, Adobe Launch and OneTrust (Section 7.1); ATDW as the primary source of truth for product data (Section 7.2); and mandatory government co-branding (Addendum A).

Respondents are responsible for determining how their proposed architecture delivers parity-plus against these requirements and for identifying, in their submission, any capability where like-for-like preservation is not proposed, together with the rationale. Where a respondent intends to alter behaviour, structure, or data that falls under a MUST preservation priority, this must be explicitly disclosed and agreed with TEQ. TEQ does not, by this response, waive any preservation requirement set out in the tender documents, and the absence of a specific item from this response should not be read as confirmation that it may be changed.

42. Consumer (Home | Queensland ) and Corporate (Industry ) will have substantial shared foundations rather than two independent builds.

Both sites share a single AEMaaCS instance, component library, deployment pipeline, and infrastructure - it is one architecture with two site configurations, not two separate implementations. The Corporate site (~200 pages, no ATDW, no Live Copy variants) represents incremental effort on top of the Consumer build, with its own templates, content migration stream, and go-live window.

Design system and component library:shared. Both sites draw on a common design system and component library, with Corporate's visual design and component usage being a smaller subset of the Consumer set rather than a separate system. Component and design work is therefore largely reused, not duplicated. The Corporate site is one version only in English.

There are localised templates for the Consumer site - please see attachment within the Tender Download package - (Addendum)TEQ_AEM_Templates-Consumer&_Corporate. Noting these templates are very similar. “Design” - ie. the approach to branding, the component design etc…is consistent globally.

Question:
Referring to page 7 in "Request Summary Report.pdf : "These outcomes do not inherently require AEM, and may be delivered more cleanly through a modern composable architecture using a headless CMS, Next.js and AWS"

May I confirm that AWS is the only chosen technology stack?

Answered on 23/Jun/2026 07:46 AM:


Good morning,

In response to your questions:

1. Vendors must choose between one of the 3 architectures noted in Section 3 of the RFP.

2. TEQ currently uses AWS however we are open to other options if there is a strong case for change.

Question:
Scope & Migration:

1. What is the current live count of ATDW product listing URLs?

2. What is the anticipated steady-state ceiling for ATDW product pages following migration?

3. Does the stated ~2,400 Consumer and ~300 Corporate page inventory represent the current state, or the expected inventory following content rationalisation?

4. Approximately how many authored pages are expected to require manual re-modelling versus automated migration?

5. Are existing translated pages expected to be reused as-is, or is translation review, re-validation, or re-translation within vendor scope?

6. Who will be responsible for translation QA and sign-off?

Design & Components

7. Will TEQ provide an approved design system/Figma library, or is the vendor expected to undertake visual design activities?

8. How many page templates and reusable components are considered in scope, and how many review iterations per template/component should vendors assume?

9. Can TEQ provide a definitive inventory of all components currently utilised across both sites?

Architecture & ATDW

10. Will TEQ accept a vendor-recommended edge runtime approach (e.g. Adobe App Builder, AWS Lambda@Edge, Cloudflare Workers) provided requirements are met?

11. Are there constraints governing this choice, such as data residency requirements, approved technology lists, or hosting restrictions?

12. Is ATDW data expected to be ingested into the Content Bus at build/publish time, or composed dynamically at request time?

Performance

13. For the Core Web Vitals objectives (90+ Lighthouse, LCP 2.0s), will TEQ accept CrUX P75 field metrics as the assessment methodology?

14. For low-traffic ATDW pages without sufficient CrUX data, will Lighthouse/lab-based measurements be considered acceptable?

Cost Model

15. Does the 7 million Content Requests per month threshold apply only to traditional AEM Sites delivery, or also to Edge Delivery Services implementations?

Personalisation

16. Is TEQ open to server-side or edge-decisioning approaches for Adobe Target to minimise client-side flicker?

17. Is an inventory of existing Adobe Target activities available to support scoping of migration effort?

Analytics

18. Can TEQ provide the current data layer specification, Adobe Analytics eVar/prop/event mappings, and Adobe Launch rule inventory?

19. For edge-rendered ATDW pages, is server-side data layer generation required, or is client-side hydration acceptable?

Integrations

20. Are the Bunji chatbot and mapping capabilities expected to be retained as embedded applications, or rebuilt as native components?

21. Following migration, who will own and maintain the Bunji RAG backend and associated OpenSearch vector indexes?

Authoring & Localisation

22. Does TEQ have a preference for which content types should utilise document-based authoring versus Universal Editor, or should vendors recommend an approach?

23. Will TEQ accept a documented inheritance/configuration model as satisfying Live Copy requirements, or is AEM MSM specifically required for the English locale variants?

Security

24. Are there Content Security Policy, script origin, self-hosting, or Web Worker restrictions that vendors should consider?

AWS & Backend Services

25. Is the current AWS estate (Lambda, OpenSearch, API Gateway, EventBridge and related services) within vendor scope to maintain and evolve, or will TEQ retain responsibility for these services?

26. Will vendors be provided access to existing Lambda source code, infrastructure-as-code artefacts, and OpenSearch index configurations?

APIs

27. For the proposed outward-facing content APIs, what are the anticipated consumers, throughput requirements, SLAs, and authentication mechanisms at launch?

28. Is there an existing API contract that must be preserved, or are vendors free to propose a net-new design?

Reviews & Tourism Data

29. Which review providers are approved for use (e.g. ATDW only, Google, TripAdvisor or others)?

30. Does the current ATDW implementation expose pricing and availability data, and if so, what level of freshness can be expected?

Timeline & Resourcing

31. Can build activities commence prior to 25 November 2026, provided final migration/go-live activities occur within the Adobe licence transition window?

32. What level of availability and turnaround can vendors expect from TEQ's website team and two in-house developers during the project?

33. Can the proposed 10-business-day acceptance period be contractually confirmed?

Cutover & Delivery

34. Will TEQ provide an authoritative URL inventory and existing redirect register, or should vendors assume responsibility for deriving these via site crawling?

35. Would TEQ accept content freeze periods by site section during migration and cutover activities?

36. Approximately how frequently is content published today, and what is the anticipated content delta during parallel operations?

37. Would TEQ consider an execution approach where Phases 3–5 are delivered substantially in parallel?

AI-Native Delivery

38. Does TEQ have a preferred AI-assisted engineering toolchain, or are vendors free to propose their own approach, provided artefacts remain portable and maintainable?

39. For Option C, what level of operational complexity associated with dual-CDN DNS routing is considered acceptable for TEQ's ongoing support model, and would documented runbooks satisfy maintainability requirements?

Answered on 25/Jun/2026 03:17 PM:


1. Queensland has approximately 9,220 displayed on queensland.com then replicated across international versions.

See addendum:  DEPT_url _report_RFP_Question.xlsx

2. 9,220 displayed on Home | Queensland then replicated across international versions 

3. Please note the 2.4k compromises of approximately 1.2k English pages, 200 translated pages (6 markets x 200), and 300 corporate pages (current state). At this stage assume 1:1 migration of all pages.

4. I believe this is a question for the vendor to advise on, not TEQ.

5. Translated language content expected to be reused as-is. Noting these ‘pages’ may need remodelling for content fragment implementation.

There may be opportunity to better optimize how translations are implemented into the website. Opportunity but not a requirement - TEQ is open to ideas from vendors, for example, AI-driven translations.

6. Vendors will be responsible, with TEQ running a final check to determine acceptance criteria has been met.

7. The focus for the UI uplift is a re-skin or re-theme of components and page templates. Outside of any required changes elsewhere in the RFP resulting from the rebuilding of the front end, for this uplift requirement we are looking at visual styling uplift (colour, type, spacing, imagery). Consistency is required between Consumer and Corporate Sites with subtle differences based on the audience of each site. TEQ is not issuing target-state comps as a design guidance. Vendors should represent their own interpretation of the uplift, informed by TEQ brand guidance, the current site, and global tourism best practice, and should show how they would partner with TEQ’s in-house creative team through defined feedback rounds. Noting also that correcting the current boxed desktop layout to full-bleed is a specific deliverable required within this broader work. Noting TEQ has an up-to-date brand guidelines that will be shared with the winning vendor.

8. All existing templates and components are considered in scope.

9. A library of components and a listing of templates is available within the Tender download package on Vendor Panel if you download the Tender Package again.

10. Yes, TEQ will accept this provided requirements are met.

Best approach is to enumerate which functions run at the edge, on which platform, at which tier; the principle to consider is "lowest tier that does the job, with escalation justified per function"

11. TEQ operates under QGEA policies as a statutory body. The data processed by this platform is predominantly publicly available tourism content with limited personal information (name, email). Vendors must ensure Australian data residency (ap-southeast-2) and compliance with the Australian Privacy Act 1988. The vendor's proposed stack must not include products on the Queensland Government Restrictions List. TEQ does not maintain a separate approved technology list beyond these requirements - vendors are free to propose their preferred technology stack.

12. TEQ does not prescribe the composition approach - this is an architectural decision the vendor must make and justify for their chosen option. However, ATDW data updates approximately 1,000 listings per month, so whichever approach is proposed must ensure product pages reflect current data without manual author intervention. Regardless of composition timing, ATDW product data must be treated as structured entity content - not raw HTML injection - so that each product page generates Schema.org markup (TouristAttraction, Offer, Place) server-side in the initial HTML payload, with entity properties (price ranges, coordinates, availability, descriptions) queryable via the outward-facing content API. The vendor should describe how ATDW data flows from API source through to structured, AI-readable page output, including the maximum staleness window and how this scales as update frequency increases.

13. TEQ will accept both measurement methodologies. Lighthouse lab scores (90+, LCP 2.0s, INP 200ms, CLS 0.1), measured via pagespeed.web.dev using mobile device simulation, are the acceptance gate at UAT and go-live. This is a controlled, reproducible measurement that can be validated before launch when no field data exists. No alternative Lighthouse configuration is accepted - pagespeed.web.dev mobile is the standard. In conjunction with Lighthouse lab scores, CrUX P75 field metrics can be used for ongoing performance benchmarking post-launch and will be the basis for performance discussions during hypercare. CrUX targets must also meet the same thresholds once sufficient field data has accumulated (typically 28 days post-launch).

14. Yes

15. It applies to all implementations. Please detail in your response if 7M Content Requests per month poses a concern. The vendor will ultimately be responsible for delivering a site that achieves the stated objectives within the threshold so any concerns should be noted in pitch stage.

16. Yes, TEQ is open to and would welcome server-side or edge-decisioning approaches for Adobe Target as Adobe Target is currently implemented through WebSDK. The RFP does not prescribe the implementation method - the vendor must recommend and justify their approach based on what best achieves the CWV targets (particularly CLS 0.01) while maintaining full personalisation capability. Server-side or edge-decisioning approaches that eliminate visible content flicker are preferred over client-side approaches that require flicker-mitigation workarounds. The vendor should describe their recommended approach, any trade-offs in personalisation capability, and provide evidence of achieving comparable CWV scores on prior implementations.

17. None to migrate.

18. See Addendum item TEQ_Data_Mapping_AEP_Web_SDK_v2.

19. All structured data (schema.org, JSON-LD, entity properties, pricing, availability) must be generated server-side and present in the initial HTML payload - this is non-negotiable and applies equally to ATDW pages as to editorial pages. Client-side hydration of entity content is not acceptable because LLM bots that do not execute JavaScript would see an empty product page. The analytics data layer (Adobe Analytics/GA4 event variables) is inherently client-side and may be populated on page load from the server-rendered content, but the underlying product data from which it derives must already be in the page source.

20. The Bunji AI chatbot is to be retained as-is. There is no expectation for the vendor to re-skin, rebuild, or replace it as part of this engagement, and no such effort should be included in pricing.

The vendor should, however, preserve Bunji's existing integration and embed point on the replatformed site so that current chatbot functionality carries over without regression. Beyond maintaining that integration so it continues to operate as it does today, no work on the chatbot itself is in scope.

Bunji’s current retrieval layer draws from the queensland.com consumer website OpenSearch/Elasticsearch index. The index contains vectorised website page content, with embeddings appended to the relevant JSON records for retrieval by the chatbot’s RAG model.

The primary structured content source currently included is ATDW operator data, limited to BOQE (Best of Queensland Experience) operators to preserve response quality. ATDW events are also included.

Bunji uses Azure OpenAI services for embedding/tokenisation and conversational response generation. Conversation logs are stored separately in Google BigQuery and backed up to S3; these logs are used for reporting and analysis, not as the primary retrieval index for chatbot answers.

Ingestion pipeline mechanics must be adapted to align with the new content delivery model. The vendor will ensure that the automated discovery, parsing, chunking, and embedding of new or modified content, including both static web pages and dynamic data feeds, functions seamlessly without any loss of existing capability or data freshness.

21. It is intended for TEQ to own and maintain the Bunji RAG and OpenSearch following the migration.

22. Document-based authoring would appear most suitable for editorial style content within Queensland.com.

Vendors can recommend the approach for other page types.

23. AEM MSM (Multi Site Manager) with Live Copy is the expected approach. TEQ currently operates 6 English locale variants using Live Copy inheritance and the RFP requirement is that this inheritance model is preserved through the migration, not rebuilt as a custom solution. AEMaaCS includes MSM as a core platform feature - there is no technical or licensing reason to replace it with a bespoke inheritance mechanism. If the vendor's chosen architecture presents a specific constraint that prevents standard MSM usage, they must detail this in their response, explain the proposed alternative, and demonstrate that it delivers equivalent functionality including selective override at page and component level, automatic propagation of master content changes, rollout configurations, and conflict resolution.

24. Content Security Policy. Respondents are referred to Section 5.2. A default Content Security Policy enforcing OWASP Top 10 controls and XSS prevention is a mandatory requirement, and all code must achieve and maintain an Adobe Cloud Manager Security Rating of A. TEQ does not prescribe a specific CSP; the respondent is responsible for designing, implementing, and enforcing a CSP appropriate to the proposed architecture that satisfies these mandatories in full. The final policy will be agreed with TEQ during the design phase. Respondents should describe their proposed CSP approach in their submission.

Script origins. The respondent is responsible for auditing the current third-party tag and script estate (refer Addendum A, Section 07, and related entries) and for deriving and maintaining the complete set of permitted script origins required to deliver the solution. As noted in Addendum A, the existing tag stack is to be audited and rationalised rather than carried forward without review; respondents should not assume any current tag is in scope without confirmation. Third-party script governance is to be administered through Adobe Launch (or equivalent tag management) with OneTrust consent enforcement, consistent with Sections 6.10 and 7.1. Responsibility for ensuring all required and approved origins function within the enforced CSP rests with the respondent.

Self-hosting. TEQ does not prescribe a self-hosting approach. The respondent is to propose the script, font, and asset delivery model that best satisfies the security, CSP, and Core Web Vitals mandatories (Sections 5.1 and 5.2), the credential-management requirements (Section 6.15), and the encryption standards (Section 5.2). Any delivery approach proposed must be justified against these requirements.

Web Workers. TEQ does not impose a specific Web Worker restriction. The respondent remains fully accountable for meeting the Core Web Vitals mandatories (LCP 2.0s, INP 200ms, CLS 0.1, Lighthouse 90+ — Section 5.1) and, for any EDS-based delivery (Options B and C), for preserving the EDS performance and JavaScript model. Any use of client-side workers, edge workers, or serverless compute is at the respondent's discretion provided all performance mandatories and the chosen architecture's constraints (Sections 5.1, 7.2, 7.3) are met. Respondents should describe their approach to dynamic content composition and any associated compute model.

25. The vendor is responsible for ensuring all existing AWS services (Lambda, OpenSearch, API Gateway, EventBridge) function correctly within the new architecture at launch, including any modifications or rebuilds required by the new content model - for example, if the move to Content Fragments changes the data structures flowing into OpenSearch or the Lambda ETL pipeline, those updates are within vendor scope. If the vendor's architecture requires new AWS resources that do not exist today (e.g. new Lambda functions for an aggregation layer, new CloudFront distributions), provisioning and configuring those is also within vendor scope. All AWS services must be delivered with Infrastructure as Code (CDK/Terraform) and documentation sufficient for TEQ's team to operate independently. Post-hypercare, TEQ retains operational responsibility for the AWS estate and ongoing AWS costs.

26. Yes - full access details, credentials, and onboarding will be arranged upon contract execution. These will not be provided during the RFP evaluation stage.

27. At launch, the anticipated API consumers are TEQ's own front-end applications (Home | Queensland and Corporate site), and AI crawlers and LLM training/inference systems (GPTBot, Google-Extended, PerplexityBot, Gemini), A small number of known strategic partners are expected within first 12 months and should be accounted for in planning. TEQ does not anticipate high-throughput external consumer traffic at launch - this is not a public developer API with unknown third-party consumption. Throughput requirements should be modelled against TEQ's current traffic profile (17M page views per year) plus an allowance for growing bot traffic. Specific throughput targets and SLAs will be jointly defined during Phase 1 based on the vendor's architecture and TEQ's operational requirements. Authentication should use API key-based access for external consumers, with keys issued and managed by TEQ. The API must support rate limiting per consumer to protect against unexpected load. TEQ is not seeking OAuth, JWT token exchange, or self-service registration at this stage.

28. This design freedom applies to the CMS-to-frontend delivery layer only. The following integration boundaries are fixed and must be respected:

ATDW remains the product data source of truth; TEQ's editorial override capability over ATDW data must be retained.

The Bunji AI chatbot is retained as-is; its current embed/integration point must be preserved.

Dynamic Media (Scene7) asset delivery is retained.

Existing translation integration (GlobalLink/TransPerfect) is to be re-established under AEMaaCS; the connector itself may change, the roundtrip capability must not be lost.

Where any existing endpoint is consumed by a downstream or third-party system, TEQ will specify that contract separately; such contracts must be maintained or formally deprecated through change control.

29. TEQ are open to considering a range of review providers, but likely an established and trusted source such as Google and/or TripAdvisor. A recommendation would be welcomed.

31. Yes

32. TEQ's internal team comprises a Project Manager, Product Owner, Data Leader, two in-house developers, and a Website Specialist, supporting the Director. This team retains responsibility for business-as-usual operation and support of the live consumer (Home | Queensland ) and corporate (Industry ) sites for the duration of the programme. Accordingly, the team's project availability is a defined allocation, not full-time, and TEQ developers should not be resourced as an embedded part of the vendor's delivery team.

TEQ anticipates the following indicative turnaround on clearly scoped, batched requests raised through the agreed project channel. Turnaround is measured from receipt of a well-formed request; ambiguous, unbatched, or incomplete requests will be returned for clarification and the clock restarts on resubmission.

Editorial / content / scope clarifications (Website Specialist, Product Owner): [1–2] business days.

Technical access, environment, and configuration queries (Product Owner; in-house developers, around BAU commitments): [2–3] business days.

Decisions and approvals requiring TEQ sign-off (Director / programme governance): addressed at the standing weekly programme sync, or within [3–5] business days where out-of-cycle.

Items requiring external governance — security review, procurement or contract sign-off, data-sovereignty determinations, change-advisory approval: these follow TEQ governance cadences and are not within the website team's turnaround control. TEQ will flag these as governance-dependent at the point they arise and provide the expected timeframe case by case.

TEQ will operate a standing weekly programme sync plus a triage channel for day-to-day queries. To enable the turnaround above, the vendor is expected to batch related queries, raise blockers through the agreed channel with sufficient context to action without a follow-up round-trip, and give reasonable notice for anything requiring developer environment access.

33. The 10-business-day acceptance period will be contractually confirmed in the MSA for both parties. Formal submission of phased deliverables will be required. Formal submission means the vendor has provided written notification that deliverables are complete and ready for review - the clock does not start on partial or in-progress submissions. If TEQ identifies a blocking defect within the acceptance period that prevents substantive review (e.g. staging environment unavailable), the acceptance period pauses until the vendor confirms resolution. One exception to be discussed during contracting is a scenario where multiple Phases are being delivered concurrently - in this case the 10-business-day acceptance period would compound (ie. two phases at the same time = 20 business day acceptance period). Additionally - Phase 6 “UAT, SEO & GEO Validation, Observability, Security, Compliance” - in the case of 12 sites being delivered simultaneously to TEQ, we will need to agree on the appropriate acceptance period as 10-business days would not suffice. Utimately we are a small team internally so we need to manage around our resourcing.

34. Yes

35. Yes - As stated in Section 6.5, the vendor owns content migration end-to-end, including all programmatic and manual re-modelling of existing authored content into the new structured schema. TEQ content authors are not a resourcing assumption for migration delivery. TEQ's role is limited to final checks - validating that migrated content is accurate, complete, and correctly structured in the new model. If specific pages or content types require manual re-authoring to fit the new content schema, that effort sits with the vendor as part of the fixed-price scope. The vendor should factor this into their migration strategy and pricing.

36. 3 - 7 articles published and/or updated daily, 5 days a week. We expect this to continue during parallel operations. Noting the majority of new articles are English sites only.

37. This would need to be discussed during project initiation. TEQ are a small team internally - if the vendor needs TEQ’s support during a project phase, this becomes unservicable with 3 phases running concurrently and will ultimately reduce the quality of the project outcome. We are open to discussions on some level of concurrent progress however this would be subject to detailed analysis by the vendor for TEQ to understand this in detail before providing a commitment.

38. TEQ does not mandate a specific AI engineering toolchain. Vendors are free to propose the tools that best suit their delivery approach, provided three conditions are met: all AI context files, system prompts, custom skills, and configuration must be fully handed over to TEQ at project completion; the toolchain must not create proprietary dependencies that prevent TEQ's team from switching tools post-launch; and the repository must be structured for AI-assisted development regardless of which specific tool is used (clear context files, documented architecture decisions, coding standards, and component conventions that any major AI coding tool can consume).

39. TEQ acknowledges that Option C carries the highest operational complexity of the three options and expects vendors proposing it to address this directly. Documented runbooks are a necessary but not sufficient condition. TEQ requires the DNS routing configuration to be managed via Infrastructure as Code (not manual DNS console changes), the routing logic to be simple and deterministic (path-based rules mapping defined URL patterns to the correct CDN layer, not dynamic or conditional routing), the configuration to be changeable by TEQ's two-person team without vendor assistance for routine operations (e.g. moving a new page type to the appropriate layer), and monitoring and alerting that surfaces routing failures before they impact users. The vendor must demonstrate in their response that the day-to-day operational burden of maintaining dual-CDN routing is proportionate to a two-person engineering team and does not require specialist DNS or CDN expertise beyond what the runbooks and IaC templates provide.

Question:
Do the consumer and corporate website need to go live together or can they go live with a time gap?

Is there a preference for a specific set of country+language website that you would like to go live with in first tranche.?

Section 9.4 invites an Agile, Scrum or hybrid methodology, while Section 11 structures delivery and payment around phase-gated acceptance. To align our proposed ways of working with TEQ's expectations, can TEQ confirm how it sees agile delivery operating within the phase-gate commercial model, in particular: the expected level of TEQ product-owner or business involvement during sprints, and whether incremental acceptance within a phase is possible rather than a single sign-off at phase end?

What is the typical frequency of content changes in AEM and data changes in ATDW currently?

Does TEQ have current, documented brand guidelines, and do these extend to digital as a design system, UI patterns, or component-level specifications, or are they primarily print / brand-identity level?

Section 6.7 and Phase 3 reference design approval through TEQ's in-house creative team. To support an iterative design approach, can TEQ confirm the availability and cadence of its creative team for in-sprint design reviews (for example, regular working sessions versus formal milestone sign-offs), and whether a single design authority can give in-sprint direction and approval?

Section 6.7 references uplift of 40+ components and templates. Can TEQ confirm whether the intent is a visual restyle of existing component structures, or whether structural / layout redesign is anticipated, and confirm the list of net-new components to be designed from scratch (e.g. in-article video, price/value, reviews, enhanced maps)?

Beyond visual designs for key page types, does TEQ expect delivery of a formal design system (design tokens, documented component library, Figma library) within the fixed-price scope, or is the design deliverable comps plus the component usage rules documented in the Playbook?

Does TEQ have a preferred AI / LLM provider that we should be aware of while planning / proposing any AI features for the platform?

Will we have access to current React SPA and Lambda codebase if we win the engagement?

Is TEQ okay with the implementation partner using AI tools for coding / development. E.g. Cursor / Claude Code

Section 2 describes current content as semi-structured and display-ready, while Addendum A references existing AEM Content Fragments and Schema.org JSON-LD for several entity types. To allow accurate fixed-price scoping of content re-modelling, can TEQ indicate, across the approximately 2,400 authored pages on the Consumer and Corporate sites, the proportion currently authored in structured Content Fragments versus display-oriented components, and TEQ’s expectation for how many pages will require manual re-authoring into the new structured model versus programmatic migration?

Section 6.5 states the vendor owns content migration with “final checks only” by TEQ. Can TEQ confirm whether TEQ content authors contribute to manual re-authoring effort, or whether the full manual re-modelling of authored pages into the new content schema sits with the vendor?

Section 6.5 requires incremental migration with parallel operation of old and new architectures. Can TEQ indicate what content-freeze duration, if any, its marketing calendar can tolerate per site section during cutover?

For the six translated-language variants (~200 pages each), can TEQ confirm whether translations are vendor-managed, TEQ-supplied, or handled by a third-party translation vendor, and whether re-translation is expected where source content is re-modelled?

Following the release of the current-state component and capability inventory, can TEQ confirm whether this inventory is considered the definitive and complete scope baseline for the parity-plus requirement in Section 5.5, or whether it is indicative only?

To inform the content model and entity design, can TEQ confirm whether the following exist and can be shared with respondents (or shortlisted respondents): current digital or content strategy, audience segmentation or personas, customer journey maps or service blueprints, content audit or inventory, and any GEO/AEO or AI-citation baseline analysis? Where such artefacts do not exist, can TEQ confirm whether their creation is expected within the fixed-price scope?

Answered on 25/Jun/2026 02:52 PM:


1. The consumer website should go live first, followed by the corporate. Please note all sites need to go live within a 12-month migration window. There are a number of language variations for the Consumer site so we expect these would be released also in a staged way.

2. English language first including our 6 English language live copy sites. Then we would agree on a sequence between our 6 translated sites.

3. TEQ sees agile delivery and phase-gated acceptance as complementary. Within each phase, the vendor should operate using their preferred agile methodology (sprints, iterative delivery). The phase acceptance criteria and payment gates apply to the cumulative output at phase end.

TEQ will provide a dedicated product owner available for weekly syncs and fortnightly sprint reviews, with authority to make prioritisation decisions and provide feedback on sprint deliverables.

TEQ is open to incremental sign-off of deliverables within a phase (e.g. progressively accepting individual templates during Phase 4 as they are completed). This gives the vendor earlier confirmation that work meets expectations and reduces the review burden at the phase gate. However, incremental sign-offs are confirmations that the vendor should proceed - they do not constitute contractual acceptance and do not limit TEQ's right to raise integration, performance, or consistency issues at the phase acceptance gate. Payment remains tied to the phase acceptance criteria being met in full.

4. 3 - 7 articles published and/or updated daily, 5 days a week. ATDW is around 225 changes per day on average however single days can hit 5k per day or more if there's a campaign or specific reason.

5. TEQ has up-to-date brand guidelines. These are primarily brand identity level. We do have a component library with functional specifications. They do not extend to digital as a design system, UI patterns, or component-level design specifications.

6. TEQ will be happy to support in-sprint design reviews including regular working sessions. Formal milestone approvals will still be required at stage gate. Our design lead can provide in-sprint direction however formal approval would require the involvement of our creative director will may be at milestones.

7. The focus for the UI uplift is a re-skin or re-theme of components and page templates. Outside of any required changes elsewhere in the RFP resulting from the rebuilding of the front end, for this uplift requirement we are looking at visual styling uplift (colour, type, spacing, imagery). Consistency is required between Consumer and Corporate Sites with subtle differences based on the audience of each site. TEQ is not issuing target-state comps as a design guidance. Vendors should represent their own interpretation of the uplift, informed by TEQ brand guidance, the current site, and global tourism best practice, and should show how they would partner with TEQ’s in-house creative team through defined feedback rounds. Noting also that correcting the current boxed desktop layout to full-bleed is a specific deliverable required within this broader work.  The approximate list of net-new components includes in-article video, price/value, reviews, enhanced maps.

8. TEQ does not expect a formal design system in the fixed-price scope. Components plus the specifications and usage rules documented in Confluence/Playbook will be sufficient.

9. TEQ does not mandate a specific AI/LLM provider. Vendors are free to propose the platform that best suits the use case, provided it does not appear on the Queensland Government Restrictions List (DeepSeek is currently prohibited on all Queensland Government systems). TEQ's internal team currently uses Anthropic Claude for AI-assisted development and content workflows and Google Gemini withing GCP instance, but this does not constrain the vendor's proposal.

Any proposed LLM integration must be architecturally compatible with TEQ's existing data and content ecosystem. Specifically, the LLM must be consumable via API from AEM authoring workflows (e.g. content generation, metadata enrichment, or translation assistance triggered within the CMS), capable of receiving structured inputs from TEQ's BigQuery data lake (analytics insights, content performance data, demand signals) and Microsoft platforms as part of automated content workflows, and integrated via documented API middleware rather than point-to-point connections, so that the orchestration layer can route to a different LLM provider without rearchitecting the upstream data flows or downstream CMS ingestion.

10. Yes. Upon contract execution, the successful vendor will be granted full read access to the current React SPA codebase, AEM component library, and all Lambda function source code via TEQ's existing repositories, as well as read-only access to the relevant AWS console (Lambda configurations, OpenSearch index schemas, API Gateway definitions, EventBridge rules). Access will be provided during Phase 1 (Discovery) under the confidentiality terms of the MSA.

11. Yes, TEQ encourages the use of AI-assisted development tools and expects to see the consequent benefits in project pricing. The RFP includes an explicit requirement for an AI-native development environment and TEQ expects vendors to leverage AI tooling to improve delivery speed, code quality, and cost efficiency. Vendors are free to use their preferred tools during the build (Cursor, Claude Code, Copilot, or equivalent), provided all AI-generated code passes the same CI/CD quality gates as human-written code, and the repository is structured with context files (e.g. CLAUDE.md) that enable TEQ's team to continue AI-assisted development post-handover.

12. TEQ acknowledges this is an important scoping input. The current site is predominantly built on display-oriented AEM page components consumed via model.json - this is the primary content architecture for both Consumer and Corporate sites. A small number of Content Fragments and limited Schema.org - Schema.org markup exist, but these should be treated as exceptions rather than representative of the overall content model. Content Fragments in the current state are used for our website classification layers (for dynamic content & product display - for example within Carousels), rather than for structuring page content. For fixed-price scoping purposes, vendors should assume that the substantial majority of the ~2,400 authored pages will require content re-modelling from display-oriented components into structured Content Fragments or the equivalent content model in their chosen architecture. TEQ expects the vendor to propose a migration approach that maximises programmatic migration (scripted extraction from the existing JCR/component structure into new CF models) with manual re-authoring limited to pages where the content transformation is too complex for automated tooling. The vendor's discovery phase must include a detailed content audit quantifying the exact split and informing the migration plan. TEQ will provide full access to the current AEM environment during discovery for this purpose.

13. As stated in Section 6.5, the vendor owns content migration end-to-end, including all programmatic and manual re-modelling of existing authored content into the new structured schema. TEQ content authors are not a resourcing assumption for migration delivery. TEQ's role is limited to final checks - validating that migrated content is accurate, complete, and correctly structured in the new model. If specific pages or content types require manual re-authoring to fit the new content schema, that effort sits with the vendor as part of the fixed-price scope. The vendor should factor this into their migration strategy and pricing.

14. The business can sustain content freezes. We would aim for is to minimise the number and the duration. A content freeze for up to 3 days per migration stage would be suitable depending on the frequency.

15. Currently translated language pages are human translated; machine translation is not used yet at scale. Translation happens through two channels:

In-house: TEQ's existing international team performs translations, drawing on their in-market language expertise.

Third-party (TransPerfect): pages requiring manual translation are sent directly from AEM. The GlobalLink Connect adaptor sits within AEM and communicates with TransPerfect's Project Director via web services, dispatching content for human translation and returning the translated pages into AEM.

For this project, translations are vendor-managed however we expect the current translated content would be re-used. Where source content is re-modelled the vendor would manage the translations with TEQ approval gates. TEQ would require consultation on this as translations need to conform to quality measures. AI-based translations would be acceptable if they can achieve our quality measures.

16. The current-state component and capability inventory shoudl be considered close to complete - it is indicative however it would be very close to the full list. Please take note that the RFP has a number of net-new components.

17. A formal content audit does not currently exist. Conducting this audit is within the vendor's scope - Section 9.2(c) requires the vendor's methodology for auditing existing unstructured data, and Section 10.3(d) specifically asks how the vendor will audit the existing AEM component library and map components to semantic content types. The audit is a prerequisite to the Phase 1 acceptance criteria (approved content model and approved migration plan). TEQ will provide full access to the current AEM environment during discovery for this purpose. Existing strategic documentation (digital strategy, audience segmentation, GEO/AI citation baseline data) will be shared with the shortlisted vendor during Phase 1. Customer journey maps will be shared where they exist but should not be assumed to be comprehensive. Creation of new strategic documents (content strategy, personas, journey maps) is not within the fixed-price scope - the vendor is expected to deliver a content model informed by TEQ's existing strategy, not to develop the strategy itself.

Question:
1. Will TEQ accept attached supporting information in addition to the requested response?

2. Are the following AEM 6.5 native features (MSM, Multistep approval, scheduling) used in TEQs current day-to-day editorial operations?

3. The RFP states that the architecture “must not foreclose AWS Neptune knowledge graph implementation (optional Phase 2)”. Can TEQ clarify how the knowledge graph is expected to interact with search, specifically, whether it will augment OpenSearch as an entity/relationship enrichment layer, or if there is a long-term intent for it to play a more central role in search and discovery?

4. Is there any existing research (qual/quant), customer segments and journeys that we can leverage to inform some of the design decisions?

Answered on 25/Jun/2026 02:49 PM:


1. No - RFP responses need to conform the specific information requested.

2. Yes, these features are currently enabled and used today.

3. As set out in Section 10.15, the AWS Neptune knowledge graph is optional Phase 2 scope and is not part of the fixed-price engagement. TEQ may commission it as separate works following the primary engagement. The only requirement applying to the primary engagement is that the proposed architecture must not foreclose a future knowledge graph implementation (Sections 7.3 and 8).

To the extent the tender documents articulate an expected purpose, Section 10.15 describes the knowledge graph as supporting automated http://Schema.org generation, unified entity-relationship management across ATDW and editorial data, and an external knowledge graph API for third-party and AI-agent consumption. OpenSearch is identified throughout as the site search index (Sections 6.8 and 7.3). On that basis, a future knowledge graph would be expected to operate as an entity and relationship enrichment and outward-facing entity API layer complementing the search index, rather than as a replacement for it.

TEQ does not, by this response, commit to a definitive long-term role for the knowledge graph in search and discovery; any such role would be determined by TEQ at the time the optional scope is considered. Respondents are responsible for ensuring their proposed Phase 1 architecture, including the entity-first content model and entity-relationship integrity, preserves the option for a future knowledge graph implementation without requiring TEQ to commit to a target end-state. Respondents may, under Section 10.15, provide an indicative approach and pricing for the knowledge graph as separate optional scope.

4. Yes, absolutely. We can provide the successful vendor with research insights on TEQ's primary markets and travel party segments including behaviour on the consideration journey. In 2024 TEQ undertook primary research to help inform updates on http://Queensland.com . Some of these consumer insights can be shared with the successful vendor.

Question:
Do the consumer and corporate website need to go live together or can they go live with a time gap?

Is there a preference for a specific set of country+language website that you would like to go live with in first tranche?

What is the typical frequency of content changes in AEM and data changes in ATDW currently?

Does TEQ have an written and upto date brand guildelines / style guide?

Does TEQ have a preferred AI / LLM provider that we should be aware of while planning / proposing any AI features for the platform?

Will we have access to current React SPA and Lambda codebase if we win the engagement?

Is TEQ okay with the implementation partner using AI tools for coding / development. E.g. Cursor / Claude Code

Answered on 23/Jun/2026 02:48 PM:
(edited on 24/Jun/2026 03:47 PM)


Good afternoon,

In response to your questions:

1. The consumer website should go live first, followed by the corporate. Please note all sites need to go live within a 12-month migration window.

2. The consumer English sites would be the first priority.

3. 3 - 7 articles published and/or updated daily, 5 days a week. ATDW is around 225 changes per day on average however single days can hit 5k per day or more if there's a campaign or specific reason.

4. Yes - these will be available to the successful vendor.

5. TEQ is open to various ideas for further discussion through the process.

6. Yes. Upon contract execution, the successful vendor will be granted rea6 access to the current React SPA codebase, AEM component library, and all Lambda function source code via TEQ's existing repositories, as well as read-only access to the relevant AWS console (Lambda configurations, OpenSearch index schemas, API Gateway definitions, EventBridge rules). Access will be provided during Phase 1 (Discovery).

7. Yes, TEQ encourages the use of AI-assisted development tools and expects to see the consequent benefits in project pricing. The RFP includes an explicit requirement for an AI-native development environment and TEQ expects vendors to leverage AI tooling to improve delivery speed, code quality, and cost efficiency. Vendors are free to use their preferred tools during the build (Cursor, Claude Code, Copilot, or equivalent), provided all AI-generated code passes the same CI/CD quality gates as human-written code, and the repository is structured with context files (e.g. CLAUDE.md) that enable TEQ's team to continue AI-assisted development post-handover.

Thank you,

TEQ