A Hotel Technical Services Agreement is one of the most important yet least understood components of hotel development. It governs the period between the initial concept and the opening, when the operator or its technical services affiliates become actively involved in shaping the design, specifications, and operational readiness of the hotel. While often perceived as a supporting document to the management or franchise agreement, in practice, it plays a defining role in how the asset is ultimately delivered.
Depending on the operator, this agreement may be referred to as a Technical Services Agreement (TSA) or a Technical Assistance Services Agreement (TASA). The terminology varies, but the function is consistent: to ensure the hotel is designed and constructed to meet brand standards and operate efficiently once opened. It is through this agreement that the brand begins to translate from concept into physical reality.
Despite its importance, the TSA is frequently under-negotiated compared to the hotel management agreement. Developers and operators focus heavily on fee structures, performance tests, and termination rights under the HMA, while the TSA is often agreed at an earlier stage with less scrutiny. This imbalance can create problems later, as many of the highest-cost, design, and operational decisions are made during the technical services phase rather than in operation.
- What is a Hotel Technical Services Agreement?
- Relationship to Management and Franchise Agreements
- Timing and Alignment with Management and Franchise Agreements
- Access to Brand Standards, Systems and Technical Expertise
- Uncertainty and Early-Stage Drafting
- Hotel Technical Services Agreement Terms
- Scope of Services
- Scope of the Hotel Project and Approval Process
- Owner’s Undertakings
- Consultant’s Undertakings (Operator Responsibilities)
- Design Standards
- Technical Services Fee
- Payments and Tax Structure
- Term and Termination
- Continuing Effect of Technical Provisions Beyond Termination
- Limitation of Liability
- When Technical Services Agreements Go Wrong
- Schedules and Exhibits
- Sample Clauses in the Hotel Technical Services Agreement
- Core Takeaways
For developers, the TSA sits at a critical intersection. It is where design, cost, and brand requirements converge, and where the operator’s influence is most direct, yet also where its responsibility is most limited. Understanding how the agreement is structured and how it operates in practice is essential to managing both development risk and long-term asset performance.
What is a Hotel Technical Services Agreement?
A Hotel Technical Services Agreement is a contract under which the operator provides advisory, review, and approval services during the planning, design, construction, and pre-opening phases of a hotel project. It is typically entered into before the hotel becomes operational and is distinct from the management or franchise agreement that governs day-to-day operations after opening.
At its core, the TSA reflects a structured division of responsibilities. The operator contributes brand standards, operational expertise, and design input, while the developer is responsible for delivering the project. The operator does not construct the hotel, appoint contractors, or take on development risk. Instead, it reviews and comments on the developer’s work, ensuring alignment with brand and operational requirements.
This distinction is fundamental and often misunderstood. The operator’s involvement can be extensive, influencing everything from room layouts and back-of-house functionality to systems infrastructure and guest experience. However, this influence is exercised through guidance and approval rather than execution. The developer retains full responsibility for cost, programme, technical compliance, and delivery, even where decisions are heavily shaped by operator input.
This creates a dynamic that sits at the heart of the TSA. The operator defines what the hotel should be, while the developer is responsible for how it is delivered. Managing this relationship effectively is one of the principal challenges of hotel development.
Relationship to Management and Franchise Agreements
The TSA is closely linked to the Hotel Management Agreement or franchise agreement and is typically executed before or alongside these documents. While the HMA governs the operation of the hotel once it is open, the TSA governs the creation of the asset itself. Together, they form a continuous contractual framework that spans the full lifecycle of the hotel.
This relationship is not merely sequential but interdependent. Decisions made under the TSA, particularly regarding design, layout, and systems, directly affect how the hotel will operate under the HMA. Room sizes, circulation flows, staffing requirements, and service delivery models are all influenced during the technical services phase, long before the hotel begins trading.
From a developer’s perspective, this creates a structural dependency. The TSA effectively sets the parameters within which the HMA will operate. If those parameters are not aligned with the developer’s commercial objectives, the consequences may only become apparent once the hotel is operational. For this reason, the TSA should be considered as strategically important as the management or franchise agreement, rather than as a preliminary or secondary document.
Timing and Alignment with Management and Franchise Agreements
The Technical Services Agreement is typically executed alongside or shortly before the Hotel Management Agreement or franchise agreement, and operators strongly prefer that these agreements be aligned in timing as part of a single, coordinated contractual package. This reflects the operator’s fundamental position within the development process. Hotel operators are not developers or commercial consultants, and while the TSA governs how the asset is designed and prepared for opening, the management or franchise agreement defines their long-term role and economic interests. Without that alignment, the operator risks contributing its standards, systems, and expertise to the development of an asset that it may not ultimately operate.
Operators often emphasise that the TSA is not intended to be a profit centre, with fees positioned as a cost-recovery mechanism for the technical services team rather than a standalone commercial return. This reinforces their reluctance to enter into a TSA in isolation. In practice, when developers seek to advance the design before finalising the operating agreement, operators are more likely to provide limited, informal, or preliminary technical input rather than fully executing a standalone TSA. This approach allows early-stage design work to continue while avoiding the risk of effectively developing a hotel for another party.
There are, however, situations where a TSA may be executed independently, typically when the project has advanced to a stage where access to detailed design standards, documentation, and specialist technical input is critical to maintaining programme momentum. While this is less common, it reflects the realities of development timelines and the need to avoid delay. Even in these cases, operators will usually seek to limit their exposure through conditionality, restricted scope, or alignment mechanisms linked to the eventual execution of the management or franchise agreement. The underlying principle remains consistent: the TSA is not intended to stand alone but to form part of a wider, integrated relationship that extends into the hotel’s operational phase.
Access to Brand Standards, Systems and Technical Expertise
One of the most important, and often underappreciated, functions of the Technical Services Agreement is that it provides the developer with structured access to the operator’s intellectual property, technical frameworks, and accumulated operational knowledge. This access is not incidental; it is the mechanism through which a hotel transitions from a generic real estate concept into a branded, operationally viable asset.
Hotel operators maintain extensive bodies of documentation covering design standards, planning guidelines, engineering specifications, IT architecture, safety protocols, and operational workflows. These materials are typically the result of decades of refinement across multiple markets, asset types, and operating conditions. They are not static documents, but evolving frameworks informed by performance data, guest feedback, and operational experience. Through the TSA, these standards are made available to the developer in a structured, controlled manner, forming the foundation on which the hotel is designed and delivered.
The value of these standards should not be underestimated. They embed efficiencies that are difficult to replicate independently, from optimal room layouts and back-of-house adjacencies to service flow, staffing models, and infrastructure planning. In many cases, they reflect lessons learned from previous development challenges, avoiding costly mistakes that might otherwise only become apparent during operation. Even for newer or emerging brands, the underlying expertise often rests with teams with long-standing industry experience, bringing a depth of practical knowledge that extends beyond what is visible in the documentation.
In parallel with access to documentation, the TSA unlocks the operator’s technical services team. These teams are typically multidisciplinary, including specialists in architecture, interior design, engineering, IT systems, procurement, and hotel operations. What distinguishes them is not only their technical capability, but their specific focus on hospitality. Hotels are highly specialised assets in which design decisions directly affect operational efficiency, revenue generation, and the guest experience. The operator’s technical teams bring sector-specific insight that generalist consultants may not always possess.
This combination of structured standards and specialist expertise creates a significant advantage for the developer. It allows the project to benefit from proven solutions, reduces uncertainty in critical design decisions, and helps align the asset with the operating model’s requirements from an early stage. While the TSA does not transfer responsibility for delivery, it provides a framework for making better-informed decisions, ultimately supporting both development efficiency and long-term asset performance.
Uncertainty and Early-Stage Drafting
One of the defining characteristics of a TSA is that it is negotiated at an early stage in the development process, often before design is fully developed and before many project variables are known. As a result, the agreement is necessarily drafted with a degree of flexibility, allowing it to accommodate changes as the project evolves.
This inherent uncertainty can create tension as the project progresses. Provisions that appear straightforward in principle may become more complex in practice as design develops, budgets are refined, and timelines shift. Unlike the HMA, which governs a relatively stable operating environment, the TSA operates in a context of continuous change.
For developers, this is a critical point. The TSA is often agreed before the full cost implications of brand requirements are understood, yet it is during this phase that those requirements begin to crystallise into real financial commitments. Changes in design, specification, or scope can have a cascading effect on cost and programme, particularly where they occur later in the process. Managing this uncertainty requires not only careful drafting, but also disciplined project management and clear communication between all parties.
Hotel Technical Services Agreement Terms
Scope of Services
The scope of services defines the extent of the operator’s involvement during the development process and is one of the most commercially significant sections of the agreement. It typically spans the full lifecycle of the project, from concept development through to construction and pre-opening.
In practical terms, the operator’s role includes reviewing and advising on spatial planning, guest flow, operational functionality, and alignment with brand standards. This may involve input on room layouts, public areas, back-of-house design, and systems integration. The objective is to ensure that the hotel, once completed, can operate efficiently and deliver the intended guest experience.
Table: Scope of Services
The table below summarises how this section typically operates in practice, based on standard TSA structures:
| Category | What the Agreement Says | Practical Interpretation | Developer Consideration |
|---|---|---|---|
| Concept Development | Covers preliminary and detailed hotel concept | Operator influences positioning, layout logic, and operational concept early | Early decisions here lock in long-term operational efficiency |
| Design Review & Input | Review of plans, specifications, and submissions | Operator ensures alignment with brand standards and functionality | Review is advisory, not responsible; the developer must validate |
| Construction Phase Input | Ongoing consultation during build phase | Operator remains involved through site visits, reviews, and snagging | Late-stage comments can create cost/time pressure |
| Standards Compliance | Alignment with brand design + IT standards | Ensures hotel meets brand requirements for opening | Standards may evolve, risk of moving target |
| Multidisciplinary Input | Covers fire safety, IT, energy, kitchen, etc. | Operator provides holistic hotel-specific expertise | Coordination required across multiple consultants |
| Pre-Opening Readiness | Input through to completion and handover | Ensures operational readiness at opening | Critical for smooth launch and brand compliance |
However, the scope is deliberately framed as advisory. The operator provides recommendations and approvals from a brand and operational perspective but does not take responsibility for technical design, buildability, or cost. This creates a structural imbalance that developers must manage carefully. The operator can influence critical decisions that affect cost and programme, but the consequences of those decisions sit with the developer.
Scope of the Hotel Project and Approval Process
The TSA establishes a structured framework for design development and approval. The developer is required to submit drawings, specifications, and other documentation at defined stages, and the operator is given the right to review and comment on these submissions.
In principle, this creates a collaborative process in which design evolves through iterative input. In practice, the effectiveness of this process depends heavily on how approval rights are exercised. When timelines for review align with the construction programme, and feedback is clear and consistent, the process can function efficiently. When these elements are not well-defined, challenges can arise.
Table: Scope of the Hotel Project and Approval Process
The table below summarises how this section typically operates in practice, based on standard TSA structures:
| Element | Agreement Mechanism | How It Works in Practice | Risk / Control Point |
|---|---|---|---|
| Project Definition | Size, keys, timing defined upfront | Sets baseline expectations for brand positioning | Changes later can be costly |
| Budget Review | Operator reviews project budget | Operator influences cost allocation (FF&E, systems, etc.) | No cost responsibility, but strong influence |
| Design Team Approval | Operator approval of consultants | Operator indirectly shapes project team | Potential constraint on owner procurement |
| Standards Issuance | Standards provided post-fee payment | Unlocks full design documentation | Critical milestone in project progression |
| Approval Process | Formal staged submissions (concept → construction) | Iterative review and approval cycle | Timing misalignment = delay risk |
| Deemed Approval | Silence = approval after set period | Protects developer from delay | Must track timelines carefully |
| Change Control | No material changes without approval | Operator maintains design consistency | Limits flexibility during construction |
| Dispute Resolution | Expert determination mechanism | Independent technical resolution route | Useful but can slow decision-making |
| IP Ownership | Standards remain operator property | Use restricted to this project only | Limits reuse or replication |
Delays in operator responses, lack of clarity in comments, or changes in direction during the design process can disrupt programme delivery. In some cases, previously approved elements may be revisited or revised, creating uncertainty and requiring rework. Where feedback is not accompanied by clear reasoning, design teams may struggle to respond effectively, leading to inefficiencies and frustration.
The approval process is therefore not simply procedural. It is a critical control mechanism that can materially affect both cost and timing. Developers should ensure that review timelines, feedback requirements, and approval criteria are clearly defined and aligned with the overall project programme.
Owner’s Undertakings
The owner’s obligations under the TSA are extensive and form the foundation of the development process. The owner is responsible for financing, designing, constructing, furnishing, and equipping the hotel, as well as for appointing and managing all consultants and contractors involved in the project.
In addition to these responsibilities, the owner must ensure that the project complies with the operator’s brand standards. This requires coordination across multiple disciplines, including architecture, engineering, interior design, and specialist systems. The owner must manage all of these inputs while responding to operator feedback and implementing required changes.
Table: Owner’s Undertakings – Responsibility Matrix
The table below summarises how this section typically operates in practice, based on standard TSA structures:
| Area | Owner Obligation | Practical Meaning | Strategic Implication |
|---|---|---|---|
| Full Delivery Responsibility | Finance, design, build, furnish, equip | Owner carries total project risk | Core TSA principle: operator advises, owner delivers |
| Consultant Appointment | Hire full design + project team | Owner builds full professional ecosystem | Requires strong project management capability |
| Project Manager Role | Central coordination point | Interface between operator and consultants | Critical for managing approvals efficiently |
| Standards Compliance | Ensure all parties follow standards | Owner enforces brand requirements across team | Risk of cost escalation |
| Submission Obligations | Submit all drawings/specs for review | Continuous interaction with operator | Admin-heavy, requires discipline |
| Regulatory Compliance | Obtain permits, approvals, licenses | Local legal responsibility remains with owner | No reliance on operator here |
| FF&E & OS&E Delivery | Procure and install all equipment | Owner responsible for full operational setup | Major cost driver |
| Programme & Budget Control | Deliver within timeline and cost | Owner absorbs impact of changes | Requires strong cost control framework |
In many agreements, the operator also retains approval rights over the project consultants, including architects and interior designers. While intended to protect brand integrity, these rights can extend the operator’s influence beyond design into the composition of the project team itself. This introduces an additional layer of complexity, as the developer must balance operator preferences with its own procurement strategy and project objectives.
Ultimately, the owner carries full responsibility for delivery. Any failure in design, construction, or compliance sits with the owner, even where decisions have been influenced by operator input. This allocation of responsibility is central to understanding the TSA’s risk profile.
Consultant’s Undertakings (Operator Responsibilities)
The operator’s obligations are typically framed as providing technical advice, design review, and operational guidance throughout the development process. This may include input on layout efficiency, systems integration, safety considerations, and operational functionality, as well as participation in site visits and coordination meetings.
Despite this level of involvement, the operator’s responsibilities are carefully limited. The agreement will usually make clear that the operator is not responsible for construction methods, regulatory compliance, or technical design accuracy. Its role is to ensure that the hotel meets brand standards and is capable of operating effectively, rather than to manage or deliver the project.
Table: Consultant’s Undertakings (Operator Responsibilities)
The table below summarises how this section typically operates in practice, based on standard TSA structures:
| Area | Operator Role | What They Actually Do | Limitation / Reality |
|---|---|---|---|
| Advisory Role | Provide consultation and recommendations | Guide design, layout, systems, operations | No execution responsibility |
| Design Input | Operational + aesthetic input | Focus on guest experience + efficiency | Not responsible for technical accuracy |
| Systems & Infrastructure | Input on IT, energy, security, etc. | Ensures operational functionality | Must be validated by engineers |
| Standards Application | Ensure compliance with brand standards | Protects brand integrity | Can override design preferences |
| Site Involvement | Site visits + coordination meetings | Monitor alignment during build | Limited physical presence (often capped) |
| Equipment & Layout | Review FF&E, OS&E, systems | Ensures operational usability | Final procurement still owner’s risk |
| Snagging & Handover | Prepare snagging lists, review completion | Supports pre-opening readiness | No liability for defects |
| Multiphase Involvement | Concept → construction → handover | Continuous engagement across lifecycle | Advisory throughout, not accountable |
This creates an accountability gap. The operator influences the main decisions, often in detail, but does not assume responsibility for their outcomes. The developer must therefore rely on its own consultants to validate and implement those decisions, ensuring that they are technically sound and commercially viable.
Design Standards
The definition and application of design standards are among the most critical aspects of the TSA. While most agreements refer to brand standards or design guides, the level of detail and clarity within those standards can vary significantly.
Where standards are clearly defined and documented, they provide a consistent framework for decision-making. However, where standards are incomplete, evolving, or insufficiently detailed, the approval process can become subjective. Design decisions may then be influenced by individual preferences rather than objective criteria.
This introduces a significant risk for developers. Changes in design direction, particularly at later stages, can lead to rework, delays, and increased cost. In some cases, the absence of clear standards can result in inconsistent decision-making, with approvals being granted and then revisited as project teams or operator representatives change.
Table: Design Standards – Structure and Control
| Component | Agreement Position | Practical Effect | Risks |
|---|---|---|---|
| Standards Definition | Central reference point (design + IT) | Governs all design decisions | May evolve over time |
| Minimum Requirement | Standards are baseline obligation | Owner cannot go below standard | Drives cost floor upward |
| Updates to Standards | Changes allowed if no cost/time impact | Operator retains flexibility | Disputes over “impact” |
| Deviation Process | Must be flagged and approved | Controlled flexibility mechanism | Requires proactive management |
| Reference Benchmarking | Linked to comparable “reference hotel” | Sets qualitative benchmark | Can be subjective |
| IP Protection | Standards remain operator property | No reuse outside project | Limits developer leverage |
| Approval Authority | Operator approves compliance | Centralised control point | Potential bottleneck |
| Subjectivity Risk | Interpretation may vary | Depends on individuals/team | Inconsistent application risk |
Ensuring that design standards are clearly defined, documented, and consistently applied is therefore essential. Where possible, objective criteria should be established to provide a basis for resolving disagreements and maintaining alignment throughout the project.
Technical Services Fee
The fee structure under a TSA is typically fixed and linked to development milestones. Payments are often staged to reflect progress through design and construction phases and are generally non-refundable.
In addition to the base fee, developers may be required to reimburse the operator for travel expenses, site visits, and other costs incurred in delivering the services. Additional fees may also apply if the scope of services is expanded or if the project undergoes significant changes.
From a financial perspective, TSA fees should be treated as an integral part of the development budget. While they may appear modest relative to overall project costs, the operator’s influence on design and specification can have a far greater impact on cost than the fee itself.
| Methodology | How It Is Calculated | Typical Usage | Commercial Notes |
|---|---|---|---|
| Fixed Lump Sum Fee | Pre-agreed total fee, usually paid in staged instalments | Most common structure (as per typical operator TSAs) | Provides cost certainty and is simple to administer. However, it may not reflect actual workload and can result in under- or over-servicing. Typically split across project phases (e.g. signing, design, construction). |
| Phased / Milestone-Based Fee | Fee divided into stages linked to project progress | Common alongside lump sum structures | Aligns payments with development progress, but timing of milestone completion can become a source of dispute. Usually embedded within a fixed fee rather than standalone. |
| Per Key Fee | Fee based on number of hotel rooms (e.g. €X per key) | Used in more standardised or mid-scale projects | Easy to benchmark and compare across projects, but does not reflect complexity, facilities mix, or brand positioning. Less common in full-service or luxury developments. |
| % of Project Cost | Fee calculated as a percentage of total development cost | Relatively uncommon in branded TSAs | Scales with project size but may create misalignment, as higher costs can increase fees. Typically avoided by major operators due to perceived conflict with cost discipline. |
| Cost-Recovery / Time-Based | Based on actual time spent (daily rates, hourly billing, expenses) | Rare for full TSA; used in early-stage or limited advisory roles | Flexible and reflective of actual effort, but lacks cost certainty and can be administratively burdensome. More common prior to full agreement execution. |
| Hybrid Model | Combination of fixed fee plus variable or additional services components | Increasingly common for complex or evolving projects | Balances cost certainty with flexibility, but can become complex. Additional services provisions should be clearly defined to avoid scope creep. |
| Other Fees & Structures | |||
| Additional Services Fee | Separate fees for work outside the agreed scope | Standard feature in most TSAs | Protects operator from scope expansion but can lead to cost escalation if not tightly controlled. Clear definitions and approval processes are critical. |
| Reimbursable Expenses | Travel, site visits, and related costs charged separately | Almost universal | Transparent in principle, but can accumulate significantly over time. Often uncapped unless specifically negotiated. |
| Deferred / Conditional Fee | Portion of fee linked to project milestones or execution of HMA | Occasionally used in early-stage negotiations | Aligns operator with project progression, but can complicate commercial structure. Sometimes tied to execution of the management agreement. |
| Reduced / Incentivised Fee | Discounted TSA fee as part of broader deal negotiation | Seen in competitive operator selection processes | May improve upfront economics, but value may be recovered elsewhere in the commercial structure. Should be assessed in the context of the full deal. |
| Fee Offset / Recovery Mechanism | TSA fee paid upfront, then recovered through deductions from future incentive fees under the HMA | Occasionally negotiated in competitive or owner-favourable situations | Can make the TSA effectively cost-neutral over time. Typically limited to incentive fees and often subject to caps. Not standard and may be resisted or priced elsewhere. |
Payments and Tax Structure
Payment provisions often include detailed mechanisms for invoicing, timing, and tax treatment. In international projects, this can involve complex considerations around withholding tax, VAT, and currency transfer.
The agreement may require that fees are paid net of tax, with the developer responsible for any deductions or additional costs. This can increase the effective cost of the agreement and should be carefully assessed during financial planning.
A clear understanding of these provisions is essential, as misalignment can lead to unexpected costs and disputes. Developers should ensure that tax implications are fully incorporated into the project budget from the outset.
Term and Termination
The TSA typically runs from execution until hotel opening, with provisions for early termination under specified circumstances. These may include failure to proceed with the project, non-payment of fees, or failure to execute the related operating agreement.
Termination provisions are often structured to protect the operator, particularly where work has already been undertaken. Developers may remain liable for fees and costs incurred up to the point of termination, even if the project is not completed.
This reinforces the importance of aligning the TSA with the broader contractual framework, ensuring that termination rights and obligations are clearly understood across all agreements.
Continuing Effect of Technical Provisions Beyond Termination
While the Technical Services Agreement is typically stated to terminate upon opening, certain provisions can extend its practical effect beyond that point. In particular, clauses relating to future capital expenditure and approval processes may continue to apply during operation, effectively carrying forward elements of the operator’s technical oversight. This creates an ongoing link between the completed asset and the original design framework, meaning that future renovations or upgrades may still be subject to operator review. Owners should be aware that, despite formal expiry, the TSA can continue to influence flexibility in asset management and capex decisions.
From a legal perspective, this effect arises because certain provisions are drafted to apply to future events and are therefore interpreted as surviving termination by their nature. Where a clause explicitly refers to post-opening activities, it is treated as a continuing obligation, even without an express survival clause, and is often reinforced by alignment with the management or franchise agreement.
Operators will typically justify this on the basis that it creates a pre-agreed framework for future capital expenditure and technical changes, avoiding the need to negotiate new arrangements each time. While this is generally sensible, owners should ensure that the financial threshold for triggering such processes is set at an appropriate level, so that the full approval framework is not unnecessarily applied to relatively minor works.
Limitation of Liability
The limitation of liability clause is central to the risk allocation within the TSA. It typically makes clear that the operator is not responsible for technical design, construction delivery, regulatory compliance, or cost outcomes.
The operator’s role is limited to operational and brand-related considerations, and its approvals do not constitute acceptance of technical responsibility. This creates a situation where the operator can influence principal decisions without assuming liability for their consequences.
For developers, this highlights the importance of independent technical expertise. The TSA does not replace the need for strong architects, engineers, and project managers, and reliance on operator input alone is insufficient to manage development risk.
When Technical Services Agreements Go Wrong
While TSAs are intended to support development, misalignment between owner and operator can have significant consequences. Disputes over design, approvals, and responsibilities can escalate, affecting both the project and the relationship between the parties.
In practice, poorly structured TSA processes can lead to delays, increased costs, and breakdowns in coordination. Conflicts between design teams and operator representatives can disrupt progress, while changes in direction can undermine programme stability. In more severe cases, these issues can lead to breakdown of the relationship between owner and brand, with wider implications for the project.
This reinforces a central point: the TSA is not a peripheral document. It sits at the heart of the development process and directly impacts project outcomes.
Schedules and Exhibits
The schedules to the TSA provide detailed support to the main agreement and often contain the practical substance of the operator’s involvement. While the core agreement establishes the structure and allocation of responsibilities, it is within the schedules that those responsibilities are translated into specific requirements, processes, and deliverables.
These schedules typically include definitions, identification of project consultants, and detailed descriptions of services. The definitions schedule, in particular, should not be overlooked. In addition to setting out technical terminology, it often defines the “Hotel” itself, including scope, positioning, and main characteristics. It may also incorporate references to industry-standard frameworks and metrics, such as the Consumer Price Index (CPI), the classification of Furniture, Fixtures and Equipment (FF&E), and accounting conventions aligned with the Uniform System of Accounts for the Lodging Industry (USALI). Developers should ensure that these definitions, particularly those related to the asset itself, align precisely with the intended project, as inconsistencies at this stage can lead to misalignment later in design, budgeting, and execution.
The schedule describing services is equally important, as it expands the scope to include specific tasks across design development, interior design, equipment selection, and construction-phase support. Developers should review all schedules carefully, as they define how the agreement operates in practice and can directly impact both cost and programme.
List of Professional Consultants / Hotel Drawings, Plans & Specifications
One of the most commercially sensitive schedules is the identification of the project team and the baseline design documentation. The inclusion of professional consultants within the schedule effectively acts as a form of pre-approval by the operator. At this stage, the developer typically retains greater negotiating leverage and should use this opportunity to ensure that their preferred architects, designers, engineers, and project managers are formally recognised within the agreement. Once the TSA is executed, introducing or replacing consultants may become more complex, particularly where operator approval rights apply.
This schedule also provides an opportunity to anchor the project in a defined set of drawings, plans, and specifications. Even where these are conceptual or indicative, they establish a reference point for the development of the design. The operator’s technical team may review and comment on these materials, and may propose refinements or further development, but their inclusion in the agreement helps to frame the discussion and reduces the risk of fundamental redesign at a later stage.
From a practical perspective, this is an important moment in the development process. By documenting both the project team and the initial design intent, the developer creates continuity and clarity that can carry over into the approval process. While the operator retains influence through its review and approval rights, the existence of an agreed baseline can help ensure that subsequent input is evolutionary rather than transformational, reducing the risk of disruption to programme and cost.
Description of Technical Assistance Services
The description of technical assistance services expands the high-level scope set out in the main agreement into a detailed, phase-by-phase framework of operator involvement. Rather than a single, uniform service, the TSA typically breaks this down across the development lifecycle, covering design planning and development, interior design and equipment selection, and the construction phase through to handover.
Each stage reflects a different form of engagement, from early conceptual input to detailed review and on-site involvement. For developers, this schedule provides the clearest view of how and when the operator’s technical team will interact with the project, and therefore where influence is likely to be greatest. Understanding this progression is essential to managing both the design process and the commercial implications that follow.
Design Planning and Development
This phase covers the operator’s involvement from the earliest concept through to final construction documentation. It is where the project is shaped in terms of layout, operational logic, systems integration, and technical functionality. While the operator’s role is advisory, its influence at this stage is significant, as decisions made here will directly affect cost, efficiency, and long-term performance.
The process typically follows the evolution of design, from initial concept and schematic design through to detailed design development and final construction documentation. The operator’s technical team reviews submissions, provides comments, and participates in coordination with the wider consultant team, creating an iterative refinement process.
From the owner’s perspective, careful management is required. The volume of input can be substantial, and it is important to distinguish between critical operational requirements and preference-based recommendations, ensuring that cost and programme impacts are properly controlled.
Design Planning and Development – Key Activities
| Area | Operator Involvement | Practical Implications |
|---|---|---|
| Concept & Planning | Review of initial concepts and planning submissions | Sets overall positioning and layout logic; early decisions can have long-term cost and operational impact |
| Schematic Design | Input on drawings, sketches, and outline specifications | Defines scale and configuration; must remain aligned with budget and project objectives |
| Design Development | Review of detailed drawings, systems, materials, FF&E layouts | Integrates operational requirements; risk of scope and cost expansion if not controlled |
| Mock-Up Review | Inspection and reporting on sample rooms | Provides real-world validation; key checkpoint before full rollout |
| Final Documentation | Review of construction drawings and specifications | Confirms readiness for build; late-stage changes can be disruptive |
| Coordination | Participation in design meetings | Helps align disciplines but requires strong project leadership from owner |
| Back-of-House Planning | Review of BOH layouts and operational areas | Critical for operational efficiency; often underestimated in early design |
| Systems & Engineering Input | Advice on MEP, fire safety, infrastructure | Supports functionality but must be validated by technical consultants |
| Equipment Integration | Input on systems and equipment placement | Requires coordination across multiple disciplines to avoid clashes |
Interior Design, Equipment Selection and Recommendations
This stage focuses on the guest-facing and operational fit-out of the hotel, including interior design, F.F. & E., and operating equipment. It is where the brand is translated into the physical guest experience and where a significant portion of capital expenditure is committed.
The operator’s involvement includes reviewing and approving design schemes, advising on materials and finishes, and guiding equipment selection. This extends across all hotel areas, from guest rooms and public spaces to back-of-house and specialist facilities.
For the owner, this phase requires close control over cost and procurement. Operator requirements can be detailed and prescriptive, and while they support consistency and performance, they can also drive specification levels beyond initial assumptions.
Interior Design & Equipment – Key Activities
| Area | Operator Involvement | Practical Implications |
|---|---|---|
| Interior Design Review | Approval of design schemes and detailed documents | Defines overall guest experience; must balance brand standards with cost |
| Design Coordination | Support to interior and lighting designers | Ensures consistency across design elements; owner should retain design direction |
| FF&E Specification | Review and approval of furniture and fittings | Major cost driver; requires close scrutiny and alignment with budget |
| FF&E Procurement | Review of specifications, samples, and contracts | Ensures compliance but may limit procurement flexibility |
| OS&E Planning | Input on operating equipment lists and specifications | Essential for operations; often underestimated in budgeting |
| Supplier Input | Recommendation of suppliers and equipment | Leverages operator experience but may influence procurement choices |
| Cost Review | Input on FF&E and OS&E cost levels | Provides guidance but cost responsibility remains with owner |
| Equipment Layout | Definition of equipment locations | Supports operational efficiency; requires coordination with design team |
| Landscaping & External Areas | Review of landscaping and external design | Extends brand experience; can introduce additional cost |
| Programme Coordination | Input on delivery schedules | Critical for installation timing and avoiding delays |
| Site Monitoring | Site visits and progress input | Provides oversight but not a substitute for project supervision |
Construction Phase and Preparation for Handover
This phase represents the transition from design into delivery and operation. The operator’s role shifts to monitoring, verification, and preparation for opening, ensuring alignment with approved designs and brand standards.
The operator typically participates in coordination meetings, reviews mock-ups and completed works, and prepares snagging lists. This supports the transition into operation, but responsibility for construction quality and delivery remains with the owner.
From the owner’s perspective, this is a critical stage for managing final quality, programme, and readiness. Operator input can be valuable, but it must be managed carefully to avoid late-stage disruption.
Construction & Handover – Key Activities
| Area | Operator Involvement | Practical Implications |
|---|---|---|
| Coordination Meetings | Participation in project and site meetings | Maintains alignment but requires structured communication |
| Mock-Up Approval | Review and approval of built sample rooms | Key quality checkpoint before full implementation |
| Construction Monitoring | Review of works against approved design | Ensures compliance but does not replace supervision responsibility |
| Standards Compliance | Verification against brand requirements | May trigger late adjustments if deviations occur |
| Snagging Process | Identification of defects and incomplete works | Supports readiness; rectification remains owner responsibility |
| Systems & Equipment Review | Assessment of installed systems | Ensures operational functionality prior to opening |
| Maintenance & Spare Parts | Input on maintenance and spare parts | Important for long-term operation but often overlooked |
| Pre-Opening Readiness | Support in preparing for opening | Critical transition phase; impacts launch performance |
Sample Clauses in the Hotel Technical Services Agreement
Sample Clause – Technical Services Fee (Structure and Payment)
Purpose: A typical structure for Technical Services Fees, including staged payments aligned with project milestones.
Sample Clause:
The Owner shall pay to the Consultant a fixed technical services fee (the “Technical Services Fee”) in the amount of EUR [●], exclusive of any applicable taxes, in consideration for the services to be provided under this Agreement. The Technical Services Fee shall be non-refundable and shall be payable in instalments linked to the progress of the Project as follows:
(a) Initial Instalment: An amount equal to twenty-five per cent (25%) of the Technical Services Fee shall be payable upon execution of this Agreement and delivery of the applicable brand standards and technical documentation;
(b) Design and Pre-Construction Instalment: An amount equal to fifty per cent (50%) of the Technical Services Fee shall be payable upon the earlier of (i) [●] months following execution of this Agreement, or (ii) receipt of all necessary approvals to commence construction of the Hotel;
(c) Construction Phase Instalment: The remaining twenty-five per cent (25%) of the Technical Services Fee shall be payable within [●] months following commencement of construction works.
In the event that the parties do not enter into a hotel management or franchise agreement within [●] days of the date of this Agreement, the Consultant shall have the right to terminate this Agreement upon written notice. In such circumstances, the Owner shall remain liable for all fees accrued and costs incurred up to the date of termination, and shall cease all use of the Consultant’s standards and materials.
Any material expansion in the scope of the services shall be subject to mutual agreement and may result in an adjustment to the Technical Services Fee.
This structure is typical of market practice, with payments usually front-loaded to reflect early-stage involvement and delivery of standards. Developers should pay close attention to timing triggers and linkage to project milestones.
Sample Clause – Reimbursable Costs and Expenses
Purpose: To demonstrate how operator costs are typically passed through to the owner in addition to the base fee.
Sample Clause:
In addition to the Technical Services Fee, the Owner shall reimburse the Consultant for all reasonable and properly documented out-of-pocket expenses incurred in connection with the performance of the services under this Agreement. Such expenses may include, without limitation, travel, accommodation, subsistence, and third-party specialist costs, where applicable.
All such expenses shall be invoiced periodically and shall be payable by the Owner within [●] Working Days of receipt of a valid invoice, supported by appropriate documentation. The Consultant shall use reasonable efforts to ensure that such costs are proportionate and consistent with the requirements of the Project.
These costs are typically uncapped unless negotiated. Over the course of a project, they can become material and should be considered as part of the overall development budget.
Sample Clause – Additional Services
Purpose: To reflect how operators manage scope creep and variations.
Sample Clause:
The services to be provided by the Consultant under this Agreement are limited to those expressly described herein. Any services requested by the Owner that fall outside the agreed scope (the “Additional Services”) shall be subject to the Consultant’s prior approval and may be performed at an additional fee to be agreed in writing between the parties.
The Consultant shall not be obliged to perform any Additional Services unless and until such fee and scope have been agreed. Where Additional Services are required as a result of material changes to the Project, delays, or revisions to previously approved designs, the Consultant shall be entitled to recover its reasonable additional costs.
This is a commercial protection for the operator and a potential cost risk for the developer. Clear scope definition at the outset is critical to avoid escalation.
Core Takeaways
A Hotel Technical Services Agreement is a central mechanism by which brand standards are translated into physical assets. While structured as an advisory agreement, it can have a substantial influence on design, cost, and delivery.
For developers, the core principles are clear. The operator influences the project but does not deliver it, and responsibility for execution remains entirely with the owner. Uncertainty at early stages must be actively managed, and approval processes and standards must be clearly defined and controlled.
Ultimately, the TSA sits at the point where concept becomes reality. Decisions made under this agreement shape not only the development process, but the long-term performance of the asset.
Further resources:
See HDG – Determining the Project Team
See HDG – Hotel Architectural & Design Team
See HDG – Hotel Development Advisors | Legal, Investment, Project & Technical Specialists
Accor Hotel Development – “Design & Technical Expertise“
Hilton Development – “Architecture, Design, Construction – Technical Services“