Two QR codes on one poster: generating branded property collateral from live CRM data
How live CRM data drives on-demand property collateral while keeping QR codes, photo text, and transparent-stock printing correct.
Two QR codes on one poster: generating branded property collateral from live CRM data
A real-estate brokerage wanted its agents to print marketing collateral without opening a design tool. We built a CRM module that turns one property record into a business card, listing posters, and an A4 window poster — rendered from live data, on demand.
The hard part was not the layout. It was the details that only show up on paper: two different QR codes that had to stay different, a title that had to read over any photo, and a footer that vanished when printed on transparent stock.
The problem
Manual production
Agents needed branded collateral for every listing: a business card, just-listed posters, and a window poster for the property itself. Producing those by hand meant a designer in the loop for every price change, every new listing, every agent reassignment.
Data already in CRM
The data already lived in the CRM. Property title, beds, baths, sqft, the sale-or-rent tag, the permit number, the price, and the assigned agent's name, phone, and email — all of it sat on the property and agent records. Retyping it into a design file was slow and error-prone.
Goal
The goal was pixel-close, on-brand output straight from that data, triggered by the agent, with no design step in between.
Why the obvious fix didn't work
The obvious fix is a design template that a non-designer fills in. That still leaves a human copying CRM fields into a form, and it still drifts from the source of truth the moment a price changes.
The other obvious fix is exporting artwork directly from Illustrator or Photoshop. That produces beautiful files, but it cannot read live CRM data, and it cannot run when an agent clicks a button.
So the render had to happen server-side, from the record, on demand. That choice carried a cost we accepted up front: PDF rendering engines do not natively reproduce every design-tool effect. Soft feathered overlays, certain blend modes, and exact kerning do not translate one-to-one. We committed to the closest visual equivalent rather than a perfect match, because live data mattered more than a pixel-identical feather.
What we did
One-click buttons
We added one-click buttons on the property and agent records inside the CRM. Clicking a button opens an in-CRM popup to upload the images the piece needs, then fires an n8n flow.
n8n flow
The flow looks up the record, assembles a payload from the live fields, and hands that payload to a template renderer. Documents — the business card and the A4 window poster — render as PDF through mPDF/TCPDF. The listing and just-listed posters render as JPG. The window poster's photo overlays, which need real browser layout, render through Gotenberg, a Chromium-based renderer.
The window poster focus
The window poster is where the work concentrated, because it carries two QR codes that do two different jobs.
How it works
The pipeline is linear and starts with a click.
- Button. An agent clicks a button on a property or agent record. An in-CRM popup collects the uploaded images for that piece.
- Lookup. n8n receives the trigger and reads the record: property title with beds, type, and location; the sale/rent tag; beds, baths, sqft; permit number; price; and the assigned agent's name, phone, and email.
- Payload assembly. n8n normalizes those fields into a single payload the template expects.
- Template render. The payload flows into the matching template. mPDF/TCPDF renders the business card and A4 window poster PDFs and the poster JPGs; Gotenberg renders the window poster's photo overlays through Chromium.
- QR generation. The window poster gets two QR codes from two different sources.
The two QR sources are the point of the design, so they are worth spelling out.
- Property DLD QR — hero, top-right. This is the property's official DLD QR. It is sourced from the property's own QR attachment and placed in the top-right of the hero image. It identifies the listing.
- Agent vCard QR — contact block. This one is generated dynamically. It encodes the assigned agent's name, phone, email, and organisation as a vCard, so a buyer who scans it saves the agent's contact straight to their phone.
Same poster, two codes, two jobs: one points at the property record, one hands over the agent.
What broke, and what surprised us
QR swap
The client caught the sharpest bug. The contact block was rendering the property's DLD QR instead of the agent vCard QR. Two QR codes on one poster, and the wrong one had landed in the wrong block — so scanning the contact code identified the property instead of saving the agent. We split the sources cleanly so each QR does its own job: DLD QR in the hero, dynamically generated vCard QR in the contact block.
Legibility fix
Legibility surprised us next. The hero title sat on top of an uploaded property photo, and some photos are bright at the top, which washed the title out. Instead of shipping a PNG overlay for every photo, we used a pure-CSS white gradient — linear white fading to transparent — across the top of the hero. It keeps the title readable over any photo, with no image dependency to maintain.
Footer on transparent
Print broke in a way screens never show. The window poster prints on transparent paper, and the footer was effectively invisible on it. On screen it looked fine; on the glass it disappeared. We set the footer colour to solid black and increased the font weight so it holds up on transparent stock.
Render constraint
The honest constraint showed up throughout. Feathered overlays, some blend modes, and exact kerning from the source artwork do not render natively in the PDF engines. We matched the intent with the closest supported equivalent rather than pretending the engine could feather like Photoshop.
Results
The measure that matters is whether an agent can produce correct, on-brand collateral from a record without a designer. After the fixes, they can: the buttons render the full set from live data, and the two QR codes each resolve to the right target.
We would track this by counting collateral generated per agent without design involvement, and by watching for regressions on the three things that bit us — the correct QR in each block, the title legible over a sample of bright and dark photos, and the footer readable on printed transparent stock. Each is a concrete, checkable pass/fail rather than a vibe.
Takeaways
- Render from the source of truth, not a copy. Pulling fields live from the CRM removes the retype step and the drift that comes with it. A price change is reflected the next time the button runs.
- Screen-correct is not print-correct. The footer proved it: solid black and heavier weight only mattered because the stock was transparent. Test on the actual medium.
- Prefer CSS to image dependencies for legibility. A pure-CSS white gradient beat a per-photo PNG overlay — one rule that works over any photo, nothing to maintain.
- Name each artifact's job when two look alike. Two QR codes on one poster invited exactly the mix-up that happened. Keeping the DLD QR and the vCard QR sourced separately made the split obvious and hard to get wrong again.
- Decide the fidelity tradeoff on purpose. PDF engines will not feather like a design tool. We chose live data and the closest visual equivalent, and said so, instead of chasing a pixel-identical effect the renderer cannot produce.
Ready to Implement These Strategies?
Let's discuss how to apply these insights to your specific business challenges.
Schedule Consultation