Cards

Configure the AI-generated cards shown on each customer — what they analyse, how they render, and what extra context they can draw on.

Cards are short AI-generated summaries shown on every customer: each card runs its own prompt against the customer's recent conversations and renders the result on the customer's detail page, and optionally as a column in the customers overview. Salfio ships with a default set (briefing, wins, risks, topics); you can edit those, reorder them, or add your own.

Cards belong to your organization: one configuration drives the card for every customer, and content regenerates automatically as new conversations arrive.

Open Settings → Cards. Each card has:

• Title — the card's name as shown on the customer page.
• Prompt — what the card should produce, run against the customer's recent conversations. The prompt also sees the customer's labels, so it can condition on them.
• Card format — structured insight blocks, or freeform markdown shaped entirely by your prompt.
• Column prompt — how to render the card's result as a short column in the customers overview (format only; the prompt above owns content). Two Defaults are offered — one that condenses the card to a single line, one that turns it into short pill labels. Picking one fills the field, and you can edit the text before saving.
• Display toggles — whether the card shows on the customer detail page and/or as an overview column.

Editing content fields regenerates the card for every customer on the next background pass. Reordering cards is free — it never regenerates anything.

By default a card sees only the customer's recent conversations and labels. Two opt-in toggles under Sources → Context feed it more background:

• Customer context — the customer's overview (business profile, open commitments, relationship sentiment), their services in use, and their name, domain, type, and revenue.
• Organization context — your company profile and services catalog, including each service's buying signals and requirements. Services the customer already uses (per their services list) are left out, so the card only ever sees what's left to sell to this customer.

The content arrives as clearly delimited sections named Customer context and Organization context, so your prompt can reference them directly. This is what makes analysis-style cards possible — for example an Upsell opportunities card:

Compare the services in the Organization context section against the customer's current services and the needs expressed in the conversations. Suggest at most two services the customer does not yet use. Only suggest a service when its buying signals match a need the customer actually expressed and its requirements hold for this customer — cite the matching signals in the customer's own words. If no service clearly fits, answer "No clear upsell" instead of suggesting the closest one.

A wrong suggestion is worse than none, so tell the card when to abstain — it will. Matching leans on two of the catalog's guidance fields: buying signals qualify a service (the need the customer voiced matches what interest looks like) and requirements rule it out (something that must be true isn't). Both always travel with the catalog into the card's context, even when a very large catalog is compressed to fit. Services listed as in use on the customer's overview never enter the catalog a card sees, so an already-purchased service can't be recommended again — even when recent conversations show fresh demand for it, the card picks from the remaining services or abstains. For an extra quality gate, end the prompt with: "Before answering, check each suggestion: would a skeptical account manager agree this is a real, well-matched opportunity? Drop any that fail."

Customer context includes the customer's open commitments with their state, and spells out how to use them: a commitment marked open — an explicit ask or agreed next step that was never delivered — is the highest-precision opportunity there is, so an upsell-style card surfaces it first. Commitments marked done were already delivered, and the card is told never to recommend doing them again — so an AM who already sent the follow-up doesn't see it re-suggested.

Cards with a context toggle enabled stay up to date on their own: editing a service in the catalog, or a refresh of a customer's overview, regenerates exactly the cards that opted in. Cards without the toggles are unaffected — enabling context on one card never changes the cost or output of the others.

A card can also be pointed at a tool connected under Agent Tools — a CRM board, a document store — so it can use knowledge that never appears in a conversation.

Open a card, and under Sources → Tools tick the tools it may read. Only tools made available to the organization are listed: cards run for every client with no user of their own, so a personal tool must first be shared by its owner under Agent Tools. Ticking a tool takes effect immediately — unlike the rest of the editor, it does not wait for Save. Nothing is enabled by default: a card with no tools ticked generates exactly as it did before, and enabling a tool on one card never affects another.

A card reads at most a few times per generation — enough to check a board or open a document, not to enumerate a workspace. If a tool is unreachable when the card runs, the card is still written from the conversation history alone; you get an ungrounded card, never a missing one.

Cards that read a tool also refresh on a timer, not only when the conversation changes. A board can move without anyone emailing about it, so waiting for new activity would leave the card quoting whatever the board said the day it was written.

Open a card and you'll see a Grounded on panel listing every tool that answered, how many reads each one contributed, and how much of the tool budget the generation spent. If a tool was reachable but a read failed, that's shown too, so a partial answer is never presented as a complete one.

Cards generated from conversations alone have no panel at all: it appears only when a tool was actually read. The counts come from the run itself, not from the card's own description of its sources, so the panel can be trusted even where the card text cannot.

Enabling a tool widens who sees its data

An organization tool is authorized by one person and shared with everyone. Putting it behind a card means the card will read that tool through that person's access, and the result is rendered for every customer the card runs on — including for colleagues who could not open that tool themselves. Each row in the picker names whose authorization it is, and the first time you put a given tool behind any card, Salfio asks you to confirm.

Withdraw access at any time by unticking it. Disconnecting the tool under Agent Tools — or making it personal again — also removes it from every card, so restoring it later never silently brings card access back.

The card editor keeps a Preview panel beside the form: pick a customer and dry-run the current draft — prompt, format, and context toggles — without saving or regenerating anything. Because it sits next to the prompt rather than below it, you can edit and re-run without losing sight of either. Use it to iterate on context-hungry prompts until the output looks right, then save.

Preview is available when creating a card too, so a new card can be tried against a real customer before it is generated for everyone. On a narrow screen the panel becomes a Preview & history tab.

Every card on a customer's page has a Report an issue action, in both the card itself and its expanded view. Use it when a card gets something wrong: pick what kind of problem it is — wrong facts, an unsupported conclusion, wrong language or format, or something else — and optionally say more in your own words.

The report goes to the Salfio team and is used to improve card quality. It does not change the card: reporting never hides a card, never triggers a regeneration, and is not visible to your colleagues. If a card is wrong because its prompt is wrong, fix the prompt in Settings → Cards — that is what actually changes the output.

Reporting the same card more than once is fine. Repeat reports tell us a problem is persistent rather than a one-off, which is exactly the signal worth having.

If you render Salfio cards inside your own product, you can forward the same reports programmatically — see Forward card feedback from your own product for the two-call walkthrough, or Report an issue with a card for the endpoint reference.