pearsley
Meghna Rajawatbuild this
Comments (0)
Sign in to leave a comment
Global sending mode set to Drafts-only.
03 / Channel mapping
Which account answers which portal
Every inbound channel is bound to its receiving account, portal, source listing, reply address and CRM unit so an enquiry is never answered from the wrong account.
Channel to unit mapping6 channels mapped
| No. | Channel | Receiving account | Portal | Source listing | Reply address | Mapped CRM unit |
|---|---|---|---|---|---|---|
| 01 | WhatsApp Business | Pearlstay Guest WhatsApp (Business Platform number) | WhatsApp Business Platform | Direct guest conversation (no listing) | Inbound conversation thread — replies sent from the Business Platform number | Unit 21gsc-004 · Arrival information · sent |
| 02 | HousingAnywhere | guest@pearlstay.example (portal mailbox) | HousingAnywhere | Unit listings published on HousingAnywhere | Reply routed through the HousingAnywhere portal thread | Unit 12gsc-001 · General question · answered |
| 03 | Homegate | guest@pearlstay.example (portal mailbox) | Homegate | Unit listings published on Homegate | Reply routed through the Homegate listing inbox | Unit 03gsc-003 · Access code request · blocked |
| 04 | ImmoScout24 | guest@pearlstay.example (portal mailbox) | ImmoScout24 | Unit listings published on ImmoScout24 | Reply routed through the ImmoScout24 listing inbox | Unit 12gsc-001 · General question · answered |
| 05 | Flatfox | guest@pearlstay.example (portal mailbox) | Flatfox | Unit listings published on Flatfox | Reply routed through the Flatfox listing inbox | Unit 12gsc-001 · General question · answered |
| 06 | Designated Gmail inbox | guest@pearlstay.example (Gmail) | Direct email (no portal) | Direct enquiries raised against a unit listing | enquiries@pearlstay.example | Unit 07gsc-002 · Operating problem · escalated |
- 01
WhatsApp Business
- Receiving account
- Pearlstay Guest WhatsApp (Business Platform number)
- Portal
- WhatsApp Business Platform
- Source listing
- Direct guest conversation (no listing)
- Reply address
- Inbound conversation thread — replies sent from the Business Platform number
- Mapped CRM unit
- Unit 21gsc-004 · Arrival information · sent
- 02
HousingAnywhere
- Receiving account
- guest@pearlstay.example (portal mailbox)
- Portal
- HousingAnywhere
- Source listing
- Unit listings published on HousingAnywhere
- Reply address
- Reply routed through the HousingAnywhere portal thread
- Mapped CRM unit
- Unit 12gsc-001 · General question · answered
- 03
Homegate
- Receiving account
- guest@pearlstay.example (portal mailbox)
- Portal
- Homegate
- Source listing
- Unit listings published on Homegate
- Reply address
- Reply routed through the Homegate listing inbox
- Mapped CRM unit
- Unit 03gsc-003 · Access code request · blocked
- 04
ImmoScout24
- Receiving account
- guest@pearlstay.example (portal mailbox)
- Portal
- ImmoScout24
- Source listing
- Unit listings published on ImmoScout24
- Reply address
- Reply routed through the ImmoScout24 listing inbox
- Mapped CRM unit
- Unit 12gsc-001 · General question · answered
- 05
Flatfox
- Receiving account
- guest@pearlstay.example (portal mailbox)
- Portal
- Flatfox
- Source listing
- Unit listings published on Flatfox
- Reply address
- Reply routed through the Flatfox listing inbox
- Mapped CRM unit
- Unit 12gsc-001 · General question · answered
- 06
Designated Gmail inbox
- Receiving account
- guest@pearlstay.example (Gmail)
- Portal
- Direct email (no portal)
- Source listing
- Direct enquiries raised against a unit listing
- Reply address
- enquiries@pearlstay.example
- Mapped CRM unit
- Unit 07gsc-002 · Operating problem · escalated
Mapping rules3 rules
- One unit per mapping
Every portal account, mailbox and listing maps to exactly one CRM unit. A mapping is never shared across two units, so a received message resolves to a single unit.
- Notification senders are not guests
Automated portal and system notifications are treated as senders of a message, never as guests. They are excluded from identity matching and never receive a guest reply.
- One active response workflow
A single active response workflow exists per matched enquiry. Later messages from the same enquiry attach to that workflow instead of opening a second one.
Channel capability caveats3 entries
WhatsApp Business PlatformBlocking · Consent required
Template-initiated contact requires documented consent for the contact. Without a documented consent record the channel stays inbound-first and no template-initiated message is prepared.
Linked casegsc-004 · Unit 21HousingAnywhereReview · Pending permitted use
The HousingAnywhere PDF handover asset containing the WhatsApp number is pending confirmation of permitted use. Until that confirmation is recorded, communication stays on-platform.
Linked casegsc-001 · Unit 12All channelsInformational · On-platform until confirmed
While a handover asset is unconfirmed, replies are prepared as drafts and manual tasks on the platform. No message is dispatched through the unconfirmed asset.
Linked caseNo linked case
SOURCE: Channel mapping · SHEET v2.10 · VALIDATED 15 Oct 2026 14:02 Europe/Zurich
Inbox · 04
Read-only register · Unified inbox
Reply tracking
Every enquiry keeps one tracked response state. Each row carries its channel, the reply state, the last activity, the owning team and the next due follow-up, so an unchecked or duplicated send is visible rather than assumed.
Reply-tracking register
04 tracked replies
| Severity | Channel | Reply state | Last activity | Owner | Next due follow-up |
|---|---|---|---|---|---|
| Email / portalUnit 12 · M. KellerOwnerGuest SupportNext due2026-10-22 | Reply sent | 2026-10-15 09:41 | Guest Support | 2026-10-22Seven days from 2026-10-15 | |
| WhatsAppUnit 07 · A. BrunnerOwnerOperationsNext due2026-10-22 | Awaiting response | 2026-10-15 08:20 | Operations | 2026-10-22Seven days from 2026-10-15 | |
| WhatsAppUnit 03 · L. MeierOwnerAccountingNext dueNone | Follow-up stopped | 2026-10-15 06:05 | Accounting | NoneFollow-up stopped | |
| HousingAnywhereUnit 21 · S. WeberOwnerGuest SupportNext due2026-10-20 | Reply sent | 2026-10-13 14:02 | Guest Support | 2026-10-20Seven days from 2026-10-13 |
Tracking rules
Replies are matched to the original thread and message IDs before the register is updated.
Duplicate sends are prevented across imports and retries; an uncertain send is reconciled before any retry.
A reply, bounce or decline stops further follow-up for that enquiry; no second general follow-up is issued.
SOURCE: Reply tracking · SHEET v2.10 · VALIDATED 15 Oct 2026 14:02 Europe/Zurich
Source:Unified inboxSheet v2.10Validated 15 Oct 2026 14:02 Europe/Zurich
Global sending mode set to Drafts-only.
Pearlstay / Corporate AIOne CRM. Traceable rules. No unchecked sends.
A WhatsApp AI for guests and prospects, and one CRM for rentals, accounting, rent collection and Beds24 channel management. Every rule is versioned, every check is recorded, and nothing is sent until its conditions are revalidated.
02 / System overview
How an inbound message is processed
Gates 01-06
An inbound WhatsApp message is authenticated, deduplicated and classified, then checked against availability, price, payment status, permissions and approvals before any reply is sent. It exits into exactly one of two coded outcomes.
- Automaticevery gate passed
- Drafts-onlyheld for staff review
- Inbound messageGuest or tenant messages the Pearlstay WhatsApp number.
- 01AuthInbound message authenticated to the connected WhatsApp sender.
- 02DedupeDeduplicated on message ID so no request is processed twice.
- 03IntentRequest intent classified and current unit context loaded.
- 04Hard checksAvailability, price, payment status, permissions and approvals.
- 05ConfidenceCalibrated score returned with the drafted reply.
- 06Pre-send recheckConditions revalidated after the calibrated threshold is met.
- AutomaticEligible · automatic sending modeEvery gate passed and the process policy permits sending without review.
- Drafts-onlyBlocked · held for staff reviewA failed gate, the process policy, or the global drafts-only override holds the reply as a draft.
Source: Contract systemSheet v2.10Validated 15 Oct 2026 14:02 Europe/Zurich
04 / Sending modes
Global sending mode and per-process modes
One global sending mode governs every outbound message on the platform. Each process then runs in its own mode underneath it. The global mode always wins: if sending is paused, no process sends, whatever its own mode says.
Global sending mode
Three cells · one active · platform-wide
Outbound guest and prospect messages are prepared as drafts for staff review. Nothing leaves the platform until a staff member approves and sends it.
Sending blocked · staff approval required
Messages are sent automatically only after every hard check passes and the configured confidence threshold is met for that process.
Sending permitted where all checks pass
External sending stops immediately and stays stopped until the mode is deliberately changed. Queued actions are held, not discarded.
Emergency stop · sending suspended
Drafts-only is the global override. It outranks a process set to automatic, and it blocks the release of access details, offers and payment confirmations until a staff member sends them.
Per-process modes
Automatic / review / disabled · set per process
Applies to the named process only. The reply is generated, all hard checks are re-run immediately before sending, and the message is released without staff involvement.
The process prepares the reply and files it for staff review. A staff member edits, approves or rejects it; only an approved draft is sent.
The process produces no outbound message at all. Its internal tasks still run and still appear in the CRM queues, but nothing is drafted for sending.
Internal accounting tasks and arrears alerts operate independently of the global sending mode. Rent obligations, allocation checks and arrears cases continue to be created and surfaced in the CRM while sending is drafts-only or paused.
Business authority is separate from sending permission. Being responsible for a decision does not authorise the system to send it; approval is bound to the exact action details and is invalidated when those details materially change.
A confidence score never grants authority. A high confidence score does not bypass availability, price, payment, permission or approval conditions, and it is not a substitute for deterministic validation.
SOURCE: Contract system · SHEET v2.10 · VALIDATED 15 Oct 2026 14:02 Europe/Zurich
05 / Workflow gates and acceptance
Every gate must pass before a code enters model context or leaves the system.
Four hard gates — identity, payment, contract and time — are enforced by deterministic services. Release criteria, staged deployment, rollback and the model-and-rule update process are stated below as rules with their verification evidence.
- BlockingCritical acceptance violation
- ReviewStaff decision required
- InformationalControl and update rule
- Identity
- Payment
- Contract
- Time
01 — Identity, payment, contract and time gates
Severity: blockingIdentity, payment, contract and time gates must pass before any access code enters model context or is sent.
- No access code enters model context before all four gates pass.
- No access code is sent before all four gates pass.
- A confidence score never grants authority to bypass a gate.
Gate orderIdentity → Payment → Contract → Time
Enforced byDeterministic services
02 — Release criteria: zero critical violations
Severity: blockingRelease requires zero observed critical violations in the agreed acceptance suite.
- Unauthorised access
- Duplicate financial postings
- Incorrect binding prices
- False arrears caused by known stale data
- Internal double commitments
ScopeThis is a release gate, not a guarantee of zero future errors. Fix and rerun failures before activating the affected process.
Acceptance suiteAgreed critical-violation suite
ThresholdZero observed critical violations
03 — Deployment stages 1-6
Severity: reviewStages 1-6 proceed in order; each stage completes before the next begins.
- Integration proof
- Master data and deterministic workflows
- Shadow mode
- Staff-reviewed operation
- Activate approved processes individually
- Monitor and expand
Stage countSix, executed in order
Stage 1Integration proof
Stage 6Monitor and expand
04 — Automatic rollback and global stop control
Severity: reviewA failure returns the affected process to staff review; a global stop halts issuing across every process.
- Affected process returns automatically to review on failure.
- The global stop control halts sending across all processes.
On failureProcess returns to review automatically
OverrideGlobal stop control
05 — Model and rule updates
Severity: informationalA change to any versioned artefact passes a representative regression suite before it reaches production.
- Prompts
- Model configuration
- Extraction schemas
- Templates
- Rules
RegressionRun the representative regression suite before changes reach production; compare results and retain a rollback version. A model upgrade or a second model is not a substitute for deterministic validation.
Versioned artefacts5 tracked items
Before releaseRepresentative regression suite
SOURCE: Contract systemSHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
06 / Access PathsVersion 2.1015 October 2026Pages 22-36
Who gets in, and by which gate.
Six accepted personas reach Pearlstay through defined entry points. Staff authenticate before any record is reachable; guests and prospects enter through WhatsApp, where the message is authenticated and deduplicated before any answer is prepared. Each row carries its coded gutter as well as its text label.
- Blocking · gate must pass before release
- Review · verified or countersigned
- Informational · public entry
01
Accounting / Rent Collection Staff
BlockingViews the public landing page, then proceeds to authenticate as a staff account before any receipt, booking or rent record is reachable.
- EntryPublic landing page
- ConditionProceeds to authenticate
- DestinationCRM workspace
02
Cleaner / Tradesperson
ReviewViews the public entry information before reaching cleaner and tradesperson tools. No existing cleaner or tradesperson account yet, so an account is created first.
- EntryPublic entry information
- ConditionNo existing cleaner / tradesperson account
- DestinationRestricted operational access
03
Existing Tenant / Guest in Stay
BlockingMessages the Pearlstay WhatsApp number instead of using an account. The AI authenticates the sender and deduplicates the message before answering.
- EntryPearlstay WhatsApp number
- ConditionRequest relates to an existing tenancy
- RequestGeneral question, operating problem or complaint, payment question, rent status check, cleaning or maintenance need
- AlternativeTenant calls instead of messaging
04
Pearlstay Staff / Business Decision Owner
ReviewViews the public landing page before authenticating, then proceeds to authenticate. A new staff member registers before first access.
- EntryPublic landing page
- ConditionProceeds to authenticate
- ConditionNew staff member registers
05
Property Acquisition Staff
InformationalViews the public entry page carrying the system diagram and version metadata, then chooses to sign in to the CRM.
- EntryPublic entry page · system diagram and version metadata
- DecisionChoose to sign in to the CRM
06
Prospective Guest (Rental Enquirer)
InformationalLands on the public WhatsApp entry point and initiates WhatsApp or channel contact for an accommodation search.
- EntryPublic WhatsApp entry point
- ActionInitiate WhatsApp / channel contact for accommodation search
SOURCE: Contract system · SHEET v2.10 · VALIDATED 15 Oct 2026 14:02 Europe/Zurich
No comments yet. Be the first!