Know the customer before you reply. Not after you escalate.
Put what the customer bought, is owed and already complained about on the ticket itself, alongside the resolutions an agent is allowed to make.
The systems you already run, the objects your product declares, and the work your team gets back.
These marks name the kinds of system a source declaration reaches — a picture of the ecosystem, not a fixed menu, and nothing here implies a partnership.
Fewer holds. Fewer escalations.
The customer arrives with the ticket
Orders, entitlement and prior complaints arrive as declared links on the case, so nobody opens billing to check.
One refund rule, not folklore
The refund rule in the year-old policy doc becomes a Function that returns the verdict and its records.
Resolutions that leave a record
A goodwill credit crosses an Action, so the ledger says who issued it and on what basis.
What teams build. On day one.
Four places this work turns into declared objects, governed reads, and reviewed changes.
Case context
One Function puts entitlement, open orders, billing state and every prior contact on the case screen, and names the system each came from.
Refund eligibility
Your goodwill rules stop living in a macro and a lead’s head: one Function decides, and shows the order and history it decided on.
Tier-one fixes
A plan downgrade is an Action. Under your threshold an agent runs it; over it, a lead approves the exact effects first.
Escalations that return
An escalation to engineering is a Workflow: it records the promise, waits for the fix, and comes back to tell the customer.
How it runs. End to end.
The same path every product takes: connect what exists, declare what it means, then publish the reads and the changes.
- 01
Connect the helpdesk and the systems around it
Your helpdesk, billing, order and identity systems keep their own writes. Bijection takes a read-only copy of each on a cadence you set, so a case screen shows the last completed capture and names it — not a live tap on the billing database.
- 02
Declare what a case actually involves
Model the ticket, the customer, the entitlement and the order as typed objects with the links between them, once, in reviewed product source.
- 03
Publish the questions and the resolutions
The questions the queue asks a hundred times a day — what is this customer owed, has it shipped, is this refund in policy — become named Functions. The resolutions an agent may make become Actions with declared effects and a review threshold you choose.
- 04
Let agents handle what you have allowed
An agent gets an objective and a declared set of Functions and Actions. It reads what an agent reads and changes what an agent may change, never more than the person who delegated to it.
Common questions.
A macro is text an agent pastes and a knowledge base is a page they have to find, read and interpret. A Function is the rule itself: it answers for this customer and this order, and shows the records it answered from. An Action then performs the resolution rather than describing it. Your helpdesk stays where conversations happen.
Only where you declare it. Sending a reply or issuing a credit is an Action like any other, and you set which ones require review. A parked Action shows the approver the exact effects before anything reaches the customer, and no agent has a write path around that.
Then it may not be in the last pull yet, and the case screen tells the agent which pull it is reading — so they can say how recent the balance is instead of guessing. You choose how often that runs. The real guard is further down: before a credit applies, the Action rechecks the state it planned against and refuses if it moved while the approval was waiting. And a question your product never declared gets refused rather than answered, because a confident wrong answer already sent to a customer is the one thing support cannot take back.
Bring us a process.
We'll build it with you.
A business process, the systems it touches, and the rules it needs to follow.