Everything operators ask before they trust an automation layer.

No. STR Engine is not a PMS replacement.

PMS platforms still hold reservations, calendars, guest records, and listing-level management. STR Engine is positioned differently. It is deployed around the PMS to automate and structure the operational work that often remains messy even when the PMS is already in place.

A property management company usually takes over a large part of day-to-day operations and charges a management-style fee, often tied to revenue. STR Engine does not do that.

We do not become the operator of record, and we do not take a revenue commission. Instead, we deploy automation around the business you already run so the operation becomes more structured, more responsive, and less dependent on manual repetition.

A VA or co-host usually handles tasks manually. That can still be useful, but it means the operation is still running on labor intensity. STR Engine is built to reduce how much repeatable work needs a person in the first place.

The model is automation-led, human-monitored, not human-led with scattered automation fragments.

STR Engine is built primarily for independent STR operators with roughly 3 to 20 properties.

That range matters because operators in that stage usually feel the pressure of scale most sharply. A 1-property host can often brute-force operations manually. A large management company may already have specialized teams and internal tooling. Operators in the middle are often running serious portfolios without serious operational infrastructure.

Usually not the best fit.

At one or two properties, many operators can still absorb the operational load manually. STR Engine becomes more valuable when coordination, response speed, maintenance tracking, and workflow consistency start breaking down under manual handling.

Yes, but the core positioning is intentionally centered on the independent operator segment.

Larger portfolios can still benefit from the architecture, especially if they want a stronger operational layer without defaulting to a traditional management-company model.

STR Engine is organized around four core automation agents:

• General Guest Inquiry Agent — handles common guest communication, pre-stay questions, and routine message response flows.
• Booking Management Agent — supports booking-related workflows, trigger-based communications, and reservation handoffs.
• Maintenance / Issue Resolution Agent — detects issues, routes them, structures troubleshooting, and supports escalation logic.
• Review Management Agent — manages review request flows, sentiment-related follow-up, and review response support.

This agent is built to reduce the constant burden of repetitive guest communication.

That includes routine questions about check-in, Wi-Fi, parking, house rules, timing, directions, amenities, and stay logistics. It can also route more nuanced questions to the right path instead of leaving everything in a shared inbox waiting for manual attention.

The Booking Management Agent supports the workflow around the reservation lifecycle rather than trying to become the booking platform itself.

That includes reservation-triggered messaging, operational data handoffs, stay-status movement, internal visibility updates, and coordination logic tied to arrivals, departures, and booking events.

It helps detect the issue, categorize it, prioritize it, trigger first-response logic, provide structured troubleshooting where appropriate, update records, and escalate when needed.

That is the difference between "someone saw the message" and "the issue entered a real operational system immediately."

This agent supports the post-stay review process so it is not left to inconsistent manual memory.

That includes review request timing, workflow triggers after checkout, visibility into review status, and structured handling of follow-up paths.

No. STR Engine is designed to work with the operator's existing tools and data, not create unnecessary software sprawl.

The business keeps its PMS, channels, pricing tools, and vendor relationships. STR Engine adds the automation and visibility layer around them.

The portal gives operators a clearer view of what is happening across the portfolio: active issues, booking workflow status, maintenance movement, review-related activity, and other operational signals.

The point is not to give you another dashboard for the sake of it. The point is to make the operating layer easier to read and manage.

The standard rollout target is roughly 5–7 days, depending on property count, current stack complexity, and how quickly needed access and information are provided.

The point is not to drag the client into a long enterprise implementation project. It is to get the operating layer deployed cleanly and responsibly.

Onboarding includes the audit, workflow mapping, stack connection, configuration, testing, and activation needed to turn the client's current operation into a working system.

It is not framed as buying a one-off custom workflow. It is the structured deployment of STR Engine around the client's actual operating model.

No. STR Engine is designed to automate repeatable operational work, but not every situation should run blindly.

The system is built around automation-led, human-monitored execution. Routine work can move fast, while higher-risk, unclear, or escalation-sensitive situations are surfaced into monitored paths instead of being buried.

That is exactly why STR Engine includes monitoring and escalation logic.

Some situations need human review, vendor follow-up, client visibility, or a more careful path. The system is designed to move routine work automatically while surfacing higher-risk or less predictable situations into a monitored environment.

STR Engine uses the current three-tier structure:

• Operator: $399 / month
• Portfolio Pro: $699 / month
• Portfolio Director: $79 / property / month for larger portfolios

This model reflects the idea that growing operators should gain operational leverage without moving into a property-management revenue-share model.

Never. STR Engine does not use a revenue-share model.

That is one of the core economic differences between STR Engine and a property management company. When your revenue grows, you keep the upside.

The current pricing structure is framed around the active service plans themselves, not the older standalone onboarding-fee model shown in the previous FAQ draft.

Portfolio fit and rollout scope are handled through the free audit and plan recommendation process. If a portfolio needs an unusually custom scope, that is evaluated directly rather than forced into an outdated pricing explanation.

No — not in the older sense of "you own the whole workflow system."

STR Engine remains the platform and workflow IP. What clients keep is their own operational data, business records, property information, and the benefit of having a stronger system deployed around their operation.

You keep ownership of your operational data.

That includes your business records, property information, and the information needed to run your operation. STR Engine uses that data to provide the service, support workflows, maintain visibility, and monitor the system, but it does not treat your business data as its own commercial asset.

STR Engine is built to process operational data only as needed to deliver, secure, support, monitor, and improve the service.

That can include onboarding information, portal access, integrations, workflow logs, monitoring events, and client operational data such as reservation or issue-related information. The principle is operational necessity, not broad unnecessary data use.

That is increasingly common, and it does not automatically remove the need for STR Engine.

Many PMS platforms are adding automation and AI capabilities, but their scope is still shaped by the PMS role itself. STR Engine is positioned differently: not as the core reservation system, but as the cross-operational layer built around the operation.

No serious operator should trust a company that guarantees business outcomes like that.

What STR Engine can do is strengthen the operating system behind the business: faster communication, better consistency, cleaner issue routing, fewer missed handoffs, stronger follow-up, and more visibility. Those things can support better outcomes, but they do not replace pricing strategy, listing quality, market conditions, or guest behavior.

The standard service framework uses a 30-day prior written notice rule for ordinary termination.

That creates enough room for an orderly wind-down while keeping the relationship commercially clear. The service can also be suspended or terminated more quickly in cases like nonpayment, misuse, security risk, or unlawful conduct, as described in the Terms.