Messages: The Module You Should Sometimes Not Use

One thread per agency, and what follows from that

The structural decision to understand first: a client has one conversation with each agency. Not one per project, not one per topic. Opening Messages finds that conversation or starts it, and from then on it is a single running history.

The upside is that nothing is ever in the wrong place. Anyone who has used a portal with per-project threads knows the failure mode: six conversations, a question that spans two of them, and a client who picks one at random. A single thread cannot be filed incorrectly.

The downside is that the thread has no idea what any message is about. There is no project attached to a message, no deliverable, no invoice. Which is exactly why the topic field exists, and why the routing table below matters more here than in any other module.

Everything in the thread is live. Messages arrive without a refresh, typing is visible, and read state updates as the other side opens it. For a client working with several agencies, each conversation is separate and scoped to that agency — there is no shared channel and no chance of a message reaching the wrong supplier.

Which module for which question

This is the part of the page worth bookmarking. Nearly every request a client sends in a chat window has a better home, and using it costs the client nothing while saving the agency a transcription step.

The pattern behind the table is simple. If the request has a structure — a file to approve, a date to book, a task to add, an asset to store — the module that owns that structure will capture it better than a sentence can. Messages is for the things that genuinely are conversation: disagreement, negotiation, explanation, reassurance, tone.

Agencies get more out of this than clients do, so it is worth teaching explicitly at kick-off. A client who learns in week one that revision feedback goes in Deliverables saves a year of copy-and-paste. The wider habit is covered in how to keep clients updated.

The topic field, and why it earns its click

Above the message box sits a topic selector with five labels plus the option to leave it blank: Project Update, Invoice, Urgent, Deliverables, and General.

Since the thread carries no project or invoice reference, the topic is the only structured signal a message has. In a small agency that is the difference between a billing question landing with whoever does billing and it sitting in a general queue until someone reads all of it.

A word on Urgent. It works exactly as well as it is used sparingly, and it stops working the first week everything is urgent. The honest version: use it when a delay has a consequence you can name, and use Project Update when you would simply like an answer today.

Leaving the topic blank is allowed and is a small missed opportunity. It costs one click.

Four quick starters

On an empty conversation, four one-tap openers appear beneath an invitation to get in touch about a project or an invoice. Each one fills in both the topic and a reasonable opening sentence:

• Asking for the latest update on a current project.
• Asking for help understanding an invoice item.
• Flagging something urgent that needs a quick response.
• Asking for the expected timeline on the next deliverable.

These solve a real problem rather than being decoration. An empty text box with a blinking cursor is one of the most reliable ways to stop someone getting in touch at all, particularly a client who is not sure whether their question is worth asking. Four prefilled openers say, in effect, that these are normal things to ask about.

Note what all four have in common: they are questions, not instructions. That is a fair reflection of what the thread is best at.

Attachments, and the 5MB line

Files can be attached to a message, by picking them or dragging them in, with a limit of 5MB per file. Anything larger is refused at the point of selection rather than failing after an upload.

That ceiling is a design statement as much as a technical one. 5MB comfortably covers a screenshot, a marked-up PDF, a single document — the things that only make sense next to the sentence explaining them. It does not cover a folder of raw photography, and it is not meant to.

The rule of thumb: attach it to a message if the sentence is the point and the file is the evidence. Put it in Files if the file is the point. A brand pack buried forty messages back in a chat thread is effectively lost; the same pack in a folder is still there in a year.

Read state, typing, and availability

Three live signals run in the thread, and together they answer the question that makes clients anxious: has anyone seen this?

• Read state on your messages, so you know the difference between unseen and unanswered.
• A typing indicator when someone on the agency side is composing, which appears while they type and clears shortly after they stop.
• An availability marker on the agency, so you can tell whether silence means they are heads-down or simply not there.

The first of those does the most work. “Seen and not yet answered” is uncomfortable for an agency and enormously reassuring for a client, and it removes the most common cause of a duplicate message being sent an hour later.

The client thread is part of the workspace, not a communications add-on. Arpixa plans run from a free tier with a single client, through Starter at $12 a month with twelve, to Pro at $29 and Advanced at $89 with no client limit. See pricing.

Clearing and deleting

Two housekeeping actions exist. A client can delete an individual message they sent, and can clear the conversation.

Be clear about what these are for. They are tidying, not retraction. A message that has already been read has already been read, and deleting it afterwards does not unsee it. The genuinely useful case is the duplicate, the half-typed line sent by accident, the attachment added to the wrong message.

Clearing the conversation is the heavier of the two and worth pausing over, because a running thread with an agency is also a record of what was agreed informally. That is often the only place a small decision lives.

Six habits that get faster replies

None of this is enforced by the software. All of it changes response times.

1. Set the topic before you type. It is one click and it changes how the message is triaged.
2. Put the ask in the first sentence. Context is useful; context first is not.
3. One subject per message. Three unrelated questions in one paragraph get one answer.
4. Name the thing. "The homepage hero" rather than "the top bit".
5. Say when you need it by, and say why if the date is real.
6. If it belongs in another module, send it there instead. The routing table above is the whole trick.

The second one is the highest-leverage. An agency reading a message on a phone between meetings will act on a first sentence that contains the ask and will defer one that opens with three sentences of background. That deferral is where most of the delay in client communication actually comes from.

Where this sits relative to the agency inbox

Worth stating for anyone comparing portals: this thread is client-facing, and it is not the same surface as the agency’s internal Inbox.

The agency’s internal inbox collects workspace updates, activity, and team coordination, and clients never see it. Internal discussion about a client — scoping, pricing, frustration, strategy — stays there. The client thread carries only what the agency chooses to say to the client.

That separation is not a limitation, it is the point. A single channel shared by internal and external conversation is how an agency accidentally sends a client something they were never meant to read. The broader case is in how to keep internal notes private from clients.

How to send a message that gets answered

1. Open Messages in the portal and pick the agency if you work with more than one.
2. Choose a topic from the dropdown, or tap a quick starter to have both topic and text filled in.
3. Lead with the question or the decision you need, then add context underneath.
4. Attach anything relevant, keeping each file under 5MB, or use Files for large asset sets.
5. Send, and check the read marker rather than resending.

The last step is worth naming as a rule: check the read marker rather than resending. A resent message does not make anyone reply faster and it does make the thread harder to read later.

Frequently asked questions