#R07 — Connecting to what restaurants already have

Scope: incumbent POS APIs, POS middleware, delivery aggregators, Google/Apple surfaces, accounting/payroll/inventory, and the strategic question "CRM first, replace the POS later — or not at all?" Date: 2026-08-18. Labels: [verified] = checked this session with a named URL; [known] = confident from training data; [estimate] = reasoned guess. Where a fact came from a search snippet this session but I did not fetch the page, it is labelled [known] with "(search corroborated 2026-08-18)".

#0. Bottom line up front

Three claims, in order of how much they should change the plan:

1. "CRM riding on the incumbent POS" is a structurally worse business than it looks, and the reason is identity, not integration. You can get checks out of almost any POS. You cannot get a stable guest identifier attached to an in-store card payment out of any POS you do not own the payment rail for. Toast, Square, Clover, Lightspeed and PAR all reserve card-linked identity for their own loyalty product. Without it, your CRM identity coverage caps at roughly 10–25% of checks (online orders + whoever voluntarily scans a code), versus 45–70% if you own the terminal and the payment. That is the difference between "a marketing tool with a coverage problem" and "the restaurant's guest database".

2. Every incumbent POS in this list either already sells a CRM/loyalty product or owns a company that does. Toast Loyalty + Toast Marketing; Square Loyalty + Square Marketing; Oracle Hospitality Gift & Loyalty (iCare); NCR Voyix Aloha Consumer Engagement; PAR owns Punchh; Lightspeed has Advanced Insights + loyalty partners it curates; Olo owns Wisely and owns Omnivore, the neutral POS middleware; iiko/Syrve ships iikoCard; r_keeper ships its own CRM. You would be building the single highest-margin attach product that each platform most wants to keep. This is not "platform risk" in the abstract; it is the specific category where platforms historically defenestrate partners.

3. Aggregator connectors are worth building and POS connectors mostly are not. Glovo/Bolt Food/Wolt/Uber Eats connectors are needed whatever POS wins, are a real operational pain point restaurants will pay for, and are not owned by a competitor. POS connectors are needed only until you replace the POS, cost 2–6 eng-months each, decay at ~0.5 eng-months/year each, and can be revoked. Build read-only migration importers from CEE systems (Poster, iiko/Syrve, r_keeper) instead of live connectors — same lead-gen value, ~1/3 the cost, no partner approval, no maintenance treadmill.

Verdict: land-and-replace, not ride-along. Details and numbers in §9.

#1. What a CRM actually needs from a POS (the capability ladder)

Vendors say "we have an API". That sentence hides a 20× cost difference. Grade every system against this ladder:

Two consequences that decide the strategy:

• T3 nearly always requires code running on the POS terminal or its back-office server, not a cloud API call. Oracle (Extension Applications / SIM scripts), Aloha (a DLL on the BOH file server), iiko/Syrve (a .NET Front plugin), Clover (an Android app on the device). Each is a different runtime, language and deployment channel. A cloud-only CRM team cannot ship T3 without becoming an embedded-software team for each incumbent.
• T2 for in-store cash/card payments is the moat the incumbent will not sell you. Toast, Square and Clover can do card-linked loyalty because they are the processor. Third-party loyalty partners on those platforms get a check and a scan prompt, not a card token. Confirm per-vendor in §2, but assume this default.

#2. Per-system integration reality

#2.1 Summary table

Columns: RT = real-time push of check events; ID = usable guest identifier for in-store card payments; WB = write loyalty discount to an open check pre-tender; Fee = who pays whom; Cert = wall-clock to certified production access; Eng = our build cost for a production connector (read + write where possible), including mapping UI, backfill, retries, reconciliation and a support runbook.

Two entries in that table are unverified and I am flagging them rather than guessing: "Presto" and "SmartTouch". Confirming them costs one afternoon: ask three local restaurateurs which POS they run and email the vendor for API docs. Do that before any of it lands in a roadmap.

#2.2 The systems that actually matter for a UA/PL/CZ/RO beachhead

Ranked by install base × API friendliness × how much CRM value you can extract:

#2.3 Notes that change estimates

• Toast's competitor clause is the single most-quoted risk and it is real but nuanced. Toast certifies loyalty partners (Punchh, Paytronix, Como, Thanx, Spendgo all ship on Toast) [known], so "CRM on Toast" is clearly permitted in practice. The clause bites when your product starts looking like a POS — i.e. exactly the direction this project is going. Building a Toast connector as a wedge for a Toast-replacement POS is the textbook way to get de-certified. [estimate on the outcome, verified on the clause text]
• Oracle's per-call sandbox billing is a real budget line and a real velocity killer. Integration test suites that re-run on every CI push are not viable against a metered sandbox. Budget a local mock + a small number of metered smoke tests. [known, oracle.com partner page corroborated 2026-08-18]
• NCR's reported 30–50% ISV revenue share comes from secondary reporting, not an NCR price list [known, treat as directional]. Even at half that, an Aloha connector is negative-margin for a EUR 49/site CRM. Do not build it.
• Rate limits are a design constraint, not a footnote. Toast is widely reported at 20 req/s per partner [known]. A 500-site chain doing menu sync + historical backfill will hit that in minute one. Every connector needs a token-bucket scheduler, per-tenant fairness, and a backfill queue that yields to live traffic. That is ~0.75 eng-months of shared infrastructure, built once.

#3. What guest data you can actually obtain (the number that decides everything)

Identity coverage = share of checks you can attribute to a known, contactable, deduplicated person.

The arithmetic that matters. A CRM sitting on someone else's POS, with no payment rail, realistically gets: own-channel online (20% of checks × 100%) + loyalty scans (80% of checks × 15%) ≈ 32% of checks — but only ~20 percentage points of that is high-quality — and the loyalty-scan half is only achievable if you have T3 write-back on that POS, which you will have on iiko/Syrve, Poster and Clover and essentially nowhere else without embedded work.

Owning the POS and the payment rail gets you online 20% + card-linked in-store 55% + reservations ≈ 60–75%. That factor-of-three in identity coverage is the entire product difference between a nice-to-have and a system of record.

#4. Middleware: who resells this problem, and are they a wedge or a trap

#4.1 The margin-stack problem, made concrete

Assume a CRM-only product priced at EUR 59/site/mo (defensible for SMB CRM+loyalty in PL/CZ; UA prices lower, EUR 25–40 [estimate]).

A SaaS business at 3–37% gross margin is not a SaaS business. Middleware is acceptable as a market-entry accelerant for a specific deal and as a demo prop; it is not viable as the permanent architecture of a EUR 59 product. The one partial exception is HubRise at 31+ sites (EUR 27), where a chain deal can still clear 50% GM — and HubRise is also the only one whose data model includes customers and loyalty, so it is the one worth a serious look.

#5. Delivery aggregators

#5.1 Capability and onboarding table

Path shapes below are [known] and approximate; every one must be re-confirmed against current docs before estimating precisely.

#5.2 What the 3 eng-months per aggregator actually buys

Menu push is the smallest part. The real work:

#5.3 The CRM truth about aggregators

Aggregators deliberately withhold guest identity. All of them. In all markets. What you get is a first name, a last initial, a relayed/masked phone number that expires, and a delivery address (sometimes truncated). No email, no stable customer ID that survives across orders, and terms that forbid marketing to that guest.

Practical implications:

• Aggregator revenue is CRM-invisible. A restaurant doing 35% of revenue via Glovo has 35% of its business permanently outside its own guest database.
• The only conversion lever is in-parcel: a printed insert or receipt line with a QR to your first-party ordering + a reward. Conversion is real but small — 2–6% of aggregator orders per campaign [estimate] — and it is a legitimate, sellable feature ("win your customers back from Glovo").
• Delivery address + order pattern is still useful for aggregate analytics (delivery zone heatmaps, channel mix, item cannibalization) even without identity. Sell that as analytics, not CRM.
• GDPR: even the masked data you receive is personal data; you are a processor for the restaurant and the aggregator's terms typically restrict onward use. Any "we enrich aggregator orders into your guest list" feature needs legal review before it ships. [known, EU]

Verdict on aggregators: build them. Not for CRM value — for operational value and because they are POS-agnostic and competitor-free. Order: Glovo → Bolt Food → Wolt → Uber Eats, then stop. That is ~11–15 eng-months and covers the beachhead.

#6. Google and Apple surfaces

Do not skip the messaging row. In the UA/PL beachhead, the CRM's delivery channel (Viber/Telegram/WhatsApp) matters more to the customer than which POS you read from. It is also entirely under your control — no partner programme, no certification, no competitor.

#7. Accounting, payroll, inventory — connect what, where

Rule of thumb: in CEE, a correctly-formatted export file beats an API integration. Accountants want a file they can import; they do not want OAuth. A generic export engine (configurable CSV/XML templates per country, per accounting package) costs ~1.5 eng-months once and covers ~80% of demand across all four beachhead countries. Build that before any single API connector.

Priority for S1: export engine (1.5) → RO e-Factura only if you enter RO (2.5) → one scheduling connector (1.0) → nothing else. Inventory partners are a distraction until you have 200+ sites.

#8. Platform risk, with the receipts

"They can cut you off" is not hypothetical in this category. The pattern is consistent: platform onboards partners to fill a gap → partner category proves it has revenue → platform builds or buys it → partner terms tighten, fees appear, or access is revoked.

The structural conclusion: a CRM whose data supply is an incumbent POS API has a supplier with a 100% concentration risk, who is also a competitor, who sets the price, and who has a documented history of raising it. No amount of engineering fixes that.

#9. Strategic verdict, quantified

#9.1 The three paths side by side

#9.2 The maintenance-drag calculation (the number people underestimate)

Per connector per year, steady state:

At 12 live connectors that is 4.2–7.2 eng-months/year — 0.35 to 0.6 of an engineer, permanently, before any new feature. On a 3-engineer S1 team that is 12–20% of total capacity, and it is the least motivating work in the company. This alone argues for the smallest possible connector portfolio.

#9.3 The recommendation

Build the POS. Sell the CRM first. Use read-only importers, not live connectors, as the bridge.

Concretely:

1. Aggregator connectors are the only live third-party integrations worth owning long-term. Glovo, Bolt Food, Wolt, Uber Eats. ~11–15 eng-months. POS-agnostic, competitor-free, real operational pain, sellable on day one even before your POS exists.
2. Replace "POS connector" with "POS migration importer." A one-way, read-only importer for Poster, iiko/Syrve and r_keeper that pulls menu, modifier groups, tax setup, staff, table plan, guest list and 12–24 months of check history. Costs 1.5–2.5 eng-months each versus 3–5 for a live bidirectional connector, needs no partner approval where the API is public, and has zero ongoing maintenance (run it once per customer). It converts the hardest objection in POS sales ("I'll lose my history") into a 30-minute onboarding step. This is the single highest-leverage integration in the document.
3. Ship one live read-only CRM connector as a lead magnet, and only one: Poster. Public API, self-serve OAuth, 2–6 week approval, right customer base. It lets you sell CRM to sites you have not yet converted and gives you a warm list for POS migration. ~1.5–2.5 eng-months. If it does not generate qualified POS pipeline in two quarters, kill it.
4. Build the iiko/Syrve Front plugin only against a signed chain deal. It is the only incumbent where full T3 write-back is architecturally clean, so it is the only one worth the embedded-software cost — but only when someone is paying for it.
5. Do not build: Toast, Aloha, Brink, Revel, TouchBistro, SpotOn, Olo, Micros 3700, Grubhub, Chowly, Cuboh. Wrong geography, wrong economics, or a competitor's home turf. Square and Clover become interesting only on a decision to enter the US, and then in that order (Square first: free, permissive, best identity data via card fingerprint).
6. Build Google Business Profile early. 1.5–2.5 eng-months, free API, no competitor, and review management is a feature SMB restaurants ask for unprompted. It also works identically whether or not you have replaced their POS.
7. Treat middleware as a demo prop, not architecture. HubRise at EUR 27–35/site is the only one with acceptable economics and the only one with a customer/loyalty data model. Use it to say "we already connect to 100+ systems" in a chain RFP; never let it become load-bearing.

#9.4 Build order with ROI

#10. Shared integration infrastructure (build once, amortize over everything)

Do not let each connector invent this. ~5.5 eng-months up front, and it is the difference between 3 eng-months and 6 per connector thereafter.

#Build effort

All figures are engineer-months of a competent senior engineer with heavy AI assistance. Variance drivers listed. Certification wall-clock is not included in eng-months but blocks release.

Recommended S1 v1 scope (bootstrapped): I1–I5 + A1 + A2 + P1 + P2 + P3 + G1 + M1 + M2 + M3 + B1 = 28.5 eng-months. At 3 engineers that is ~9.5 calendar months of integration work alone, running in parallel with the POS build — which is why S1 must cut something. The honest cut list: drop A2 (Bolt Food) and M1 (WhatsApp) from v1 → 23.5 eng-months.

S2 v1 scope (funded): add A3, A4, P4, G2, B3, B5 → +18 eng-months, plus a dedicated 1.5-FTE integrations pod from month 6 to absorb O1.

#Open questions / what would change this answer

1. Does Poster (or Dotypos) publish partner-marketplace revenue-share terms, and are they under 20%? If Poster takes 30%+, the "Poster as lead magnet" play loses most of its economics and should become importer-only. Confirms it: the joinposter developer/partner agreement, one email to their partner team.
2. Is card.fingerprint on Square still stable per-card-per-seller in 2026, and does any EU POS expose an equivalent? If a European POS or PSP exposes a stable network token to third parties, path A (CRM-only) gets meaningfully better — identity coverage could double. Confirms it: Square Cards API docs; Adyen/Nexi/Worldline tokenization terms for ISV access.
3. What is the actual POS install-base split in the UA/PL beachhead? My ranking (Poster > iiko/Syrve > r_keeper > local) is [estimate] from training data. If r_keeper is 3× Poster in the target segment, the importer build order flips. Confirms it: 30 discovery calls, or a data pull from a Ukrainian POS reseller / equipment distributor.
4. Will Toast's competitor clause actually be enforced against a POS-adjacent CRM? It has never, to my knowledge, been litigated publicly. If a US-market decision is ever on the table, this needs a real lawyer reading the current API Documentation License Agreement, not a search snippet. Confirms it: counsel review + conversations with 2–3 existing Toast loyalty partners about their experience.
5. Is HubRise still independent, and what are its partner (not customer) terms? EUR 27–35/site is verified customer pricing; the ISV-side terms are not. HubRise being acquired by a POS or aggregator would change the "wedge" verdict to "trap" overnight — the Omnivore precedent is exactly this. Confirms it: HubRise partner agreement + a look at their cap table/news.
6. What are Glovo's and Bolt Food's actual partner-onboarding requirements in Ukraine specifically — do they require a registered local entity, a minimum number of connected merchants, or an existing POS certification? A minimum-merchant threshold would create a chicken-and-egg problem that reorders the entire build plan. Confirms it: their partner-integration application forms and one call each.

Cross-references: hardware and printing constraints in r01-hardware-peripherals.md; fiscalization gates that make several of these markets pass/fail in r03-fiscal-regulatory.md; offline behaviour and the canonical check model in r04-offline-sync-domain.md.