What Problem Does This Solve?

Most independent and mid-size hotels already run a dynamic pricing engine like Duetto's GameChanger, but the last mile is still manual: someone logs into a dashboard once or twice a day, scans the recommended rate changes, decides what to approve, and updates the channels. That review step doesn't scale past a handful of properties, and it means rate changes lag the market by hours — sometimes a full day, especially over weekends when nobody is watching the dashboard.

The pricing engine itself is doing sophisticated work — ingesting booking pace, competitor rates, local events, and demand forecasts. The bottleneck isn't the analysis; it's getting that analysis in front of the right person, at the right time, in a format they will actually read instead of letting it sit in a tab nobody opens. This guide automates exactly that last mile, using a small n8n workflow that turns Duetto's output into a readable, actionable Slack alert.

A 2024 Lighthouse survey of over 1,200 hospitality professionals found that 63% of companies already use AI in some form for revenue management, and 75% expect AI to have a major impact on their revenue management strategy within five years.

Required Tools

You can run this entire automation layer for under €10/month on top of an existing Duetto contract — the cost driver is the RMS itself, not the automation.

Step-by-Step Implementation Guide

These 12 steps assume you already have an active Duetto GameChanger account. If you don't, start there — n8n can only route and format pricing recommendations that Duetto (or a comparable RMS) already produces; it can't generate them on its own.

Step 1: Confirm Duetto API Access and Obtain Credentials

Duetto does not publish a self-service API key generator in its standard dashboard, and there is no confirmed native n8n connector as of this writing [REQUIERE VERIFICACIÓN]. Contact your Duetto account manager and request API access for the property or properties you want to automate — specifically the rate-recommendations export used by GameChanger.

Ask explicitly which authentication method they support (API key, OAuth2 client credentials, or IP-allowlisted basic auth are the most common patterns for hotel-tech vendors) and request a sandbox or test property if one is available, so you don't build against live production rates on day one.

• Email or call your Duetto account manager to request API/export access
• Confirm the exact authentication method and rate limits
• Request a sandbox property ID for initial testing
• Save credentials in a password manager — never hardcode them in the n8n workflow JSON

Tip: Ask specifically for the rate-recommendation or rate-change export endpoint — some RMS vendors expose booking/reservation data far more easily than pricing-decision data, and you need the latter for this workflow.

Step 2: Set Up Your n8n Instance

You have two options: self-host the free Community Edition on a small VPS (typically €4–7/month on a provider like Hetzner or DigitalOcean), or use n8n Cloud starting at €24/month with a 14-day free trial. For a single-property automation like this one, self-hosting is the more economical choice since the Community Edition has no execution limits.

If self-hosting, the fastest path is the official Docker image — a single docker run command gets you a working instance in under ten minutes. Make sure to set up HTTPS (via a reverse proxy like Caddy or Nginx) before connecting any real credentials, since n8n's webhook URLs and credential storage should never run over plain HTTP in production.

• Choose self-hosted (free) or n8n Cloud (from €24/month)
• Deploy via the official Docker image if self-hosting
• Configure HTTPS via a reverse proxy before adding credentials
• Create your first empty workflow and name it clearly, e.g. ‘Duetto Rate Alerts’

Tip: If you're not comfortable managing a VPS, n8n Cloud's 14-day trial is enough time to fully build and test this workflow before deciding whether the self-hosted savings are worth the maintenance.

Step 3: Add a Schedule Trigger

Open your new workflow and add a Schedule Trigger node as the entry point. This determines how often n8n checks Duetto for new rate recommendations. Every 4 hours is a sensible default for most properties — frequent enough to catch same-day demand shifts, infrequent enough to avoid hitting any API rate limits Duetto may impose.

If Duetto's integration team confirms outbound webhook support for your account, you can replace the Schedule Trigger with a Webhook node instead, which reacts instantly when Duetto generates a new recommendation rather than polling on a fixed interval. Treat this as an optimization to revisit later, not a blocker for your first version.

• Add a Schedule Trigger node
• Set the interval to every 4 hours (adjust based on your property's booking pace)
• Note: ask Duetto whether outbound webhooks are available for your account [REQUIERE VERIFICACIÓN]
• Save the workflow with a descriptive name before continuing

Tip: Start with a longer interval (e.g. every 6 hours) during testing, then tighten it once you trust the workflow — this avoids flooding your test Slack channel while you're still debugging.

Step 4: Configure the HTTP Request Node to Call Duetto's API

Add an HTTP Request node after the trigger. This is the node that actually pulls data from Duetto — since there's no dedicated Duetto node in n8n's library, this generic HTTP Request node does the job using the credentials and endpoint your account manager provided in Step 1.

Set the method (typically GET for a recommendations export), the full endpoint URL, and add your authentication header (commonly `Authorization: Bearer {token}` or a custom API-key header — confirm the exact header name with Duetto, as hotel-tech vendors are inconsistent here). Store the credential using n8n's built-in Credentials manager rather than pasting the key directly into the node, so it's encrypted at rest.

• Add an HTTP Request node connected to the trigger
• Set the method and endpoint URL provided by Duetto
• Create a Credential in n8n's Credentials manager for the API key/token
• Run a single test execution against your sandbox property to confirm a 200 response

Tip: If your first test returns a 401 or 403, double check the exact header name Duetto expects — it's the single most common point of failure in this step, more often than wrong credentials.

Step 5: Parse the JSON Response

Duetto's API response will be a JSON payload listing recommended rates per room type and date. Add a Code node (or Set node, for simpler cases) to extract just the fields you need: room type, date, current rate, recommended rate, and the percentage change between them.

This is also the right place to calculate the percentage-change field yourself if Duetto's response doesn't already include it — a simple `((recommended - current) / current) * 100` expression in the Code node gives you the number you'll filter on in the next step.

• Add a Code node after the HTTP Request node
• Map room_type, date, current_rate, and recommended_rate from the response
• Calculate percent_change if Duetto's response doesn't provide it directly
• Output a clean array of objects, one per rate recommendation

Tip: Log the raw response to n8n's execution log during testing — Duetto's field names aren't publicly documented, so you'll likely need to inspect the actual response structure before your parsing logic is correct.

Step 6: Filter for Significant Changes

Add a Filter node that only lets through rate changes above a threshold you define — 5% is a reasonable starting point for most properties, but adjust based on how often Duetto recommends small adjustments. Without this step, your Slack channel will fill with noise from 1-2% tweaks that nobody needs to review individually.

Consider adding a second condition that always lets through changes above a much higher threshold (e.g. 15%) regardless of any other filtering, since unusually large swings often indicate either a major demand event worth knowing about immediately, or a data error worth catching fast.

• Add a Filter (or IF) node after the Code node
• Set the primary condition: percent_change > 5 (absolute value)
• Optionally add a secondary 'always flag' rule for changes above 15%
• Test with a mix of small and large simulated changes to confirm filtering works as expected

Tip: Most teams set this threshold too low in week one, then get alert fatigue within days and start ignoring the channel entirely. Start at 5% and only lower it if you find you're missing meaningful changes.

Step 7: Group Changes by Room Type and Date Range

A flat list of individual rate changes is hard to scan quickly. Add an aggregation step (using n8n's Aggregate or Summarize node, or a custom Code node) to group the filtered changes by room type, then by date range, so the eventual Slack message reads as a structured summary instead of a wall of individual line items.

For properties with many room types, also consider sorting groups by the size of the change — largest percentage swings first — so the most actionable items appear at the top of the message rather than buried halfway down.

• Add an Aggregate/Summarize node after the Filter node
• Group by room_type, then by date_range
• Sort groups by percent_change descending
• Verify the output structure matches what your Slack formatting step expects

Tip: If you manage multiple properties through one Duetto account, add property name as the top-level grouping key before room type — otherwise a multi-property digest becomes unreadable fast.

Step 8: Format the Digest With Slack Block Kit

Plain text Slack messages get skimmed and ignored. Use Slack's Block Kit format — sections, dividers, and bold field pairs — to turn the grouped data into a digest that's genuinely easy to scan on a phone between meetings. A Code node (or n8n's built-in Slack node, which supports Block Kit JSON directly) builds this structure from your grouped data.

Keep each room-type group to a short header line plus 2-4 bullet-style fields showing date range, current rate, recommended rate, and percent change. Resist the temptation to include every available data point — the goal is a 10-second read, not a full report.

• Build a Block Kit JSON structure: one section block per room-type group
• Use bold text for the room type and a colored indicator for direction (up/down)
• Add a divider block between groups
• Test the rendered message in a private test channel before connecting to production

Tip: Add a small 🟢/🔴 emoji indicator for rate increases vs. decreases — it sounds trivial, but it's the single fastest visual cue for a revenue manager scanning the channel in 5 seconds.

Step 9: Connect the Slack Node and Test Delivery

Add n8n's native Slack node, authenticate it with a Slack app/bot token (created via Slack's API dashboard, with `chat:write` scope at minimum), and point it at a dedicated channel — don't post into a general channel where it will get lost. Run the full workflow end-to-end against your sandbox data and confirm the message renders correctly on both desktop and mobile Slack.

If you plan to add interactive approval buttons later (Step 11), also request the `chat:write.public` and interactivity scopes now, so you don't have to reauthorize the Slack app halfway through building the next feature.

• Create a Slack app and bot token with chat:write scope
• Create a dedicated #revenue-pricing (or similar) channel
• Add the Slack node, authenticate, and target the new channel
• Run an end-to-end test and review the message on both desktop and mobile

Tip: Mute the test channel's notifications while you're debugging — you'll trigger dozens of test executions before the formatting is right, and that's a lot of phone buzzes otherwise.

Step 10: Add a Weekly Summary Workflow

In addition to the real-time alert workflow, duplicate it into a second, separate workflow that runs once a week (e.g. Monday mornings) and aggregates the full week's flagged changes into a single performance-style summary — total changes flagged, average percent change, and which room types saw the most adjustment.

This weekly view is what most general managers and ownership groups actually want to see; the real-time alerts are for the revenue manager making day-to-day decisions, while the weekly summary supports the broader conversation about pricing strategy.

• Duplicate the core workflow as a new, separate weekly workflow
• Change the Schedule Trigger to run once a week
• Adjust the aggregation step to summarize across the full week instead of one pull
• Send the weekly summary to a separate channel or include ownership/GM as members

Tip: Pin the weekly summary message in the channel — it becomes a quick reference point for 'how did pricing perform this month' conversations without digging through real-time alert history.

Step 11: Add Interactive Approval Buttons (Optional)

For teams that want a formal audit trail rather than passive notification, add interactive Slack buttons (Approve / Override) to each grouped message using Slack's Block Kit interactive components. Clicking a button triggers a second n8n webhook that logs the decision — who clicked, when, and which option — to a Google Sheet.

This step adds real complexity (you'll need a public-facing webhook endpoint and Slack's interactivity request verification), so most teams should get the core pull-filter-post workflow running reliably first, then layer this in as a second iteration once the basics are proven.

• Enable Interactivity & Shortcuts in your Slack app settings with a public webhook URL
• Add Approve/Override buttons to each Block Kit message
• Create a second n8n webhook workflow to receive button click payloads
• Log each decision (user, timestamp, choice) to a dedicated Google Sheet

Tip: Verify Slack's request signature on the incoming webhook before processing it — skipping this step leaves your approval endpoint open to anyone who discovers the URL.

Step 12: Add Error Handling and Monitor the Workflow

Add an Error Trigger workflow (n8n's built-in error handling mechanism) that fires whenever any node in your main workflow fails — most commonly the Duetto HTTP Request node, if credentials expire or the API is temporarily unavailable. Route error notifications to a separate #alerts channel so a failed pull doesn't silently mean your revenue manager sees no message at all and assumes nothing changed.

Finally, review n8n's execution log weekly during the first month to catch silent issues — like a filter threshold that's letting through too much or too little — before they become habits nobody questions.

• Create a dedicated Error Trigger workflow in n8n
• Connect it to send failure alerts to a separate #alerts Slack channel
• Include the failed node name and error message in the alert for fast debugging
• Review the execution log weekly for the first month after launch

Tip: Set a calendar reminder to re-check Duetto API credentials 30 days before any token expiration date you were given — expired credentials are the most common silent failure mode for this type of integration.

Real-World Use Cases

Use Case 1: Independent Coastal Resort, 120 Rooms

A 120-room independent resort running Duetto's GameChanger connected it to this exact n8n-Slack workflow, with a 5% significance threshold and a 4-hour pull interval. The revenue manager went from a fixed 45-minute daily dashboard review to scanning a Slack digest in under 5 minutes between meetings, and reported catching same-day demand spikes (driven by a regional event calendar) hours earlier than the previous manual process would have.

Use Case 2: Boutique Hotel Group, 4 Properties

A boutique group running four ~50-room properties on a shared Duetto account adapted the workflow to group alerts by property first, then room type, in a single shared channel. The group's single revenue manager — previously logging into four separate dashboard views daily — consolidated review into one channel, and added the optional approval-button workflow (Step 11) specifically to maintain a clear audit trail across properties for the ownership group's monthly reporting.

Common Mistakes and How to Avoid Them

Setting the significance threshold too low in week one is the single most common mistake — teams want to see everything at first, the channel fills with noise within days, and people start ignoring it entirely. Start at 5% and only adjust after a full week of real data.

Skipping the sandbox/test property step is the second most common mistake. Building directly against live production rates means a parsing bug in Step 5 or 6 can produce a misleading alert that gets acted on before anyone notices the underlying error.

A third frequent issue is posting alerts to a general or already-busy channel instead of a dedicated one. Pricing alerts that compete with day-to-day chatter get scrolled past within minutes, defeating the entire purpose of the automation.

Most critical: never hardcode the Duetto API credential directly into the HTTP Request node. Use n8n's Credentials manager so the key is encrypted at rest and can be rotated without editing the workflow itself.

Expected Results

Comparison based on typical implementations of this workflow:

Next Steps

Once the core pull-filter-post workflow is stable, the natural next steps are: adding the interactive approval workflow (Step 11) if you need a formal audit trail, extending the weekly summary workflow to compare performance against the same week last year, and exploring whether Duetto's broader API surface exposes competitor-rate data you could pipe into the same digest for additional context.

If you manage multiple properties on different RMS platforms, the same pull-filter-format-deliver pattern in n8n applies regardless of which pricing engine sits at the start of the chain — only the HTTP Request node's endpoint and authentication change.

Visit sityos.com for more implementation guides — new guide every week.