--- --- ## Landlord Journey SOP - **Landlord Journey – Overview** --- Landlords come to SureRightStay because they want **serious tenants, predictable income, and protection against fraud and damage**. Our responsibility is to turn what could be a risky, informal process into a **structured, transparent relationship** where expectations are clear on both sides. In the landlord journey, SRS: - Explains the model (verification, inspection, payments) in simple language - Checks that the landlord is real and authorised to list the property - Verifies key documents and works with relevant authorities where required - Presents the property to tenants as a **verified, professionally managed listing** - Manages communication, issues and payouts in a clear, documented way This flow is not just about listing a property; it is about **protecting the landlord, the tenant and SRS’s credibility** at the same time. --- - **Landlord Experience Promise** --- Whenever a landlord interacts with SRS, we commit to: - **Clarity before commitment** Landlords understand how SRS works, what we verify, and how fees and payouts operate before they sign anything. - **Respectful and honest communication** We are open when documents are missing, when something is delayed, or when we cannot accept a listing. - **Verification as a service, not a punishment** We explain that verification and inspection are there to protect everyone and increase the value and trust of their property. - **Transparent money flow** Landlords know when funds are collected, when they are held, and when they will be settled. - **Traceable decisions** Any rejection, condition or suspension of a listing can be explained with documented reasons, not arbitrary opinions. --- - **Ops Checklist – Landlord Onboarding (External Flow)** --- Use this whenever you are dealing with a **new landlord or new property**. - ☐ Landlord has received a **simple explanation** of SRS (verification, inspection, payments, support). - ☐ Landlord profile is complete: name, contact details, preferred channel (email/WhatsApp/phone). - ☐ Property basics collected: location, type, rent/shortlet, price range, availability. - ☐ Landlord understands they must provide **ownership/authority documents** and that SRS may verify with government/partners. - ☐ Expected **timeline** communicated: docs → verification → inspection → listing goes live (and what can delay it). - ☐ Fees and **payout model** explained: what SRS charges, when payouts happen, and how statements are provided. - ☐ Landlord knows where to see **status updates** (e.g. “under review”, “awaiting documents”, “verified and live”). - ☐ If we cannot proceed or must pause, the landlord receives a **clear, respectful explanation** and, where possible, a suggested next step. --- ```mermaid flowchart TD A([Start]) --> B["Click List your property or Landlords page"] B --> C["Fill landlord profile and contact details"] C --> D["Complete property pre-intake form"] D --> E["Upload ownership documents and ID"] E --> F{Documents valid and complete?} F -->|No| G["Request additional documents or clarification"] G --> E F -->|Reject| H["Reject and archive lead, notify landlord"] F -->|Yes| I["Schedule inspection"] I --> J["Conduct inspection with photos, video and grading"] J --> K{Inspection outcome?} K -->|Fail| L["Reject listing and notify landlord"] K -->|Conditional| M["Request fixes or improvements"] M --> I K -->|Approve| N["Prepare and sign SRS Landlord Service Agreement"] N --> O["Create listing with title, description, photos and verified badge"] O --> P["Activate listing on platform"] P --> Q([End: Active verified property]) ``` --- ## Tenant/Guest Journey SOP - **Tenant Journey – Overview** --- Tenants come to SureRightStay because they want a **place that feels safe, real, and fairly priced**—without being scammed, stranded, or surprised by hidden conditions. Our responsibility is to turn browsing and booking into a **trust-based journey** where information is clear, money is handled safely, and help is available when something goes wrong. In the tenant journey, SRS: - Shows only properties that meet our **minimum verification and quality standards** - Makes key facts (price, deposit, rules, verification status) **easy to understand before booking** - Uses **secure, traceable payment flows** instead of random transfers - Documents entry and exit conditions to reduce disputes - Provides a **clear path to support** if the property or host fails to meet agreed expectations The goal is not just to fill rooms, but to **protect tenants and preserve trust** in the SRS brand and its landlords. --- - **Tenant Experience Promise** --- Whenever a tenant interacts with SRS, we commit to: - **No deliberate surprises** Core information (price, deposit, rules, basic verification status) is visible before payment, not after. - **Verification you can see** We indicate which properties are verified, when they were last inspected, and what that means in practical terms. - **Safe and traceable payments** Tenants pay through secure channels; we avoid situations where they are asked to send money to random accounts outside the agreed process. - **Documented handover** We encourage and support entry/exit checks so disputes are based on facts, not memory. - **A real support path** If something is wrong, tenants know exactly how to contact SRS and what kind of help to expect. --- - **Ops Checklist – Tenant Booking & Stay (External Flow)** --- Use this for each **confirmed booking** and during the stay. - ☐ Tenant has seen the **full price breakdown** (rent, deposit, fees, any extra charges) before confirming. - ☐ Tenant understands the property’s **verification status** (e.g. “Verified by SRS, last inspected on [date]”). - ☐ Booking confirmation with **reference ID, dates and key terms** has been sent. - ☐ Move-in / handover time has been clearly agreed and communicated to both tenant and landlord/agent. - ☐ Entry condition is **documented and acknowledged** (photos, checklist, or both). - ☐ Tenant knows how to reach **SRS support** (contact info visible in email/portal). - ☐ If an issue is reported, the tenant receives **acknowledgement and a realistic timeframe** for investigation and response. - ☐ At check-out, the tenant is informed about **deposit handling and expected timelines** for any refund. --- ```mermaid flowchart TD A([Start]) --> B["Click Explore verified properties"] B --> C["Use search with mode, location, type and budget"] C --> D["View list of verified properties"] D --> E["Open property details page"] E --> F{Interested in this property?} F -->|No| C F -->|Yes| G["Click Start booking or Request viewing"] G --> H["Create account or log in"] H --> I["Complete basic verification with ID and profile"] I --> J["Select move-in date and duration"] J --> K["See price breakdown including rent, deposit and fees"] K --> L["Confirm booking details"] L --> M["Make payment into escrow style holding"] M --> N{Payment successful?} N -->|No| O["Show error and retry or cancel"] O --> L N -->|Yes| P["Send booking confirmation with reference ID"] P --> Q["Schedule handover and entry inspection"] Q --> R["Perform entry inspection and sign checklist"] R --> S["Stay period"] S --> T{Any issue during stay?} T -->|No| U["Proceed to check-out date"] T -->|Yes| V["Create support ticket and follow support SOP"] U --> W["Schedule check-out and exit inspection"] W --> X["Perform exit inspection and compare with entry condition"] X --> Y["Determine deposit settlement"] Y --> Z["Pay landlord and refund deposit as applicable"] Z --> AA["Request tenant review and feedback"] AA --> AB([End]) ``` --- ## Agents / Agencies Journey SOP - **Overview** --- Agents and agencies extend SRS’s reach on the ground. They can help us discover more properties, conduct inspections, and serve landlords and tenants faster. But they can also **damage trust** if they cut corners, misrepresent SRS, or make side deals. In the agent journey, SRS: - Onboards agencies as **partners with clear roles**, not just casual “agents” - Sets expectations for **ethical conduct, documentation quality, and communication** - Provides a clear framework for **commission and rewards** - Actively monitors behaviour and is willing to **warn, suspend or remove partners** to protect users Agents are not just “sales people” in this model—they are **frontline trust partners** who must work within SRS rules. --- - **Experience Promise** --- When we work with agents and agencies, we commit to: - **Clarity on roles and limits** We define what they can do in our name and what they cannot. - **Transparent earnings structure** Commission or fees are shared upfront—no guesswork, no moving goalposts. - **Consistent processes** We train them on how SRS handles listings, inspections and disputes, so they are not guessing. - **Respect and professionalism** We communicate feedback and sanctions professionally, based on facts and agreed standards. --- - **Ops Checklist (External Flow)** --- Use this when onboarding or actively working with a **partner agency**. - ☐ Agency understands **what SRS is** and how we are different from generic listing sites. - ☐ We have explained the **partner role**: listing submission, inspections, or both. - ☐ Commission / fee model and **payment timing** have been clearly explained and agreed. - ☐ Agency has been trained on: - What SRS means by **“verified property”** - Minimum photo / description standards - Inspection expectations if they perform inspections - ☐ Agency knows how to **submit properties and documentation** using the agreed channel (portal/email). - ☐ Agency contact person and **escalation path** on both sides are defined. - ☐ Agency understands that **fraud, side deals or misrepresentation** will lead to suspension or termination. - ☐ When issues arise with an agency, we give **clear feedback and documented consequences**. --- ```mermaid flowchart TD A([Start]) --> B["Agent or agency opens Agencies or partner link or is contacted by SRS"] B --> C["Choose role: listing agent, inspection partner or both"] C --> D["Submit agency application with CAC, contact and coverage areas"] D --> E["SRS performs screening and due diligence"] E --> F{Approved as potential partner?} F -->|No| G["Politely decline and archive record"] F -->|Yes| H["Share and agree Partner Agreement terms"] H --> I["Sign Partner Agreement with commissions and conduct rules"] I --> J["Create agency portal access"] J --> K["Provide onboarding and training on docs, inspections and processes"] K --> L{Operational role type?} L -->|Listing agent| M["Submit properties on behalf of landlords following Landlord SOP"] M --> O["Properties are verified and listed"] L -->|Inspection partner| N["Receive inspection tasks in portal"] N --> P["Perform inspections and upload reports, photos and videos"] P --> O O --> Q["Track performance including quality, SLA and complaints"] Q --> R{Serious or repeated issues?} R -->|No| S["Continue as active partner"] R -->|Yes| T["Apply warning, suspension or termination"] S --> U([End]) T --> U ``` --- ## Developers / Portfolio Landlords SOP - **Overview** Developers and portfolio landlords bring **multiple units or entire projects** to SRS. They are more complex than individual landlords and often have existing processes, teams and expectations. In this journey, SRS: - Positions itself as a **verification and tenant-onboarding partner**, not a replacement for the developer’s entire organisation - Focuses on **project-level verification** before unit-level onboarding - Agrees upfront on **service scope, reporting, and financial structures** - Manages expectations about **timelines, documentation, and what we can or cannot guarantee** The goal is a **repeatable relationship** where both sides understand the boundary between SRS responsibilities and the developer’s own obligations. - **Experience Promise** With developers and portfolio landlords, we commit to: - **Structured engagement, not improvisation** We follow a clear path: discovery → project verification → framework agreement → unit onboarding. - **Transparent capabilities** We do not oversell the speed or power of verification; we explain real timelines and dependencies on government/partners. - **Consistent reporting** We agree in advance on what we will report (occupancy, issues, payouts) and how often. - **Aligned interests** Our processes aim to protect both the developer’s brand and the tenants who occupy their units. - **Ops Checklist – (External Flow)** Use this when working with a **new project or portfolio client**. - ☐ We have held a **discovery call/meeting** to understand the project, expectations and existing processes. - ☐ We have explained SRS’s role: verification, tenant onboarding, inspections, dispute support, etc. - ☐ The developer understands the difference between: - **Project-level verification** (land/title approvals) - **Unit-level onboarding** (each apartment/house listing) - ☐ We have discussed and set **realistic timelines** for verification and go-live. - ☐ A clear outline of **fees, revenue share and settlement flow** has been shared. - ☐ A named **account contact** exists on both sides. - ☐ The developer understands that SRS **may refuse or delay listing** units if verification or documentation is incomplete. - ☐ Reporting cadence and format (e.g. **monthly occupancy / issue summary**) has been agreed. ```mermaid flowchart TD A([Start]) --> B["Developer or portfolio owner submits interest form"] B --> C["Capture project information such as location, units and stage"] C --> D["Initial qualification by SRS for fit and geography"] D --> E{Good fit for SRS?} E -->|No| F["Decline or defer engagement with explanation"] E -->|Yes| G["Schedule discovery call or meeting"] G --> H["Hold discovery call to understand needs, processes and risks"] H --> I["Request project documents such as titles, approvals and layouts"] I --> J["Compliance reviews project level documents and risks"] J --> K{Project passes verification?} K -->|No| L["Decline or request changes and record reasons"] K -->|Yes| M["Draft framework or master agreement"] M --> N["Sign framework agreement with portfolio terms, roles and fees"] N --> O["Begin unit level onboarding following Landlord SOP"] O --> P["Create project and unit listings with verified badges"] P --> Q["Assign account manager and agree reporting cadence"] Q --> R["Manage ongoing relationship including occupancy and issues"] R --> S([End]) ``` --- ## Support, Complaints and Escalation SOP - **Overview** Support and complaints are where SRS’s values are tested the most. This is often the moment when people decide whether SRS is truly **trustworthy** or “just another platform.” Our aim is to handle issues with **calm, clarity and fairness** to all parties. In the support journey, SRS: - Receives and logs complaints in a **structured, trackable way** - Distinguishes between **simple requests, service issues and serious disputes** - Bases decisions on **contracts, evidence and documented inspections**, not emotion - Communicates outcomes **clearly and respectfully**, even when the answer is “no” - Knows when to **escalate internally** to operations, legal or leadership This is where “verification, not vibes” becomes **“resolution, not noise.”** - **Experience Promise** When someone comes to SRS with an issue, we commit to: - **Being reachable and responsive** Users should never feel like their complaint has disappeared into a void. - **Listening fully before deciding** We collect facts and review evidence before making a call. - **Explaining the process** We tell users what we will investigate, how long it may take, and what types of outcomes are possible. - **Deciding based on evidence and agreements** We refer back to inspections, messages and terms, not personal bias. - **Respectful, clear communication** Even when we cannot give people what they want, they should understand **why**. - **Ops Checklist – (External Flow)** Use this for **any complaint or serious issue** from tenants, landlords, agents or developers. - ☐ Issue is captured in a **ticket or log** with ID, user type, property, booking reference and a short description. - ☐ User receives an **acknowledgement** with their ticket ID and an estimated response time. - ☐ We clarify what we will **investigate** (inspections, chat/email history, payment records, agreements). - ☐ We remain **neutral** when speaking to both sides (no blame language before investigation). - ☐ Decision is based on **evidence + written terms**, not pressure or emotion. - ☐ Outcome is communicated in **simple, respectful language**: - What we found - What decision we reached - What we can do (refund/partial refund/repairs/credit/etc.) - ☐ If the user disagrees, we explain the **escalation path** and what escalation realistically means (review, not guarantee of a different decision). - ☐ Once closed, the case is **tagged by root cause** (e.g. listing quality issue, landlord conduct, tenant conduct, system delay) to feed into product and SOP improvements. ```mermaid flowchart TD A([Start]) --> B["User reports issue by web, app, email, phone or WhatsApp"] B --> C["Create support ticket with unique ID"] C --> D["Capture user type, property, booking ID and issue category"] D --> E["Assign initial severity as low, medium or high"] E --> F{Severity level} F -->|Low| G["Support team handles information or minor issues"] F -->|Medium| H["Operations team handles service or operational issues"] F -->|High| I["Operations and compliance or legal handle critical case"] G --> J["Investigate by checking records and evidence"] H --> J I --> J J --> K["Draft resolution proposal based on evidence and contracts"] K --> L["Communicate resolution to all parties"] L --> M{Resolution accepted by parties?} M -->|Yes| N["Implement resolution such as refunds, repairs or sanctions"] N --> O["Close ticket and log outcome"] O --> P["Tag root cause and update SOPs, training or product if needed"] P --> Q([End]) M -->|No| R["Escalate to next level such as Ops lead, legal or executive"] R --> S["Review case again at higher level"] S --> K ```