A macro may not invent a promise.

Support copy is an offer, or it is a quote

A customer asks where the thing is, whether they will be refunded, or whether an exception can be made. The agent—or the macro the agent fires—answers in a complete sentence. The sentence sounds like the company. The warehouse, the ledger, and the payment record have not said that sentence. You now have two promises, and only one of them is operable.

A support macro is useful when it is allowed to quote a promise the system of record already holds, and when every other topic must escalate to a person whose role is allowed to create a promise. It is not useful when the macro library is a drawer of kind phrases.

This note is the TWIMCO Support Promise Authority Matrix. Rows are promise types. For each row you write whether a macro may state it, what must already be true in the system, who may create the promise if it is not there, and which phrases are forbidden even when the agent is trying to be reassuring. There is no live matrix tool. Do not point anyone at a URL for one.

On Paddle8, TWIMCO built a fine-art auction and marketplace, including real-time bidding and a shipping API taken from route knowledge that had lived in spreadsheets. The public lesson is that the winning bid was the start of an obligation, and the platform needed an interface to operational knowledge before fulfillment could be more than a guess. Support language about arrival, handling, or what happens next is the same shape of problem: if the route knowledge is not in the system the macro can read, the macro does not get to invent a date. This is not a claim about Paddle8’s ticket macros or refund practice. Those are not on the public case. The case is the standard that post-sale facts have to be in the product before anyone speaks them as commitments.

If your team is about to paste “we’ll make it right” into a saved reply, start the matrix before the reply is shared.

Six promises, each with an authority

One page. Each promise type gets the same four lines: may state, only if, must escalate to, never say. Leave a line blank rather than smoothing it over in the meeting.

Arrival or ETA. A macro may state an ETA only when a field you named is present—a carrier window, a scheduled handoff, a recorded route—not when the order merely exists. If the field is empty, the macro may say that the timing is not set and escalate. It may not estimate from habit. “Usually ships in a few days” is a promise wearing a shrug.

Refund. A macro may confirm a refund only when the payment record already shows it, including the state your ledger uses for “submitted” versus “settled” if those differ. It may not approve a new refund. Approval belongs to the role on the escalate line. Quoting an amount that is not the amount on the record is a fail even if the sentence is polite.

Exception or waiver. Fee waived, deadline moved, special handling added. Macros do not grant these. They may acknowledge a request and name the role who can decide. If your business truly allows a macro to grant one narrow waiver, write the condition as a field the system already computed, not as agent discretion hiding in a template.

Replacement or reship. The macro may describe a replacement only after a replacement record exists. “We’ll send another” before that record is an offer the stock and the shipping desk have not accepted.

Destination change. Address, pickup, or recipient. The macro may repeat the destination currently on the order. It may not accept a new one unless the product has a path that validates the change and names who approved it. A macro that writes the address because the customer typed it in chat is an authority you did not mean to give a template.

Comfort language. “We’ll make it right,” “this will be resolved today,” “you won’t be charged.” Ban the sentences that create time, money, or outcome promises without a field. You may keep a short human sentence that does not add a commitment: that the case is open, who owns it, and where the customer can see status. If you cannot write that sentence without inventing a date, the status model is the problem, not the prose.

Add a row for any phrase your team already uses that leadership would not want read aloud in a dispute. The matrix is done when every row has an escalate role or an explicit “macro may state, because this field.” A row with neither is a hole.

Bind the sentence to a field

Walk one macro from the library as a timeline before you trust it.

Trigger. Which customer question or tag is allowed to surface this macro. A macro that agents use for everything will be used to promise everything.

Read. The fields it must read first. If any required field is missing, the macro does not get a fallback sentence with a softer promise. It gets the escalate path.

Say. The sentence, with slots filled only from those fields. No slot filled from the agent’s memory or from a default you hid in the template “so it never looks empty.”

Refuse. The phrases the reviewer deleted, written on the matrix so they are not pasted back next quarter.

Record. That the macro was sent, which fields it quoted, and the agent who sent it. A promise you cannot find later is a promise you will argue about from a screenshot.

Review is a role, not a shared folder. Someone owns the library and re-reads it when the underlying fields change—when “delivered” starts to mean “handed to a carrier” instead of “received.” A macro that was honest under the old meaning becomes a false ETA under the new one without anyone editing the words. Put that re-read on the matrix as a duty of the owner.

Agents still need a way to be human. The matrix does not ban apology. It bans apology that smuggles a commitment. Train the difference with two examples from your own tickets, anonymized: one sentence that only named the existing state, and one that created a state the system did not have. If reviewers cannot agree which is which, the row is not ready to ship.

On marketplace work shaped like Paddle8, the moment of sale is visible and the movement afterward depends on operational knowledge. A macro about the bid is not a macro about the crate. Do not let one template cover both because the customer asked a single question that contained both. Split the rows. Escalation is a better answer than a blended sentence that is half true.

Where fulfillment is the actual work, the scoped conversation is fulfillment operations. The matrix is the brief for which sentences the operation is willing to stand behind.

Kind sentences that outrun the ledger

Composites, not Paddle8 ticket data and not measured handle time.

The friendly ETA. No carrier window exists. The macro still offers a range because silence felt rude. The range becomes the customer’s expectation and the team’s argument.

The refund that was sympathy. The agent confirms money is on the way. The payment record shows an open request, or nothing. Finance hears about it from the customer.

The blanket make-right. One macro covers damage, delay, and buyer’s remorse. It promises an outcome. The rows for exception and replacement were never split, so the template grants all of them.

The address typed in chat. The macro updates the destination, or the agent pastes a confirmation of a destination the order does not hold. The shipment leaves for the previous place, or for a place nobody validated.

The stale slot. The template still says “delivered” means “at the door” after the status model changed. The macro is quoting a field and lying about the field’s meaning. Authority without a re-read is how an honest binding rots.

When you see these, do not add a softer adjective. Close the row: either a field, or an escalate role, or a ban. The unreproducible asset is the filled TWIMCO Support Promise Authority Matrix—your promise types, your fields, your escalate roles, and the forbidden sentences you actually removed from the library—plus two anonymized ticket lines showing the difference. A style guide that says “be accurate” does not name the field. Your matrix does.

Use it beside the status model, not instead of a returns policy. A policy can allow a refund the macro is still forbidden to grant. That split is healthy. The policy says what the company may do. The matrix says what a template may say before a person decides. Collapsing them is how a saved reply becomes an unauthorized offer.

If a chatbot or agent is the one firing the macro, the same rows apply. An agent does not get extra authority because it sounds careful. It gets the rows. The public Paddle8 standard remains the one to borrow: know the operational fact before you build a sentence on top of the transaction.

Put this into practice

1. List the macros agents already use for ETA, money, exceptions, replacement, and address changes.
2. For each, fill may state, only if, escalate to, and never say. Blank “only if” means the macro may not state that promise.
3. Delete or rewrite any template that fills a slot from a default or from memory.
4. Name an owner to re-read the library when status meanings change. Record sends with the fields they quoted.
5. If the ledger cannot support the sentence customers keep asking for, fix the record before you fix the prose, and bring that gap to fulfillment operations. Ground the standard in Paddle8: what happens after the sale has to be knowable, not improvised at the moment someone asks.

A kind reply that invents an ETA is not service. It is a promise with no owner.