Object Cards: Giving a Table, a Room, or a Listing Its Own Card

A restaurant we talked to had printed QR codes for every table. Nice codes, properly sized, laminated. Six months later the menu URL had moved, and every one of those thirty codes pointed at a 404. Reprinting meant a design file nobody could find, a print shop, and a Saturday.

That is the problem object cards solve. Not "how do I make a QR code", which is a solved problem and free. The problem is what happens to that code six months later, and who owns it when the person who made it leaves.

What an Object Card Actually Is

An object card is a normal AtlasLinq card that belongs to a thing instead of a person. Table 4 gets a card. Room 212 gets a card. The listing at 14 Oak Street gets a card. Under the hood it is the same profile document as a personal card, with the same fields, the same QR rendering, the same view tracking and the same lead form.

The one difference is ownership, and it is the difference that matters. A personal card belongs to a user account. An object card belongs to the team. No individual owns it, so nothing happens to it when someone changes role or leaves the company. The card for Table 4 is still the card for Table 4 after your floor manager moves on, and the new manager can edit it on their first day without anyone hunting for a login.

Why Not Just Use a Plain QR Code?

For a lot of cases, a plain QR code is genuinely fine. If you need to point people at one URL that will never change, generate a code and print it. You do not need us for that.

Object cards start earning their keep when one of these is true:

• The destination will change. A printed code is permanent; what it points at should not have to be. Edit the card and every code already printed, stuck, or engraved keeps working.
• You want to know if it is working. A plain QR code tells you nothing. An object card records views, saves, and captured contacts, per card.
• There are more than a handful. Thirty tables is thirty codes to generate, track, and eventually replace. That is a spreadsheet nobody maintains.
• Someone should still own it next year. Codes made from a personal account quietly become that person's problem, then nobody's.

Where They Fit

Restaurants and cafés. A card per table, grouped by room or floor. Menu, ordering link, reviews, wifi. When the menu changes on Tuesday you change it once.

Property listings. A card per listing, on the board outside. Photos, the full spec, a booking link, and the agent's contact. Someone walking past at 9pm gets the whole listing instead of a phone number they will not call. When it sells, the card becomes the "sold, here is what else we have" page rather than a dead code.

Hotels. A card per room. Checkout time, wifi, room service, the number for the front desk. Guests stop calling reception to ask what the wifi password is.

Equipment and machines. A card on the machine itself, holding the manual, the service history link, and who to call when it stops. This is the one people underestimate. The information a technician needs is almost never attached to the thing they are standing in front of.

Making Them Without Doing It Thirty Times

Creating cards one at a time is fine for a handful. For a room of tables it is not, so the dashboard can stamp out a whole batch in one go. You define the card once, say how many you need, and each one comes out with its own label and its own QR code.

Two fields are worth filling in properly, because they do more work than they look like they do:

• Title is the object's label. "Table 4", "Room 212", "Excavator 7". It shows on the card and it is how you will find it in a list of eighty.
• Location is a free-text grouping used by analytics. Put "Downtown branch" or "Second floor" here and you can compare performance by location later. Leave it blank and you cannot.

The Number Worth Watching

Object cards report into the same analytics as everything else, so you get views and saves per card, grouped by location. Views are the flattering number and the less useful one. A code on a busy street gets scanned by people who are curious and gone.

Save rate is the honest one. It is the share of people who viewed the card and then kept something: saved the contact, tapped through to book, submitted the lead form. A listing card with 200 views and four saves is decoration. One with 40 views and twelve saves is working. Once you have the same card in two locations, the comparison tells you something real about placement rather than about footfall.

The Limits, Plainly

Object cards are an Enterprise feature. An Enterprise plan includes 3 of them at no extra cost, which is enough to try the idea properly on a few tables or one listing before committing. Beyond that they are a paid add-on, priced per card per month, up to 200 cards self-serve. Past that we would rather talk to you than have you click through a form, because at that scale the placement questions matter more than the billing.

They are managed entirely from the web dashboard. There is nothing to do in the mobile app, and the people scanning them never install anything, which is the same promise as the rest of the product.

Worth Doing?

If you have printed a QR code and later wished you had not, yes. If you have a set of physical things that people walk up to and want information about, probably. If you need one code pointing at one page that will never move, no, and you should just generate one.

The honest test is whether you would want to know how often the thing gets scanned. If that question is interesting to you, the card is worth having. If it is not, a printed code is cheaper.