Partner Type:
Purpose: Set context, value, and boundaries immediately.
- What the partner is
- What the partner offers within SuperControl
What the partner offers outside SuperControl ⭐
(Explicitly call out features clients may see advertised but not available via the integration)
- Cost of service (link to partner pricing)
- CSF?
Ideal client profile
- Agency vs owner‑operator
- Portfolio size
- Geography
Primary problem solved
- Distribution
- Revenue optimisation
- Payments
- Operations
- Compliance
Optional: Internal Notes & Context
- Known risks / sensitivities
- Strategic importance
- Client fit (good / bad)
- “Know but don’t say” guidance
Purpose: Kill assumptions early.
Capture:
- Integration classification
- Direct / Bespoke / API‑based
- Data flow
- One‑way / Two‑way
- Source of truth (plain English) ⭐
- “If data is changed here, it will / will not update there”
- Push vs Pull (plain English)
- Sync timing
- Real‑time / near‑real‑time / scheduled / manual triggers
- Hard limitations
- What will never sync
- What overwrites what
Capture:
- Step‑by‑step flow written as you would say it on a call (Include high level visual workflow)
- Include both systems
- Include all integration levels e.g existing listings link/legacy/R&A or Full content 2 way
- No APIs, no acronyms without explanation
Include explicitly: ⭐
- What the client must do in the partner portal
- What SC cannot see or control
Purpose: Remove ambiguity and repeated tickets.
| Data Type | Direction | Notes/ Caveats |
|---|---|---|
| Availability | SC → Partner | Queued processing |
| Rates | SC → Partner | Channel rules apply |
| Default booking extras | SC → Partner | Yes/ No |
| Booking extras | SC → Partner | Itemised |
| Discounts | SC → Partner | Channel-specific |
| Uplifts | SC → Partner | Agent rules |
| Bookings | SC → Partner | Source of truth |
| Guest details | SC → Partner | Partial |
| Payments | SC → Partner | Not SC |
| Messages | SC → Partner | If supported |
| Property content | SC → Partner | Field limits apply |
Disclaimer: Property content might need split down if there are only certain things we send. If field limits apply, detail them out. e.g character limits on descriptions etc.
Booking example & breakdown
Example booking including:
- Base rate
- Discounts
- Uplifts
- Agent commission
- Extras
- CSF
- VAT
- Owner payment impact
If OTAs / Channel capture clearly:
- Where cancellations must be initiated
- Where modifications must be initiated
- What triggers updates
- Payments:
- Who takes payment
- Deposit / balance handling
- VCC behaviour
- Out‑of‑scope payments
- Historical bookings:
- Imported or not
- Guest communication:
- Where messages live
- Agency behaviour:
- Owner payment allocation
- Auto owner payments
- Agents & commission:
- Automatic vs manual
- Common pitfalls
- Available reporting
If Product / SaaS Integrations capture:
- Actual functionality delivered (vs marketing)
- Data required to function
- Prerequisites
- Common misunderstandings
- Available reporting
Purpose: Reduce failed setups & escalations.
Capture:
- High‑level steps
- Responsibility split:
- Client
- SuperControl
- Partner
- Typical timeframes
- Common failure points
- Best‑practice recommendations (non‑mandatory) ⭐
- e.g. Airbnb promotions
- Listing optimisation checklist
- Testing capabilities
- SC Admin tools
- Top recurring issues
- Mandatory first checks
- Info required before escalation
- Known limitations / “expected behaviour”
- What we cannot see or test internally
- Commercial
- Technical
- Support
- Escalation
- SLAs / working hours
External link should include the following:
- Current commercial agreement
- Rev share / fees
- Partner status
- Signed agreements