Macros, playbooks and agent productivity
Your team writes the same sentence forty times a day, and after the sentence it still has to tag the case, assign it, move it to another queue and schedule the follow-up. This page is about cutting that repetition without hiding what a click does.
What this is for
Your team writes the same sentence forty times a day, and after the sentence it still has to tag the case, assign it, move it to another queue and schedule the follow-up. This page is about cutting that repetition without hiding what a click does.
Macros that do more than write
A macro used to do two things: insert a text and set status and priority. Now it can also tag the case, assign it, move it to a queue, leave an internal note, schedule a follow-up and open a guided playbook. Because a macro now touches the case, the composer shows the plan before you apply it: you read what the click will do, and only then click.
- The text lands in the composer with the variables still visible. The server replaces them when the message is sent, exactly as before.
- Nothing is sent to the customer unless the macro says so and you confirm it.
- If one action fails, the ones that already worked stay. The screen names the one that did not.
Macros that are yours, your team's or the company's
A macro now has an owner. A personal macro belongs to whoever wrote it and nobody else sees it, not even an administrator. A team macro appears to the team. A company macro appears to everyone. Sharing goes one way only: you can promote a personal macro to the team or to the company, never pull a company macro back to one person. To retire one, deactivate it.
Guided steps on the case
An administrator writes a playbook for a kind of case: the steps, which of them are required, and an optional hint. On the case, the agent marks each step as done or skips it. Skipping is a legitimate answer and stays written as such, which is the whole point: the difference between "I did it" and "I decided not to" is what makes the panel worth reading.
- Leave the category or the queue blank and the playbook applies everywhere. Fill one in and it applies only to that value.
- The most specific playbook comes first, and a generic company playbook keeps showing below it. They add up, they do not compete.
- A playbook guides. It never refuses a change on the case.
What cannot be missing to close a case
A closing template says which fields this kind of case needs filled in before it can be closed, whether the resolution text is required, and whether an outcome code is required. The case shows what is missing before anyone tries to close it, and the rule applies everywhere a case can be closed: the list, the board, a macro, the API, the terminal.
Without a closing template, nothing extra is required. Turning the page on with an empty list does not block a single case.
Buttons that appear when they should
An administrator can add a button to the case that shows up only when the case is in a certain state and the person looking at it has a certain role. The button points to something that already exists: a macro, a status change, a priority change, or an external link built from the case data.
Files of the case, in one place
Every file of a case in a single list, with where it came from (the conversation, the case itself, a comment, an activity) and a search by name. Nothing is copied: it is the same file, in the same place, finally visible without scrolling the whole thread.
Bulk actions that tell the truth
Select several cases and apply a macro, move them to a queue, tag them, assign them or change status. The result is one line per case: applied, skipped (and why: an approval is pending, or the closing requirements are not met) or failed. The number at the top is the count of that list, so it can never say more than what happened.
Your shift, and the team's
- **My shift** is yours to see: what you resolved, replied and noted today, how much is still with you, how much is past due and how many customers are waiting.
- **By person** compares people, so it stays with whoever manages settings.
- **Per active hour** is resolved cases divided by the clock hours where there is a trace of your work: a message sent, a macro or a quick text applied. We do not track working hours, so a dash means we do not know, and that is not the same as zero.
Keyboard shortcuts
Each person picks their own keys, in Settings. The list of actions is ours, so a shortcut never adds new behaviour to a screen; it reassigns a key. Two actions cannot share a key in the same area, and the screen says so instead of letting the last one win.
The acknowledgement email your customer gets
When an email opens a case, the customer gets an acknowledgement with the protocol number. Three things decide what it says, in this order:
- **An auto-reply rule that matches.** You wrote the condition (a channel, a keyword, outside business hours), so your text wins.
- **A case email template for "case created".** This is the general acknowledgement, and it can now be written per language, per category and per queue. The language is the one your customer wrote in: we read what they declared in their record first, and fall back to what the text itself shows.
- **The single acknowledgement text** in the service settings, which is what always worked.
Two behaviours stay exactly as they were, on purpose. If the acknowledgement is turned off, nothing goes out, and adding a template does not turn it back on. If you have auto-reply rules and none of them matches, the reply stays silent, because that silence is the condition you wrote.
When the phone rings
If your company has voice set up and you are available for calls, an incoming call shows a small card in the corner of the console with who is calling. One click opens their case.
- One open case: the card opens it.
- More than one: the card lists them and you pick. We would rather ask than start the wrong conversation.
- No open case, but the number is in the CRM: the card opens the record.
- Unknown number: the card says so, and you keep the number in front of you.
The card never changes your screen by itself, and you only see it once per call. The console asks the server every few seconds, so the card can take a moment to appear.
Calling from the case
When your company has voice set up and the case has a phone number, the case shows a Call button. Your phone rings first; when you answer, the customer is dialled. The call is attached to the case from the first second, so it shows up in the case history without anyone linking it by hand.
Transferring, listening in and whispering are not here, and that is deliberate: no voice provider we support announces those capabilities, and a button with nothing behind it is worse than no button.
Running a flow on the case
The case can start a flow (a follow-up sequence, an automation) without leaving the console. Only flows built for cases and turned on appear in the list. Running the same flow twice does not enrol the case twice, and the panel keeps the history of what was run, by whom.
Filling fields by rule
If your company wrote field rules for cases, the case shows what those rules would fill in, from and to, before anything is written. You click to apply. Nothing is written just because you opened the case.
Rules that add up children (a sum, a count) are not previewed here: they change when the child changes, not when you open the parent, and they keep running in the scheduled pass.