What a digital business card actually is
A digital business card is a web page that represents a person: their name, job title, company, phone number, email address, and whichever links matter — LinkedIn, a booking page, a portfolio. It is reached by scanning a QR code, tapping an NFC tag, or opening a link, and on any modern phone the recipient can save the whole thing to their contacts in one tap without installing anything.
The property that makes it worth using is that the card and the code are separate things. The QR code points at a short link; the card sits behind it. That means the code printed on a badge in January is still correct in December after a promotion, a phone number change, and a rebrand — because none of those touched the code. A printed card freezes on the day it goes to press, which was never really a paper problem so much as an addressing one.
The second property is measurement. A paper card disappears into a pocket and is never heard from again. A digital card produces scan counts, locations, devices, and times, which is what lets an organisation answer whether a conference, a badge design, or an email signature placement is actually generating contacts.
Individual cards and company card programmes are different products
Almost all confusion when evaluating this category comes from treating two different problems as one, and vendors have little incentive to separate them because both are sold under the same name.
An individual card is a personal tool. One person maintains their own details, chooses their own design, and shares it themselves. Success is a good-looking card and an easy sharing flow, and the market is well served — several platforms do this well, and free tiers are genuinely usable.
A company card programme is an IT and brand governance problem wearing a card costume. Success is that every person in scope has a card, that all of them are on-brand, that the details are correct without anyone maintaining them, and that cards stop working when people leave. None of those are solved by a good card designer, and all of them are solved by connecting the programme to the systems that already know who works there.
The practical consequence: evaluate a company programme on provisioning, deprovisioning, brand locking, and roster maintenance. Evaluate an individual card on design and sharing. A tool that is excellent at one is frequently mediocre at the other, and that is not a flaw so much as a positioning choice.
The four ways card data gets in, and when to use each
How employee data reaches the platform determines almost everything about whether the programme stays accurate. There are four options and they are not interchangeable.
- Employees enter their own. Zero setup, and it fails at scale. Roughly a third of people complete it, and the third who do enter titles inconsistently. Fine for a small team, unworkable as a company programme.
- A one-off CSV or XLSX import. Everyone has a card on day one. Correct until the first hire, promotion, or departure — then progressively wrong, with no owner and no alarm. Genuinely right for fixed populations like a conference delegation.
- Directory sync from an identity provider. Cards are generated from Okta or Microsoft Entra ID and maintained by the joiner-mover-leaver processes that already exist. The correct answer for any ongoing employee programme.
- A programmatic API. For when a system rather than a person owns the roster — an HRIS, a CRM, an internal service. Best where card creation should be part of an existing automated workflow.
Why deprovisioning is the requirement that decides the vendor
When a card rollout gets blocked internally, it is almost never the design or the price. It is a security review asking what happens when someone leaves, and getting an unsatisfying answer.
The reason is worth stating plainly. A digital business card is a public URL carrying a real person's name, job title, employer, direct phone number, and email address. Left live after termination it is a working asset for anyone building a social-engineering pretext — and unlike a dormant Slack account, nobody receives an alert when it is used, and nothing in the normal course of business surfaces it.
"An administrator deletes the card" is not a control. It is a task, and tasks get missed. The requirement is that deactivation in the identity provider automatically suspends or deletes the card, with no human step, and that the current state of any individual's card is directly visible rather than inferred. That is what SCIM provides, and it is why the identity question rather than the design question usually determines which platform an organisation ends up with.
What a rollout actually looks like
A company-wide programme is a short project rather than a purchase, and it goes wrong in predictable places.
- Decide scope before anything else. Usually the customer-facing population — sales, customer success, field engineering, recruiting, partnerships, executives — which is typically ten to thirty percent of headcount. Provisioning everyone inflates cost and makes adoption metrics meaningless.
- Get identity done first. Configure SSO and verify it with a real sign-in before the design work. Doing it first front-loads the review that would otherwise block the launch at the end.
- One template, signed off, locked. The single artefact that makes a thousand cards look like one company. Lock what must not vary.
- Pilot one group, and test a departure. Provision a single department, check cards against the directory, then deactivate a test user and confirm the card goes offline. That last test is the one worth doing before you rely on the control.
- Ship the distribution kit, not just the cards. Email-signature snippet, badge-ready QR image, and a one-line script for what to say. A card nobody knows how to use gets scanned exactly never.