Property turnover estimate

Tektolo prices with a deterministic, source-cited engine. You turn what the user has (an inspection report, photos, notes) into findings. The engine returns standardized tasks by trade, regional low / expected / high costs, priorities, vendor scopes, refer-outs, and every assumption it made. The rules always decide; an AI model (gpt-6-luna on Microsoft Azure OpenAI) may only read the user's words into findings, and you always see what it read. quick_estimate reads words the matcher cannot place with the AI model. scope reads with the matcher alone unless you send read: "ai". An answer that used an AI reading is a draft (review.status: "draft") and carries reading: every finding the rules answered, in the shape scope accepts. The same findings under the same ruleset give the same result (result_hash), but a reading can differ from one run to the next, so show the user the findings the AI read before you quote a number.

When to use

• Move-out or turnover inspections, make-ready planning, "what will this turn cost", "what do I send the painter", owner approval estimates.
• Re-running an estimate with the owner's approve/decline decisions or the manager's own vendor prices.

When not to use

• Diagnosing mold, asbestos, lead, gas, electrical or structural hazards. The engine flags these for a licensed professional; do not price their remediation yourself.
• Legal advice on deposits or tenant charges. Responsibility labels are hints only.
• Remodels, new construction, non-US properties.

How to call it

• MCP (preferred in assistants): add the remote server https://tektolo.com/mcp. Start with property_turnover_quick_estimate (zip, bedrooms, bathrooms and issues as plain strings); use property_turnover_scope for rooms, measured quantities, rate cards and decisions. property_turnover_issue_codes with no arguments lists the areas and codes. If the ZIP is missing or not 5 digits, ask the user; never guess it. For the Excel or owner estimate, give the user links.web_tool_prefilled from the result.
• REST: POST https://tektolo.com/v1/property-turnover/scope with the JSON below. Downloads: POST .../scope/render/xlsx (workbook), .../render/html (owner estimate), .../render/csv (work orders), .../render/vendor_csv (zip of per-trade scopes), .../render/bids_html (work lists for bids: one section per trade, no prices).
• Catalog and schemas: https://tektolo.com/catalog.json, https://tektolo.com/capabilities/property-turnover.
• Web: the free tool is https://tektolo.com/tools/rental-property/property-turnover; typical costs by area are at https://tektolo.com/turnover-costs/.
• Next step: the scope is step 1 of the move-out workflow; step 2 settles the security deposit (deposit_settlement_settle, web tool /tools/rental-property/deposit-settlement).

Building the request

1. property: zip (5 digits, never a street address), bedrooms (0 = studio), bathrooms (halves as 0.5), and if known sq_ft, year_built and unit_type. Year built matters: pre-1978 triggers lead-safe-work handling (priced). unit_type single_family or townhome gets house-sized defaults (floor area, lock count, yard). If you know whether there is carpet, send floor_coverings: {"carpet_present": true} or {"carpet_sq_ft": 600}. Without it, carpet findings imply carpet; otherwise whole-unit carpet cleaning is left out and listed in unknowns.
2. findings: one per observed condition.
   • Use code when you know it (e.g. walls.nail_holes, carpet.pet_urine), otherwise a short plain description ("dog urine stains in bedroom carpet"). Words the matcher cannot place come back as a manual-quote line with suggested_codes; resend with a code. With read: "ai" they go to the AI reader first: a finding it reads comes back with resolution: "ai" and needs_review: true, its lines are flagged, and the answer is a draft. A finding sent with a code never goes to the AI model.
   • To confirm what the AI read, send the findings from reading.findings back to scope (keep each finding's extraction, fix any the user corrects) with confirmed: true on each one the user checked. The answer is then verified, and the result still shows those findings as read by AI.
   • location.area (bedroom, bathroom, kitchen, living_room, ..., whole_unit) and an optional label ("Bedroom 2").
   • extent: spot | partial | full when you can tell.
   • quantity {value, uom} when measured (sq_ft, sq_yd, linear_ft, each, room, ...). Otherwise typical sizes are assumed and listed.
3. standards.profile: minimum | standard (default) | premium. Optional overrides: paint_policy, carpet_policy, cleaning_policy, always_rekey, markup_pct. standards.price_tier: pm_vendor (default, a manager buying from local vendors) | bulk_contract (portfolio contract prices) | retail_one_off (an owner hiring one contractor).
4. Optional: rate_card (the manager's prices: {task_id, unit_price, uom?} or {trade, min_charge, trip_charge}; whole-unit wall paint is per sq_ft_floor, so send uom to have a mismatched price rejected rather than misapplied), trade_vendors, tax_rate, and decisions ({finding_id | line_id, action: approve|decline|defer}). Re-run with decisions to get the approved scope.
5. detail: MCP defaults to summary (totals, trade scopes, every line tied to a finding, refer-outs, notes; routine lines summed in omitted_note). Ask for full when the user needs every line. A finding's location may be a plain string ("Bedroom 2"). Hedged notes ("mold?") come back as "check first" refer-outs that hold no work until confirmed.

From photos

Tektolo does not look at photos. You do, then you send findings and the engine prices them.

• Describe only what is visible, one finding per condition. Give its location (the room or area) and what it is. Use an issue code when one clearly fits (look it up with property_turnover_issue_codes); otherwise write a short plain description.
• Give extent (spot, partial or full) only when the photo shows how far it goes. Otherwise leave it out and say so in your reply.
• If you are not sure what a photo shows, or how far damage goes, hedge the description ("possible water stain on bedroom ceiling", "mold?"). The engine marks hedged findings uncertain: their lines are priced but kept out of the totals (totals.to_confirm) until someone confirms them, and hedged safety items become check-first refer-outs. You can also ask the user for a better photo or a closer look.
• Ask the user about what photos cannot show, and do not guess it: whether appliances and fixtures work, odors and smoke, pests, and size or extent (square feet, counts). Send a quantity only when the user gives you a measurement or a count.
• Never write that the tenant caused something because of a photo. A photo shows a condition, not who caused it. Leave tenant fault out of the descriptions: the responsibility_hint on each line comes from the engine and is only a hint.
• A photo of a written checklist or inspection report is different. Transcribe what it says, as it says it, one finding per entry, and do not add your own reading of the rooms.
• Never send faces, names, addresses or other personal details. Describe the room, not the people or the street.
• Mention what you could not see in your reply, and list what you asked the user to confirm.

Example

{
  "property": {"zip": "28205", "unit_type": "apartment", "bedrooms": 1, "bathrooms": 1, "year_built": 1998},
  "findings": [
    {"code": "walls.nail_holes", "location": {"area": "living_room"}, "extent": "spot"},
    {"description": "carpet heavily soiled in bedroom", "location": {"area": "bedroom"}},
    {"code": "safety.smoke_alarm_missing", "location": {"area": "bedroom"}}
  ],
  "standards": {"profile": "standard"}
}

Relaying the result

• Lead with summary and the expected total plus the range. Say clearly that these are estimate ranges, not quotes.
• Call out every refer_outs item and what professional to engage. Quote-required lines are $0 in the totals; totals.allowances is a budget range for them, outside the total.
• A responsibility_hint of mixed means the line carries wear and damage findings; see its responsibility_by_finding before discussing tenant charges.
• List unknowns and the important assumptions (e.g. assumed room sizes, national prices used), so the user can correct them and re-run.
• When review.status is draft, show the user what was read (reading.findings: the words, the item and the room) before you quote a number, and ask them to confirm or correct it. For a verified answer, send the confirmed findings to scope with confirmed: true.
• Name every finding with needs_review: the AI reader read it from the user's words, so ask the user to confirm it. A review.note means the reader was not available (daily limit or an error) and the text was read by the matcher alone.
• Group the work by trade_scopes when the user wants to brief vendors. Offer the workbook or vendor CSV downloads.
• If the user needs an audit trail, keep the result_hash and run.ruleset_version. Over MCP they come back only when you call with audit: true (REST always returns them).
• If a call says the daily free limit is reached, tell the user when it resets (the message names the time) and do not retry. On a hosted assistant (Claude, ChatGPT) the shared server URL has one limit for everyone; the message names the page for a free personal connector URL. Volume and integrations go through the Contact page.

Make it yours

Fork this skill and add your company's standards (default profile, paint/carpet rules, markup), your rate_card, and your trade_vendors, so every estimate uses your prices and vendors.