Docs.

This document describes how the rental operation runs day-to-day: from the moment a producer lands on /rentals to the moment the deposit is released and the gear is back on the shelf. It is written for the person at the desk, not for engineering. Engineering reads this to build the system that supports the process; the desk reads it to know what to do.

Anything that's still a policy decision is flagged with {TBD: see open-questions.md §section}. Do not invent a value when you see that marker — escalate to the owner and update the open-questions doc when it's decided.

1. Operating principles

These seven principles override anything more specific below. When a process step and a principle disagree, the principle wins and the process gets updated.

1. Confirmed reservation wins — no recalls. Once a reservation is confirmed (confirmed) by any party, its gear is unavailable to everyone else, including internal studio.chat productions. studio.chat does not recall gear from a renter for an internal shoot. Internal needs are expressed as blackouts (see §8) set before a conflicting booking confirms; whoever confirms first holds the dates. studio.chat can cancel its own unpaid internal plans to free dates for a paying client, but a confirmed booking — internal or external — is firm.

2. The deposit is the protection. There is no vetting and no insurance. The gate on every rental is the same: pay the 100% replacement-value deposit, present a valid photo ID, and have a verified contact phone and email. The deposit covers loss and damage; the desk does not run background checks, request proof of project, or sort renters into tiers. The desk may still decline an obviously fraudulent request, but the standing protection is the deposit, not a gatekeeping process.

3. One source of truth. The rental system knows what's where, in what condition, and when. No parallel spreadsheets, no "I'll just text the DP." If the system doesn't reflect reality, the system is wrong and needs to be fixed; the workaround is not the answer.

4. Quote-first, never instant. Every rental in v1 goes through a human quote step. No item is reservable by a stranger without desk approval. This is what lets us collect the deposit, verify ID and contact, and enforce lock-outs without complex automation. Direct checkout is a v2 question.

5. Document at the moment, not later. Condition reports, signatures, photos, and damage notes happen at the counter, not retroactively. If a detail isn't captured at pickup or return, it didn't happen — we cannot prove it later, and we won't try.

6. Bilingual by default. Every client-facing artifact (quote, contract, confirmation, reminder, receipt) exists in EN and ES. The client's preferred language is set at inquiry and propagates through every touchpoint. Internal records may be EN-only for the team's sanity, but anything signed by a client is in their language.

7. Small and curated, not big and broken. We do not chase items we can't service, clients we can't vet, or volume we can't fulfill. A small clean rental book is a feature, not a limitation.

2. Client lifecycle (happy path)

End-to-end sequence for a clean rental. Each phase identifies who acts, what the system does, what artifact is produced, and what state the reservation is in afterward.

State machine, for reference. The names in code font are the real reservation statuses the system stores (reservations.status); the plain-English label before each is what the desk says out loud. Use the code names when reading the system; use the labels when talking to a human. There is no separate "draft" status — the first record a client creates is already inquired.

Inquiry (inquired) → Quoted (quoted) → Held (held) → Confirmed (confirmed)
   → Returned (returned) → Settled (settled) → Closed (closed)

Cancel branch:  inquired | quoted | held | confirmed → Cancelled (cancelled)
Dispute branch: returned | settled → Disputed (disputed) → settled | closed

Full transition map (this is the canonical machine; the system rejects any jump not listed here):

Two things to internalize. held vs confirmed is a real, separate step: held blocks the gear on the calendar the moment a deposit is taken; it promotes to confirmed once that deposit has actually cleared. Gear being out is not a status. A confirmed reservation covers the whole fulfilment window: the first unit scanned out stamps the pickup time (picked_up_at) and the reservation stays confirmed; per-unit scans track exactly which units are out; the last unit scanned back flips the reservation to returned, where the post-return condition check happens before settlement. A confirmed reservation past its return date with gear still out is overdue.

2.1 Discovery

Actor: Client.

What happens: A producer (or first AD, DP, gaffer, line producer) arrives at studio.chat/rentals or studio.chat/es/rentals. They browse the curated catalog, read the pricing framework (see §5), and form an intent to rent.

System: Serves the public catalog. Records page visits (analytics only, no PII). Does not yet know the client exists.

Artifact: None.

State: No record yet.

2.2 Inquiry

Actor: Client submits the request form. Desk is not involved yet.

Form captures, at minimum:

• Name, company (optional), phone, email, preferred language (EN / ES).
• Items requested (multi-select from catalog).
• Desired pickup date and return date.
• Project context: a short free-text "what's the shoot?" — narrative film, doc, commercial, music video, photo stills, etc. (optional color, not a gate).
• How they heard about us (optional).

System:

1. Validates dates (return ≥ pickup, not in the past, within a reasonable forward window).
2. Cross-references requested items against the production lock-out calendar (see §8) and silently flags conflicts for the desk — does not tell the client "unavailable" at this stage. The desk makes that call.
3. Creates the reservation record in status inquired.
4. Fires the inquiry-acknowledgement email (see §7) in the client's chosen language.
5. Notifies the desk over Slack (the decided inquiry channel; the desk is run by Karen — see §12).

Artifact: Reservation record in the system. Acknowledgement email to client.

State: inquired.

2.3 Intake / verification

There is no vetting. studio.chat does not run background checks, request proof of project, require insurance, or sort renters into tiers. The only gate is the rental gate: a paid 100% deposit, a valid photo ID, and a verified contact phone and email. This phase is just the desk confirming the inquiry is real enough to quote and that the dates are available.

Actor: Desk.

What the desk does:

1. Confirms the contact details are reachable: the phone and email will be verified (a verified email is also what the contract is delivered to for e-signature — see §2.5). If something is obviously bogus, the desk asks for a working phone and email before quoting.
2. Verifies availability against the production calendar one more time manually (the system's check in §2.2 is advisory).
3. Decides: proceed to quote or decline. The desk may still decline an obviously fraudulent or abusive request, but there is no tier to assign and no documents to collect at this stage — ID is presented in person at pickup (see §2.7).

A decline is sent politely, in the client's language, with a short reason ("we're shooting that week"). We don't elaborate beyond a sentence.

System: Records desk notes against the inquiry.

Artifact: Notes on the reservation record.

State: Still inquired. The reservation stays inquired until the desk either quotes it (quoted) or declines it (cancelled).

2.4 Quote

Actor: Desk.

What the desk does: Generates a written quote covering:

• Line items (each rented item, day rate, days, line subtotal). Day rates are NET of IVA and are derived from each item's replacement value by the cost-recovery engine unless a manual per-item rate override is set (the override always wins).
• No multi-item or volume discount. Carts are the sum of their line items; there is no quantity break (see §5).
• Subtotal (net of IVA).
• No damage waiver. studio.chat does not offer a damage waiver — there's no gear-insurance market in Colombia, so the 100% replacement-value deposit is the sole loss-and-damage protection. The quote engine keeps a damage_waiver_usd_cents field as dormant plumbing, but no waiver is presented to renters.
• IVA at 19%, applied to the net total (not to each per-day rate). The rate is a configured setting (iva_rate, default 0.190).
• Deposit (separately stated, refundable). Computed as 100% of cart replacement value (no gear-insurance market in CO); the per-cart $500 floor is dormant at 100%. Studio-space lines add their own flat damage deposit on top.
• Grand total: net rental fees − discount + waiver, then + IVA = the gross the client pays. The deposit is shown but not summed into "fees" because it's refundable.
• Pickup and return windows. Defaults: pickup at 14:00, return by 11:00 (see §2.7). These hours are intended to be office-configurable, but the settings fields are not built yet, so the defaults stand and the desk states them on the quote by hand.
• Valid-until date. An unpaid quote or hold expires after 1 week by default (intended to be office-configurable). Not yet enforced: there's no settings field or expiry job for this today, so nothing auto-expires a quote — the desk tracks validity manually.
• Payment options: Stripe (USD canonical) and/or Wompi (COP, display only). All money is stored in USD cents; COP is a display conversion at the snapshotted rate (see §5.10).

System: Generates the quote PDF in the client's language, attaches it to the reservation, transitions state.

Artifact: Quote PDF (EN or ES). Quote email.

State: quoted.

2.5 Contract + deposit

Actor: Client signs and pays. Desk verifies.

Flow:

1. Client accepts the quote via a link in the email.
2. Client signs the rental contract electronically via Google Docs (the decided e-signature surface). The contract is generated as a Google Doc and emailed to the client and to studio.chat for signature — email is the delivery channel, which is why a verified email is part of the rental gate. Contract is in their language. ES contract is the legally binding version for ES-speaking clients (Colombian law applies). The contract is built around the deposit-only model: the 100% replacement-value deposit covers loss and damage; sub-rental and cross-border are not policed beyond "paid + returned on time in the same condition."
3. Client pays the deposit (and either the rental fees up front, or on pickup — house preference is up front; flexible for repeat clients).
4. System receives the webhook from the payment processor.

Designed, not yet built; confirm. Automated contract generation, email delivery, execution tracking (signature status and timestamps surfaced in the office), and Slack notifications on contract events are the decided design but are not yet wired into the reservation flow. Today the contract is handled manually around the Google Docs surface.

System:

• On signature: stores the signed contract PDF and (per the design above) records execution status and timestamps; surfaces them in the office and fires a Slack notification.
• On deposit receipt: transitions to held. The items are now blocked on the rental calendar.
• Once the deposit has cleared (not just authorized — actually settled), transitions to confirmed. (Promoting only when pickup is within a few days is desk practice, not a system rule — the machine allows held → confirmed at any time.) quoted may also go straight to confirmed when a deposit clears immediately, skipping the explicit hold.

The distinction between held and confirmed is so we can release a hold (held → cancelled) if a payment never settles, without losing the audit trail.

Terminology note: the held status is named reserved in the system as of 0021; the role described here is unchanged.

The confirmation deposit threshold (decided, implemented). "Confirmed" means the reservation has collected enough deposit, defined as:

• Threshold = the first rental day's charge — Σ (qty × the snapshotted day rate) across the lines — or the whole rental subtotal when the rental runs under a day (i.e. it's priced below a full day). Equivalently min(one day's rate, the rental subtotal). It's the rental charge, pre-tax and separate from the replacement-value damage deposit.
• Collected = money actually taken toward the rental: deposit captures + balance charges, net of refunds and released holds. An authorized-but-not-captured hold and damage charges don't count.
• The → confirmed transition is gated on collected ≥ threshold (alongside the existing overlap check). It can't be confirmed until that much has cleared. Computed by getReservationDepositStatus / depositThresholdCents.

Who is a "client". A client is an account that has at least one confirmed reservation (confirmed-or-later status) — i.e. someone who cleared the deposit and booked. Having a profile row is no longer the bar. The accounts registry (/office/accounts) lists every non-staff account — clients and unconverted leads alike — while the "client" subset is what the account stats page (/office/accounts/stats) and the agent's searchClients tool report on (listClients, confirmed-or-later).

Artifact: Signed contract PDF. Deposit receipt.

State: held → confirmed.

2.6 Confirmation

Actor: System (mostly automatic).

What happens: Once confirmed, the client gets a confirmation email with:

• Pickup date, window, address (Medellín, exact address shared at this stage and not before).
• What to bring on pickup day (their copy of ID, anyone they're sending in their place, etc.).
• A short reminder of what's covered by the contract and what isn't.

System: Schedules T-48h and T-2h reminders (see §7).

Artifact: Confirmation email.

State: confirmed.

2.7 Pickup

Actor: Client and Desk, in person.

Pickup / return hours. The default windows are pickup at 14:00 and return by 11:00. The midday gap is deliberate: returns clear and get inspected in the morning so the same unit can go back out at 14:00. These hours are intended to be office-configurable.

Decided policy; configurability not yet built; confirm. The settings fields for pickup/return hours don't exist yet, so today the defaults above are fixed and the desk applies them by hand. Making them office-configurable is a small follow-up build.

Flow:

1. Client arrives at the agreed window. ID is checked against the name on the contract — a valid government-issued photo ID is the in-person half of the rental gate (deposit + ID + verified contact). If a runner is picking up on behalf of the renter, the renter must have notified the desk in writing in advance, and the runner brings their own ID.
2. Desk and client walk through the pickup inspection checklist together (see §6). Each item is checked, serials verified, accessories counted against the packing list, conditions noted with photos.
3. Client signs the condition report on the spot. Photo of the signature page is attached to the reservation.
4. Client takes the gear. Both parties keep a copy of the condition report (PDF to client's email, original in the file).

System: Records the check-out timestamp and assigns specific units to the reservation. Pickup is per-unit: each unit is scanned out individually; the first unit out stamps the pickup time (picked_up_at) and the reservation stays confirmed — gear being out is scan state, not a separate status. Attaches the signed condition report.

Artifact: Pickup condition report (PDF + photos).

State: still confirmed (the desk says "checked out"; the scans, not the status, say the gear is out).

2.8 During rental

Actor: Nobody, ideally.

What happens: Nothing. The client is on set; the gear is in use. Desk does not contact the client during the rental unless:

• The client initiates contact (extension, problem, lost item).
• A T-1 reminder for return is auto-sent on the day before return.

studio.chat does not contact the client to recall the gear for an internal shoot — a confirmed booking is firm (see §1 and §3.8).

System: Watches the calendar. Sends the return-day reminder. Flags late returns once the return window closes — a confirmed reservation whose return time has passed with gear still out is what the office surfaces as "overdue" (see §3.4).

Artifact: None.

State: confirmed (gear out, per the scan state).

2.9 Return

Actor: Client and Desk, in person.

Flow:

1. Client arrives within the return window.
2. Desk and client walk through the return inspection checklist (see §6), comparing each item to its pickup condition. Discrepancies are noted with photos.
3. If no damage and nothing missing: both sign the return condition report. Client leaves; settlement is queued.
4. If damage or missing items are found: a short conversation about what we observed, photos taken, item flagged, client notified that settlement will be delayed pending assessment (see §9). Client still signs the return report; their signature is "I acknowledge what was observed," not "I accept liability for it."

System: Return is per-unit, mirroring pickup. As units come back the reservation stays confirmed (the per-unit scan state makes a partial return visible). Once the last unit is scanned in, it advances to returned — the state in which the condition walkthrough above is recorded and which gates settlement. Records the check-in timestamp and attaches the signed return condition report.

Artifact: Return condition report (PDF + photos).

State: confirmed → returned on the last unit. (The post-return inspection happens while the reservation sits in returned; a partial return is visible from the scan state, not a separate status.)

2.10 Settlement

Actor: Desk + Bookkeeper.

Clean return (no damage, on time):

• Deposit released within 3 business days.
• Client receives a receipt summarizing the rental and confirming deposit release.

Damaged or late return:

• Deposit held until damage assessment is complete (see §9). SLA: 5 business days for cosmetic, 10 business days for functional, longer if outside repair estimates are required.
• Late fees calculated per §3.4.
• Charges applied against the deposit. Excess refunded; shortfall billed.
• Receipt sent with line-item breakdown.

Artifact: Final receipt. Damage settlement statement, if applicable.

State: settled (reached from returned). If the client contests the assessment, the reservation can move to disputed instead of, or after, settled (see §3.10).

2.11 Post-rental

Actor: System and Desk.

What happens:

1. Items move from "out" back to "available" on the calendar.
2. A review request is sent to the client (optional response).
3. Repeat-client flag is set on the contact record if this was their second+ clean rental. With no vetting tiers, this flag doesn't unlock any reduced gate (the gate is always deposit + ID + verified contact); it's retained as a relationship signal — useful for prioritizing service and for the metrics in §13. (Standing carries neutral or blacklist; blacklist is the only one that changes behavior — it routes future requests to owner approval, see §3.10. "Repeat" is derived from paid reservations (>= 2), not a stored standing.)
4. The reservation can be archived (soft-deleted) from the /office/data console: archiving sets deleted_at, which hides the row from every normal office view while keeping it fully recoverable (restore) or permanently removable (purge). Archival is a deliberate desk action, not an automatic 90-day job.

   Inferred design — not yet built; confirm. A scheduled auto-archive of closed reservations after a retention window (e.g. 90 days) is not implemented; today archival is manual.

Artifact: Optional review.

State: closed.

3. Edge cases / unhappy paths

These are the not-fun branches. Each is described as a sub-process the desk can run without escalating, unless explicitly noted.

3.1 Extension mid-rental

Trigger: Client messages "can I keep it through Friday?"

1. Desk checks calendar against production lock-out and other bookings.
2. If clear: confirm extension in writing (email reply), update the reservation with new return date, calculate prorated rate (see §5), send a supplemental quote. Client pays the delta within 24h or the extension reverts to original return date.
3. If not clear: offer the client the latest possible return, or a firm "no" with the reason ("we have a shoot Monday at 8am").
4. The original signed contract is amended via email confirmation; we do not re-sign for short extensions.

A new extension is a separate transaction. The deposit is already 100% of replacement value, so extending the dates doesn't change it; adding items to the extension recomputes the deposit on the new cart.

3.2 Cancellation before pickup

Client cancels in writing. Refund schedule, by days from cancellation to scheduled pickup:

The deposit is always returned on cancellation (no gear changed hands). The rental-fee tiers above are a starting framework; final percentages are {TBD: see open-questions.md §pricing}.

System transitions: held or confirmed → cancelled (a quoted reservation that never paid can also be cancelled). Cancelling releases any assigned units back to the calendar.

3.3 No-show on pickup

Trigger: Pickup window closes; client has not appeared and has not messaged.

1. Desk attempts contact (call, then SMS, then email) within 2h of the close of the window.
2. If no response by end-of-day: the reservation is treated as a no-show.
3. Rental fees forfeited (subject to the cancellation schedule, treated as "0 days to pickup").
4. Deposit refunded.
5. If we later learn the client had a real emergency, the owner can override and refund the rental fees as goodwill.

System transition: confirmed → cancelled with cancel_reason recorded as no_show.

3.4 Late return

Trigger: Return window has closed; gear is not back.

1. Grace period. First 2 hours past the return window, no fee. Desk contacts the client to confirm ETA.
2. Same-day late, past grace. A flat late fee — {TBD: see open-questions.md §pricing} — is logged but not charged immediately.
3. Overnight late. A full additional day rate accrues per day late, per item. The client is notified by end of day 1.
4. 3+ days late, no contact. Treated as potential loss (see §3.6). Owner is informed; legal options reviewed.

Late fees come out of the deposit at settlement. If they exceed the deposit, the client is billed.

3.5 Damaged item

See §9 for the assessment process. Short version of the workflow:

Minor / cosmetic (scratch, missing lens cap, frayed cable):

• Desk decides, logs the cost, applies against deposit.
• Client notified within 24h with photos and the line item.

Major / functional (lens won't focus, sensor scratch, water damage, broken mount):

• Owner / DP / tech lead assesses.
• Outside repair estimate obtained.
• Client notified within 5 business days with photos and the estimate.
• Charge applied against deposit; balance billed if estimate exceeds it.

Total loss (dropped on rocks, fire, theft):

• Owner decision. See §3.6 (loss) and §9 (assessment).
• Replacement value charged against the deposit (which is 100% of replacement value); there is no insurance to claim against.

3.6 Lost or stolen

Trigger: Client reports the item lost or stolen, or the item fails to return and client is non-responsive past 3 days.

1. Police report required. Client must file a denuncia with the relevant Colombian authority (or local equivalent if outside MDE) within 24h of the loss and provide a copy. There is no insurance either way: liability falls on the renter and is settled against the 100% deposit. The police report is required for our records and any later legal action, not to support an insurance claim.
2. Desk notifies the owner immediately upon report.
3. The lost unit is taken out of circulation in inventory; remaining items in the reservation continue normally if they're back.

   Asset condition is like_new / good / fair / service / retired / lost, where lost = lost or stolen — a real state given there's no gear-insurance market in CO, distinct from retired (deliberately taken out of service). A lost asset is non-serviceable, so it's never assigned at pickup. (Item availability is separate: draft / available / private / sold / damaged.)

4. Replacement value (from the inventory record, not subjective) is billed, settled first against the 100% deposit; any shortfall is billed direct to the renter.
5. If criminal activity is suspected on the renter's part, owner decides on legal action.

3.7 No insurance flow

There is no insurance. studio.chat does not require, accept, or process a certificate of insurance, and renters do not file claims through us. Loss and damage are settled directly against the 100% replacement-value deposit, with any shortfall billed to the renter (see §3.5, §3.6, and §9). This section is retained as a deliberate "not applicable" so the numbering of §3.8–§3.10 (referenced elsewhere) stays stable.

3.8 studio.chat needs the gear but it's already booked

Decided: confirmed-reservation-wins, no recalls. Once any reservation is confirmed (confirmed), its gear is locked to that booking and is not recalled — not even for an internal studio.chat shoot. There is no contractual recall clause. studio.chat protects its own dates by entering blackouts (see §8) before a conflicting booking confirms; whoever confirms first holds the dates.

What the desk can do:

1. Plan ahead with blackouts. Internal production needs go in as asset_blackouts / space_blackouts for the dates required. A blackout entered before an external booking confirms keeps the gear off the external inquiry form for those dates.
2. Cancel unpaid internal plans to free dates. If studio.chat's own internal plan for some dates is still unpaid (no confirmed paying booking behind it), an admin can cancel it in the system to open those dates for a paying client. This is the only override, it's a manual desk action, and it only works against studio.chat's own unpaid plans — never against a confirmed external booking.
3. If the gear is already booked externally, it stays booked. The internal shoot finds another unit, sources it elsewhere, or moves its dates. The renter is not contacted to give the gear back.

This is a deliberately simple rule: no special system accommodation is built for an internal-override-over-a-confirmed-booking, because that case does not exist. The lever is timing — get the blackout in before the booking confirms.

3.9 Multi-item rental, partial damage

When some items return clean and others don't:

• Clean items are settled normally (their share of the deposit released promptly).
• Damaged items go into assessment.
• Deposit is logically apportioned by item replacement value; if the damaged item's share covers the assessed damage, the rest is released.

Practically: don't make the client wait on a clean lens because a matte box is being assessed.

3.10 Dispute / chargeback

Trigger: Client disputes a charge with their card issuer or refuses to acknowledge an invoice.

1. Desk gathers the full file: signed contract, condition reports, communications log, photos, receipts.
2. Owner reviews. If the dispute is clearly invalid (signed condition report shows damage, client signed it), we respond to the issuer with the file.
3. If the dispute is borderline (damage was real but the client contests scope or amount), owner may negotiate a partial settlement to close it out.
4. The client is flagged in the system (standing set to blacklist). Future rentals from this client require owner approval.

The reservation itself moves to the disputed status (reachable from returned or settled). From disputed it can resolve to settled or closed once the dispute is worked out — the machine supports going back and forth between settled and disputed until it closes.

We do not chase small chargebacks in court; we do flag and refuse repeat business.

4. Rental gate (no vetting, no insurance)

There is no vetting framework and no insurance. studio.chat does not sort renters or carts into tiers, does not require proof of project, and does not require or accept a certificate of insurance. The earlier Tier A / B / C system has been removed.

The gate is the same for every rental, every item, every client:

1. 100% deposit. The deposit equals 100% of the cart's replacement value (see §5.6). It is the sole loss-and-damage protection.
2. ID. A valid government-issued photo ID (cédula, passport, or equivalent foreign ID), presented at pickup and checked against the name on the contract (see §2.7). No proof of address.
3. Verified contact. A verified phone and email. The verified email is also the channel the contract is delivered to for e-signature (see §2.5).

That's the whole gate. There are no first-time-renter caps, no student gradations, no replacement-value thresholds, and no per-item requirements beyond it.

Schema teardown done. The vetting/insurance schema — the rental_tier enum, items.tier, items.requires_coi, kits.tier, and the settings.tier_b_* / settings.tier_c_* thresholds — was removed in migration 0005. No policy in this document depends on them. The clients.trust_tier field is unaffected and kept (its blocked value was renamed to blacklisted in the same migration).

5. Pricing structure (framework, not numbers)

Numbers are deliberately not in this doc. They live in the settings table and the quote generator. Below is the model. Where the shipped quote engine already implements a piece of this, it's noted inline; where a setting exists but the engine doesn't yet apply it, that's called out too, because the desk should not promise behavior the system doesn't compute.

5.1 Day rate

The base unit. The day rate is "a full 24h period, picked up and returned within the agreed windows." It is net of IVA and is derived from each item's replacement value by a per-class cost-recovery model, not stored as a flat number — unless an item carries a manual day-rate override, which always wins. (Shipped: deriveDayRateUsdCents / effectiveDayRateUsdCents in the pricing engine.)

5.2 Weekly multiplier

Decided and shipped: the "3-day week." The engine charges week_multiplier days per week (default 3.00) — so a 7-day rental costs 3 day-rates, capped — and weeks stack: a 14-day rental is 2 weeks. The per-week remainder is capped at one week's charge. A manual per-item weekly rate override, if present, replaces the derived week price.

Beyond 7 days, weeks stack as above. Sub-day pricing (half-day) is described in §5.4.

5.3 Weekend rate

Decided: a weekend is 3 days at the day rate. A weekend = Friday + Saturday + Sunday = 3 calendar days, each billed at the normal day rate. No surcharge, no discount. This is already the current behavior: the quote engine bills calendar days, so a Fri–Sun rental is simply 3 day-rates (subject to the 3-day-week cap once it stacks into a full week, §5.2). The weekend_multiplier setting (default 1.00 = day rate) is kept as a dormant, no-op lever for future weekend pricing, but it is not applied per-day today.

5.4 Half-day rate

For same-day pickup and return in the same business day, a half-day rate applies. A half_day_multiplier setting exists (default 0.60), but the quote engine does not yet apply it — rentalDaysBetween floors at 1 full day. So half-day is configured but not computed; the value and the wiring are open — {TBD: see open-questions.md §pricing}.

5.5 Late return rate

Settings exist for this — late_grace_minutes (default 60) and late_per_day_factor (default 1.00) — but the quote engine does not yet compute late fees; they are a manual desk calculation at settlement today. The intended model:

• Hourly late beyond grace: pro-rata of the day rate, rounded up.
• Per-day late: late_per_day_factor × day rate per item per day.
• These are floors. If a late return cascades into a missed booking for another client, the late renter may also be liable for the lost booking — case by case, owner decides.

Partially shipped (2026-06-10). The daily overdue cron flags every confirmed reservation past return_at + grace and computes this late-fee model into the audit payload as advisory numbers — nothing is charged automatically; the desk records any late fee manually at settlement.

5.6 Deposit

Decided and shipped: the gear deposit is deposit_percent of the cart's total replacement value (now 100% — no gear-insurance market in CO), floored at deposit_minimum_usd_cents ($500.00, dormant at 100%). The floor only applies when the cart actually contains replacement-valued gear, so a space-only reservation isn't saddled with the gear minimum. Studio-space lines add their own flat, refundable damage deposit on top of the gear deposit.

Replacement value is the admin-maintained value on the inventory record (items.replacement_value_usd_cents) — not "what we paid" and not "what it sells for used." A replacement_value_updated_at stamp tracks freshness; the values are refreshed via the replacement-prices runbook.

5.7 No multi-item / volume discount; bundles deferred

Decided: no multi-item or volume discounts (for now). A cart is priced as the straight sum of its line items. There is no quantity break for renting many items, and no ad-hoc multi-item discount tier.

Pre-defined kits / bundles (e.g. an "interview kit" priced as a single unit below the sum of its parts) are deferred — an "add later" feature. Today there is no bundle pricing; a kit is quoted as its individual line items.

5.8 Damage waiver — not offered

Decided: studio.chat does not offer a damage waiver. There's no gear-insurance market in Colombia, so the 100% replacement-value deposit (§5.6) is the sole damage and loss protection (there is no insurance or COI — see §4). The renter's liability is not bought down.

The quote engine still accepts a waiver amount (damage_waiver_usd_cents) and folds it into the net total, so the plumbing exists — but it is dormant. No waiver is presented or sold to renters, and the desk should never quote one.

5.9 Cancellation refund schedule

See §3.2. Tiered by days-to-pickup.

5.10 Tax (IVA) and currency

IVA. Decided and shipped: 19% Colombian IVA, stored as iva_rate (default 0.190), applied to the net total (subtotal − discount + waiver), not to each per-day rate. The quote engine returns both the net total and the gross (net + IVA); the gross is what the client pays, excluding the refundable deposit.

Currency. Decided and shipped: USD cents are canonical. Every stored amount — line totals, subtotal, deposit, total, payments, claims, replacement values — is in USD cents. COP is display only, converted at a snapshotted rate. Each reservation freezes the conversion rate at creation (fx_rate_snapshot), sourced from the org-level cop_per_usd_snapshot setting, so a historical quote always reconverts at the rate in force when it was made. Payment provider is Stripe for USD; Wompi can present COP, but the ledger stays in USD cents either way.

5.11 Cleaning fee — a condition penalty, not a flat fee

Decided: the cleaning fee is a condition penalty, not a standing fee. There is no flat cleaning or sanitization fee added to every rental. Instead, a percentage charge is applied at return / inspection only if an item is not returned in the same condition it went out in (e.g. returned dirty, with residue, or otherwise needing cleaning to restore its pickup condition). It is assessed against the deposit at settlement like any other condition deduction (see §9).

The percentage is TBD — do not quote a number. And this is not built yet: there is no charge surface for it in the system today, so when it applies the desk logs it manually at settlement. Documented here as policy; the rate and the wiring are both pending — {TBD: see open-questions.md §pricing}.

6. Inspection checklist (pickup + return)

This is a literal checklist. It should be printed and used at the counter, or run on a tablet with photos attached as boxes are ticked.

6.1 Camera body (per unit)

[ ] Serial number matches inventory record: ____________________
[ ] Body cosmetic condition: clean / scuff / dent (circle + photo)
[ ] Mount: clean, no debris, no bent pins
[ ] Sensor: visual inspection, no scratches, no embedded dust visible
[ ] Display / EVF: powers on, no dead pixels, no cracks
[ ] All function buttons respond
[ ] Card slot(s): no debris, door closes cleanly
[ ] Battery door / grip mount: secure
[ ] Strap lugs and 1/4"-20 / 3/8" threads: clean
[ ] Records test clip to provided media (pickup only)
[ ] Media wiped or formatted appropriate to renter's workflow (return only)
[ ] Firmware version recorded: ________
[ ] Time on body / shutter count: ________

6.2 Lens (per unit)

[ ] Serial number matches inventory record: ____________________
[ ] Front element: clean, no scratches, no fungus (photo if uncertain)
[ ] Rear element: clean, no scratches
[ ] Aperture: smooth across full range
[ ] Focus ring: smooth, no play
[ ] Zoom ring (if applicable): smooth, no slipping
[ ] Image stabilizer (if applicable): toggles, audible engage
[ ] Mount: clean, no bent contacts (electronic) or scoring (PL)
[ ] Hood present and clean
[ ] Front and rear caps present
[ ] Lens case / pouch present

6.3 Audio

[ ] Mic body cosmetic: clean (photo any dent or paint chip)
[ ] Capsule: protected with foam or basket as appropriate
[ ] Cables (per cable):
    [ ] Connectors clean and seat firmly
    [ ] Strain relief intact
    [ ] No nicks or exposed conductor
[ ] Recorder powers on, runs through menu
[ ] Recorder media slot clean
[ ] Phantom power test (pickup only)
[ ] Wind protection (deadcat, blimp): condition noted
[ ] Batteries: included count and type confirmed

6.4 Lighting

[ ] Fixture cosmetic: clean (note dents, scorch marks)
[ ] Power lead / appliance inlet: undamaged
[ ] Yoke and stand mount: secure, all knobs present
[ ] Diffusion panels / barn doors: present and undamaged
[ ] Color filters / gels included per packing list
[ ] Bulb (if applicable): no chips, no halo cracks
[ ] LED fixtures: powers on, runs through full intensity and color range
[ ] Cooling fan: runs quietly, no rattle
[ ] Carrying case / soft bag: present and zips closed

6.5 Grip

[ ] Stand: extends and locks fully
[ ] All knobs and clamps present and tight
[ ] Spreader (if applicable): intact
[ ] Sandbags: present, no leaks
[ ] Apple boxes: present per packing list, no major splits
[ ] Flags and nets: fabric intact, frame not bent

6.6 General / kit-level

[ ] Case / pelican: closes and latches; foam present
[ ] Packing list reconciled: every item present, photographed at counter
[ ] Batteries: charged to ≥80% (pickup only)
[ ] Media / cards: blank and formatted (pickup); cleared (return)
[ ] Accessories per inventory record: cables, chargers, manuals, etc.
[ ] Any items the renter is bringing back early flagged separately
[ ] Renter signs condition report
[ ] Desk signs condition report
[ ] PDF emailed to renter

7. Communications playbook

Every client is tagged with a language preference (EN or ES) at inquiry. Every touchpoint below is sent in that language. The table lists the trigger, channel, and content summary.

Bilingual operating note. The desk handles incoming messages in whatever language the client writes in. If a client's preference was set to EN but they reply in ES (or vice versa), the desk responds in the language of their latest message and updates the preference. The CRM / inquiry record stores both the original preference and a last_known_lang field.

Off-template communications (extensions, problems, damage notifications) are written by the desk in the client's language. The desk lead is fluent in both. If they need help with phrasing, the standard reply library (kept in the team wiki) has bilingual versions of the most common notes.

8. Production lock-out (blackout) workflow

The system must never offer the same item to an external client when studio.chat needs it for a shoot. The mechanism is the blackout, and the rule is confirmed-reservation-wins: whoever confirms a date first holds it. A blackout is how studio.chat confirms its own dates first.

8.1 How a blackout is created

1. Producer or Owner books a shoot. Internal production calendar gets the dates.
2. Producer creates a blackout entry in the rental system covering:
   • Date range (start, end). Include teardown / return-to-shelf time.
   • Items or spaces needed — asset_blackouts for gear (one row per unit — black out every unit to hold a whole item), space_blackouts for studio space.
   • Reason / project tag (internal only; never shown to external clients).
3. System applies the blackout immediately. Items inside the range become non-bookable to external clients via the inquiry form.

Blackouts are explicit date ranges. There is no configurable lock-out "window" — the old blackout_default_days setting was dropped in migration 0002, so a blackout covers exactly the dates entered, nothing implicit.

8.2 No lead-time window — get in first

There is no lock-out lead-time buffer to configure. Because a confirmed booking is firm and is never recalled (see §1, §3.8), the only lever is ordering: a blackout entered before a conflicting external booking confirms holds the dates; a blackout entered after does not displace that booking. The practical "lead time" is simply "blackout your shoot dates before someone books over them."

8.3 Conflict at inquiry time

When a client submits an inquiry that overlaps a blackout:

• The system flags the inquiry to the desk but does not auto-reject.
• Desk evaluates: can we partially fulfill (different days, alternate item)? Reply offering an alternative or politely declining.
• We don't disclose the reason ("we have an internal shoot") beyond "those items aren't available those dates."

8.4 Internal shoot lands after an external booking confirms

When studio.chat decides it needs gear that is already confirmed (confirmed) to an external rental, the booking wins. The producer:

• Sources the gear elsewhere, finds another unit, or moves the shoot dates. The external renter is not asked to give the gear back.

If the competing internal plan is still unpaid (no confirmed paying booking behind it) and a paying client wants the dates, an admin can cancel studio.chat's own unpaid plan to free them — the one allowed override, and only against studio.chat's own unpaid plans (see §3.8).

9. Damage assessment process

Triage decides who decides.

9.1 Cosmetic damage

Examples: scuff on body, missing lens cap, frayed cable, lost sandbag, bent flag frame.

• Decided by: Desk Lead.
• Process: Photo, log, attach a replacement or repair cost from the inventory record (we maintain a small price list for common small parts and cosmetic items). An item returned dirty or not in the same condition it went out in is also handled here, via the cleaning-fee condition penalty (§5.11) — a percentage charge, %-TBD, logged manually today.
• Notification: Client within 24h, with photo and itemized cost.
• Settlement SLA: 5 business days from return.

9.2 Functional damage

Examples: lens won't focus, sensor scratched, mount damaged, recorder won't read media, fixture won't power on, broken iris.

• Decided by: DP / Tech Lead (whoever owns the gear category), with Desk Lead present.
• Process: Internal test to confirm the failure. If confirmed, send to authorized service for an estimate.
• Notification: Client within 5 business days, with estimate and photos.
• Settlement SLA: 10 business days from return, or 5 business days from receipt of repair estimate, whichever is later.

9.3 Total loss

Examples: dropped from height, water/fire damage, theft.

• Decided by: Owner.
• Process: Document everything. If theft or loss, police report required from renter (see §3.6). There is no insurance (see §3.7).
• Notification: Client within 2 business days, in writing, formally.
• Settlement: Replacement value charged, settled against the 100% replacement-value deposit; any shortfall billed direct to the renter. There are no insurance proceeds. SLA on settlement closes when the renter has paid in full.

9.4 Notification format

Always written, always in the client's language, always with photos attached. Phone calls are fine for urgency but never instead of writing. A damage notification states:

• What was observed.
• The condition at pickup vs. at return.
• The assessment tier (cosmetic / functional / loss).
• The amount being held / charged.
• What the client can do (provide additional context, dispute, etc.).
• The settlement deadline.

10. Sub-rental, re-rental, and cross-border — not policed

Decided: studio.chat does not police sub-rentals or cross-border use. The renter on the contract is responsible for the gear, full stop. Whether they hand it to their crew, lend it to another production, list it on their own sub-rental platform, take it to a different project, or carry it across a border is not something studio.chat gates on or restricts.

The only obligations are the contract terms: the rental is paid for (the 100% deposit is held) and returned on time in the same condition. Loss or damage — by the renter or by whoever they handed the gear to — is settled against the deposit (see §9), with any shortfall billed to the renter on the contract.

A different runner may still pick up on behalf of the renter, with advance notice in writing (see §2.7), because that's an ID question at the counter — not a sub-rental restriction.

This is a contract framing, not an operational gate: there is no sub-rental approval workflow, no "vetted project" to confine the gear to (there is no vetting), and no customs process. The exact contract wording that states "you are responsible regardless of who uses it" is {TBD: see open-questions.md §legal} — to be finalized with counsel.

11. Records & audit

What we keep, where, and for how long.

Archival vs deletion (shipped). Reservations, clients, and short links support soft delete: archiving sets a deleted_at marker that hides the row from every normal office view while keeping it recoverable (restore) or permanently removable (purge) from the /office/data console. Catalog tables (items, assets, spaces) are deliberately not soft-deletable yet, because hiding one would also have to hide it from the public catalog and pickers. Every reservation state change is written to an append-only audit_log (with a source of user or api), so the lifecycle is reconstructable independent of the retention table above. The retention durations themselves remain a records-policy decision, not a system-enforced one.

Access controls:

• Desk Lead can read everything except financial summaries and damage decision rationale on disputed items.
• Owner can read and write everything.
• Bookkeeper can read everything financial; can read condition reports only when relevant to a settlement.
• DP / Tech Lead can read inventory condition history and damage assessments for items in their category.
• Clients can request their own records under Colombian data protection law (Ley 1581); the desk has a template response and a 72h turnaround.

Backup: Document storage is backed up off-site nightly. Specifics {TBD: see open-questions.md §tech}.

12. Roles & responsibilities

The Desk Lead role is run by Karen. Inquiries reach the desk over Slack.

RACI table. R = Responsible (does the work), A = Accountable (owns the outcome), C = Consulted, I = Informed.

Conflict resolution. When the Desk Lead and Owner disagree on a borderline call (e.g. whether to decline a request that looks fraudulent, or whether to make a goodwill refund), the Owner's call stands. The Desk Lead documents the override in the reservation record. We review these quarterly to recalibrate.

13. Metrics we'll track

Reviewed monthly by the Owner, quarterly with the team. None of these are public.

13.1 Utilization per item

• Days rented / days available in the period. Days "blocked for production" count as utilization (the gear was being used; we just weren't earning external rent on it).
• Days "in repair" do not count as available.
• Target: each catalog item ≥ 25% utilization across a quarter. Items below 10% are candidates for removal from the catalog.

13.2 Revenue per item

• Rental fees collected per item per period.
• Computed monthly. Compared to depreciation per item.
• An item that doesn't cover its depreciation over a year is a candidate for removal.

13.3 Damage rate

• Rentals with any damage charge / total rentals, per period.
• Target: < 5% of rentals trigger any damage charge.
• Above 10% triggers a review: are we inspecting too lightly, or is the catalog mismatched to our client base? (There is no vetting to loosen or tighten — the deposit is the protection.)

13.4 On-time return rate

• Rentals returned within the window / total rentals.
• Target: ≥ 90%.
• Clients who run < 80% on-time over 3 rentals get flagged.

13.5 Repeat client rate

• % of rentals from clients who have completed at least one prior clean rental.
• Target: ≥ 40% within 12 months of launch.
• A healthy repeat rate is the single best signal that the operation is working as intended.

13.6 Production-rental conflict count

• Number of times an internal shoot lost out to an already-confirmed external booking (gear it wanted was booked first; see §3.8) in the period. Gear is never pulled from a renter, so this counts missed internal needs, not recalls.
• Target: ≤ 2 / year.
• Above that, we're blacking out shoot dates too late (see §8.2) — the fix is earlier blackouts, not a longer lead time.

13.7 Settlement timing

• Median business days from return to deposit release.
• Target: ≤ 3 days for clean rentals, ≤ 10 days for damaged.
• Slow settlement erodes repeat rate; we track it deliberately.

Appendix A — Glossary

• Reservation. The single record that tracks a rental across its whole life, from first request to close. Its status is one of the nine real states: inquired, quoted, held, confirmed, returned, settled, closed, cancelled, or disputed (see the §2 state machine). Gear being out is scan state inside confirmed, not a status. "Inquiry" and "booking" are desk words for early and post-deposit phases of the same reservation, not separate records.
• Cart. The set of items in a reservation while it's still being quoted, before deposit.
• Cosmetic / functional / total loss. Damage tiers in §9.
• Day rate. The base unit of pricing per item.
• Desk. The day-to-day operator of the rental house. Run by Karen.
• Deposit. A hold equal to 100% of the cart's replacement value; studio.chat's sole loss-and-damage protection (see §4, §5.6).
• Inquiry. An unconfirmed request, pre-quote — a reservation in status inquired.
• Lock-out. A range during which an item is blocked from external rental because studio.chat needs it for a shoot.
• Quote. A written, time-limited offer to rent at specified terms.
• Rental gate. The single requirement to rent anything: pay the 100% deposit, present a valid photo ID, and have a verified contact phone and email (see §4). There is no vetting and no insurance.
• Replacement value. What it would cost studio.chat to buy the item again today. Stored on the inventory record. Updated annually.

Appendix B — Process change control

This document changes when policy changes. Process:

1. Proposed change is discussed at the monthly ops review or in an ad-hoc owner-desk conversation.
2. Decision is recorded as a one-line entry in a CHANGELOG section at the top of this file (to be added when the first change lands).
3. Affected sections are edited. Old text is removed, not struck through — git history is the audit trail.
4. The desk reads the diff at the next stand-up.
5. Any open-questions referenced are updated in open-questions.md to reflect the resolution.

If a policy is changed mid-rental for an active booking, the change does not apply retroactively. The contract the renter signed governs their rental.