pearsley
Meghna Rajawatbuild this
Comments (0)
Sign in to leave a comment
Global sending mode set to Drafts-only.
02 / IntegrationsCapability matrix
Integration capability matrix
Every operation in the mandatory technical milestone, with its verified state: supported, tested, limited or unavailable. Each row carries the approved substitute or manual fallback, the operational impact and the cost note, so integration scope can be frozen on evidence rather than assumption.
- UNAVAILABLE— Blocking — no verified operation
- LIMITED— Review — requires staff handling
- INFORMATIONAL— No gate — recorded for traceability
| Integration area | Capability | Status | Fallback | Operational impact | Cost note |
|---|---|---|---|---|---|
| Beds24 API V2 — channel management | |||||
| Read / write access | Live read and write against Beds24 API V2 on the mapped unit set | TESTEDINFORMATIONAL | No substitute approved; operations wait for the connection | Availability and rate changes cannot reach the channel until access is confirmed | Included |
| Unit mapping | Stable unit identity mapped between Beds24, the CRM and the contract system | TESTEDINFORMATIONAL | Manual reconciliation against the exported unit list | Mapping is the precondition for every other Beds24 operation | Included |
| Booking and block creation | Create a booking or a direct contract block on a mapped unit | TESTEDINFORMATIONAL | Manual entry in Beds24, recorded against the CRM case | Direct-contract commitments depend on the block being written and read back | Included |
| Booking and block amendment | Amend dates, occupancy and amounts on an existing booking or block | TESTEDINFORMATIONAL | Manual amendment in Beds24 with the change logged in the CRM | Extensions, early arrivals and occupancy changes follow the amendment path | Included |
| Open-ended block extension | Extend an open-ended block beyond the current horizon | LIMITEDREVIEW | Staff-triggered extension, recorded in the CRM with the Beds24 reference | Open-ended tenancies stay protected; extension is not unattended | Included |
| Termination updates | Remove only the superseded block after a human approves a termination | LIMITEDREVIEW | Manual removal after written approval, with evidence retained | Never automatic; a signed contract is never silently cancelled | Included |
| Channel connections | Portals and channels connected to the Beds24 listing set | LIMITEDREVIEW | Per-channel confirmation read back in Beds24 before propagation is relied on | Channel propagation is asserted per connection, not assumed for the portfolio | Per connection |
| PriceLabs rates | PriceLabs writes the channel rate for the mapped date ranges | LIMITEDREVIEW | Rate set manually in the channel for the affected dates | PriceLabs and CRM rules must never compete to write the same rate | Subscription |
| Duplicate and timeout handling | Reconcile a repeated or timed-out write against the external record before retrying | TESTEDINFORMATIONAL | Reconciliation against Beds24 before any retry is issued | Underlies the no-duplicate-financial-postings acceptance gate | Included |
| Cleaning-notice ownership | Exactly one sender owns cleaning notices across CRM and Beds24 | UNAVAILABLEBLOCKING | CRM owns the notice; Beds24 must not also send it | Duplicated notices mislead cleaners and are treated as an exception | No change |
| Automatic calendar maintenance | Unattended repair of divergent calendars across CRM, Beds24 and the channels | UNAVAILABLEBLOCKING | Exception raised and staff notified; never recorded as silent completion | Unsupported operations are surfaced, not closed without evidence | No change |
| Unsupported operations | Operations confirmed as outside the Beds24 API V2 capability set | UNAVAILABLEBLOCKING | Recorded as exceptions with the manual step kept in place | Migration effort and manual steps are planned, not assumed away | Manual effort |
| Retry and failure path | Failed operations enter review rather than being retried blindly | TESTEDINFORMATIONAL | Approved changes and failed operations enter the CRM review queue | Failures remain visible with the proposed next step and an owner | Included |
| AbaNinja and bank evidence — accounting | |||||
| Original receipt capture | PDF, JPG and PNG receipts and invoices captured from CRM upload and the intake mailbox | TESTEDINFORMATIONAL | Manual upload into the CRM with the original preserved | Originals are retained and linked to the booking record | Included |
| Document extraction | Extraction of supplier, invoice number, date and amount without contradiction | LIMITEDREVIEW | Staff key the fields from the original document into the review queue | Uncertain or incomplete documents route to review rather than blind booking | Per document |
| Validation | File checksum plus supplier, invoice-number, date and amount checked before use | TESTEDINFORMATIONAL | Manual duplicate check against the supplier record | Duplicates are caught across upload, email and retry paths | Included |
| Posting to AbaNinja | A checked document booked with account, tax code and property or cost allocation | LIMITEDREVIEW | Staff post the entry in AbaNinja and the link is recorded in the CRM | Posting an expense stays separate from authorising any outgoing payment | Included |
| Acknowledged booking status | Final status taken only from an acknowledged AbaNinja operation | UNAVAILABLEBLOCKING | Status stays pending until the acknowledgement is returned | No booking is reported as complete from a local state change alone | No change |
| Stable bank transaction IDs | Transaction identity that survives refresh cycles and re-imports | LIMITEDREVIEW | Transactions matched on amount, date and reference until IDs are confirmed | Allocation and reversal depend on a transaction remaining identifiable | Included |
| Refresh coverage | Scheduled refresh of booked incoming payments from the bank feed | LIMITEDREVIEW | Manual statement import into the reconciliation queue | Reconciliation freshness and coverage limits apply to every feeder | Provider fee |
| Booked-versus-pending distinction | Booked and pending bank transactions kept visibly apart | TESTEDINFORMATIONAL | Pending amounts excluded from confirmed receipt status | Prevents a payment being treated as received before it is booked | Included |
| Allocation | Receipts allocated against the rent obligation for the correct contract and period | TESTEDINFORMATIONAL | Staff allocate the receipt and record the reason | Rent, deposit, cleaning fees and other charges stay separate | Included |
| Reversals | Reversal through the supported process, with correction history preserved | LIMITEDREVIEW | Reversal arranged with the accounting owner; history retained | A posted entry is never deleted to make a reconciliation agree | Included |
| Stale-feed detection | A feed that has stopped updating is detected and surfaced | TESTEDINFORMATIONAL | Staff confirm the feed state before reminders rely on it | Prevents false arrears caused by known stale data | Included |
| OCR licensing | Document extraction must run on a licensed route | UNAVAILABLEBLOCKING | Manual keying remains available if the licence is not confirmed | Extraction is not activated on an unlicensed path | Licence required |
| Outgoing payment execution | Automatic execution of outgoing bank payments | UNAVAILABLEBLOCKING | Payment remains a human, external step; settings cannot silently enable it | Deliberately excluded from the delivered scope | Not applicable |
| WhatsApp and notification reliability — messaging | |||||
| Inbound authentication | Incoming messages authenticated before any handling | TESTEDINFORMATIONAL | Unmatched senders are not treated as guests | Protected information is only reachable after matching | Included |
| Deduplication | Messages deduplicated by message ID | TESTEDINFORMATIONAL | Repeated webhook deliveries discarded rather than re-answered | Prevents duplicate replies and duplicate internal work | Included |
| Media intake | Images and documents received on the channel and attached to the case | LIMITEDREVIEW | Staff request the document by email and attach it in the CRM | Evidence capture depends on the intake path being available | Provider fee |
| Approved proactive templates | Only templates approved for the account may open a conversation | LIMITEDREVIEW | Staff send from the recorded mailbox where a template is not approved | Template approval gates every proactive message | Per message |
| Delivery and failure status | Delivery and failure state recorded per outbound message | TESTEDINFORMATIONAL | Undelivered items remain visible in the queue for staff action | An uncertain send is reconciled before it is ever retried | Included |
| Opt-out handling | An opt-out is honoured and stops further proactive contact | TESTEDINFORMATIONAL | Contact-stop recorded against the identity and respected by follow-ups | Follow-up rules stop at the opt-out before anything is sent | Included |
| Device and user mapping | Internal push routed to the correct device and staff user | LIMITEDREVIEW | Internal alerts fall back to the in-app queue and email | Urgent escalation depends on a mapped recipient rather than a broadcast | Included |
| Acknowledgement | Recipient acknowledgement recorded for urgent internal alerts | LIMITEDREVIEW | Unacknowledged urgent alerts repeat under the agreed rule | Urgency stays attributable to a named owner | Included |
| Urgent repeat rule | An unacknowledged urgent alert repeats; normal tasks and drafts never do | LIMITEDREVIEW | Staff confirm the urgent item manually in the queue | Draft and normal-task volume stays out of the push channel | Included |
| Reply matching | A reply is matched back to the correct thread and identity | TESTEDINFORMATIONAL | Unmatched replies surface as an exception for staff association | Prevents a single enquiry being handled by two parallel workflows | Included |
| Contact via the clickable handover link | WhatsApp conversation opened from a prefilled opaque enquiry reference | LIMITEDREVIEW | Email and portal contact remain available while the handover asset is unconfirmed | Channel use waits on confirmation of permitted use of the handover asset | No change |
SOURCE: Integration proofSHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
Integrations · Proof gates
Prove the integration before the full build
Pearlstay-authorised integration capabilities must be demonstrated in a sandbox or an isolated test workflow before committing to full implementation. No live guest obligations are created and no real reminders are sent. Integration scope is frozen only after this milestone is satisfied.
Beds24 — channel and unit lifecycle
8 gates
Correct unit mapping
GATEProvider key mapped to the CRMW unit identity with no orphan or duplicated units.
Integration engineering
Blocking. No target-state cutover while any unit is unmapped or mis-mapped.
Current availability
GATEAvailability readback matching the authoritative contract position at the moment of the check.
Integration engineering
Blocking. No booking decision may rely on this source alone until readback agrees.
Booking and block creation
GATECreated booking and block records with stable provider identifiers recorded against the unit.
Integration engineering
Blocking. Creation remains a manual step until creation is proven on the test unit.
Booking and block amendment
GATEA dated amendment trace showing the changed dates, the change reason and the resulting state.
Integration engineering
Blocking. Amendments stay under human handling until the trace is complete.
Open-ended block extension
GATEReadback confirming the open-ended block remains extended after the operation.
Integration engineering
Blocking. An unverified extension returns the unit to manual calendar maintenance.
Termination updates
GATEOnly the superseded item removed, with the removal recorded in the audit trail.
Integration engineering
Blocking. Removal acts only after the human termination approval and never before it.
Duplicate and timeout handling
GATEA repeated request and a timed-out request reconciled against the external record before any retry.
Integration engineering
Blocking. An unproven retry path keeps the affected operation in review.
Channel propagation
GATEA channel change observed end to end with the resulting channel value captured as evidence.
Integration engineering
Blocking. Inventory-channel writes stay paused while propagation is unproven.
Cleaning notice and unsupported operations
2 gates
Cleaning-notice ownership
GATEOne named owner for the cleaning notice, with the notice traceable to its source record.
Operations ownership
Blocking. Turnover scheduling keeps a named human owner until ownership is proven.
Unsupported operations
UNPROVENEach unsupported operation enumerated with its approved substitute or documented manual fallback.
Operations ownership
Blocking. Unsupported automatic calendar maintenance is recorded as an exception, never as silent completion.
AbaNinja and bank evidence
6 gates
Original receipt capture
GATEThe original document retained and linked to its AbaNinja record, unaltered.
Accounting operations
Blocking. Documents without a retained original are not booked.
Extraction
GATEExtracted fields compared against the source document at field level.
Accounting operations
Blocking. Automated document booking stays off while field-level agreement is unproven.
Validation
GATEDuplicate detection by file checksum and by supplier, invoice number, date and amount.
Accounting operations
Blocking. A failed or timed-out booking request is reconciled against the external record before retry.
Posting
GATEProposed account, tax code and property or cost allocation carried into the acknowledgeable booking request.
Accounting operations
Blocking. Posting an expense stays separate from authorising any outgoing payment.
Acknowledged booking status
GATEFinal status taken only from an acknowledged operation returned by the accounting system.
Accounting operations
Blocking. No success state is shown before the external system acknowledges it.
Bank transaction integrity
UNPROVENStable identifiers, refresh coverage, booked-versus-pending distinction, allocation and reversals on the actual account.
Accounting operations
Blocking. A stale feed raises an exception, blocks the affected allocation and notifies staff.
WhatsApp and notification reliability
10 gates
Inbound authentication
GATEAuthenticated inbound events on the actual account with the source recorded.
Messaging operations
Blocking. Unauthenticated inbound events are discarded, never answered.
Deduplication
GATEDuplicate webhook events collapsed by message identifier, with the duplicate count recorded.
Messaging operations
Blocking. A duplicated event never produces a second send.
Media intake
GATEInbound media preserved and linked to the conversation record.
Messaging operations
Blocking. Media that cannot be preserved routes to review instead of being dropped.
Approved proactive templates
GATEApproved template references in use for template-initiated contact, with documented consent.
Messaging operations
Blocking. Template-initiated contact stays disabled without the approved references.
Delivery and failure status
GATEDelivery and failure states reconciled per send before any retry is offered.
Messaging operations
Blocking. An uncertain send is reconciled; it is never retried on a timer alone.
Opt-out handling
GATEOpt-out recorded against the contact and honoured on every later send.
Messaging operations
Blocking. An opted-out contact receives no proactive message of any kind.
Device and user mapping
GATEInternal push mapped to named devices and users on the actual account.
Messaging operations
Blocking. An unmapped recipient falls back to the dashboard task, not to silence.
Acknowledgement
GATEAcknowledgement captured and recorded against the originating alert.
Messaging operations
Blocking. An unacknowledged urgent alert escalates again.
Urgent repeat rule
GATEThe repeat applies to the urgent class only, and normal tasks and drafts raise no individual push.
Messaging operations
Blocking. The repeat stays limited to the urgent class while it is unproven.
Reply matching
GATEA reply matched back to its originating conversation record.
Messaging operations
Blocking. An unmatched reply becomes a review item for staff.
Scope freeze
Integration scope is frozen only after this milestone is satisfied.
Exception rule
Unsupported automatic calendar maintenance is treated as an explicit exception with an approved substitute or manual fallback — never as silent completion.
Conflict rule
An unresolved conflict blocks the action and notifies staff. A signed contract is never silently cancelled.
SOURCE: Integration proofSHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
04 / Provider adapters
Provider adapters and migration boundaries
How each integration is built, which system owns which write, and what stays outside the scope. Every boundary below is a rule, not a preference.
Adapter boundaries
05 boundariesBeds24 adapter
In scope — build targetConstraintThe production CRM adapter is built directly for Beds24, not as a full Lodgify integration that is later rebuilt. A replaceable integration module separates business rules from the provider adapter: operations are expressed provider-neutral and the provider-specific wiring lives in provider-keyed mappings.
ConsequenceLodgify remains live until a verified cutover. Only the Beds24 production adapter is in scope; no parallel Lodgify production adapter is maintained.
SOURCE: IntegrationsBeds24 adapter boundarySHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
Beds24 migration safeguards
Informational — prerequisiteConstraintExisting data is exported and reconciled before the switch. Original channel booking IDs and source ownership are preserved through migration, so a booking keeps the identity and origin it arrived with.
ConsequencePriceLabs mappings and discounts are confirmed, not assumed. One single sender owns guest messages and cleaning notices across CRM and Beds24.
SOURCE: IntegrationsMigration safeguardsSHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
PriceLabs
Stop — no competing writerConstraintPriceLabs and CRM rules must never compete to write the same channel rate. Two writers on one rate is a direct conflict, so the boundary fixes which system owns that write.
ConsequenceA market-data-based revenue-management engine is not included in this delivery. No new pricing rules are introduced that would write against the PriceLabs rate.
SOURCE: IntegrationsPriceLabs boundarySHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
E-signature provider
In scope — provider to be approvedConstraintA qualified electronic signature platform satisfying Swiss ZertES requirements is selected on lowest total cost that meets the Swiss signature, integration, reliability and usability requirements. DeepSign, Swisscom Sign and SwissSign are the initial candidates.
ConsequenceExisting individual signature and countersignature approval rules are preserved — no new signing authority is granted by this integration.
SOURCE: IntegrationsE-signature boundarySHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
Accounting
Boundary — excluded scopeConstraintAbaNinja remains the accounting system behind the CRM interface. Specialist accounting configuration and closing may remain in AbaNinja; the CRM presents the operational view over it.
ConsequenceClosing, payroll, tax filings and outgoing-payment execution are not added by this integration.
SOURCE: IntegrationsAccounting boundarySHEET v2.10VALIDATED 15 Oct 2026 14:02 Europe/Zurich
Source: Integration proofSHEET v2.10VALIDATED 15 Oct 2026 14:02Europe/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
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!