Skip to content
Agency Pilot

Feature

Every client conversation, filed against the client

The answer to "what did we tell them about that?" should take four seconds, not an archaeology expedition through somebody's personal inbox.

Start free trial See pricing

Channels in one timeline

Texts and calls — inbound and outbound — land in a conversation filed against the client whose number they came from, alongside emails you send from your own mailbox.

Clients can reach you from the app

A client logged into their portal can start a conversation with you directly. It lands in your queue with the client, project and priority already attached.

SMS and calls on your own number

Connect your own Twilio or GoHighLevel account. Messages send from your number, and inbound texts and calls come back into the same thread.

Your real mailbox

Connect an existing mailbox over IMAP and SMTP. It is your email, not a separate address the client has to learn.

Assignment and status

Threads have an owner, a status and a priority, so a conversation cannot quietly become nobody's problem.

Credentials stay yours

Provider credentials are stored encrypted per agency. There is no shared platform account sending on everybody's behalf.

The problem is not volume, it is scatter

Most agencies do not have too many client messages. They have the right number of messages spread across a personal inbox, two people's phones, a Slack channel, a shared mailbox nobody reads and a project tool with a comments feature.

The cost shows up in three places: onboarding a new account manager takes weeks because the history lives in other people's heads, something gets dropped whenever someone is on holiday, and every client dispute becomes a matter of opinion because nobody can produce the thread.

Putting the conversation on the client record fixes all three at once, and it is the least glamorous feature in the product.

Letting the client start the conversation

A client in their portal can open a conversation with you without leaving the app. They pick what it is about — optionally attaching it to a specific project — set how urgent it is, and write.

On your side it arrives as a thread with the client, the project and the priority already set, which is more context than an email saying "quick question" has ever contained. Replies go back and forth in the portal, and the client can see the status of what they asked rather than wondering whether it was received.

The point is not that clients cannot email you. It is that when they use the portal, the message arrives already filed.

  • Client picks the category, priority and related project
  • Threaded replies both ways, visible to the client in their portal
  • Status is visible to the client, so "did you get this?" stops happening
  • Your team sees it beside everything else that client has ever sent

Bringing your own numbers and mailboxes

SMS and calls run through your own Twilio or GoHighLevel account rather than a number we rent to you. You connect your credentials, they are encrypted, and messages go out on the number your clients already have. Inbound texts and call events come back through signed webhooks and land in the thread automatically.

Email works the same way. Connect an existing mailbox over IMAP and SMTP — your domain, your address — and send and receive from inside the client record. Passwords are encrypted, TLS certificates are verified, and connections are checked against an SSRF guard before anything is dialled.

The reason for this design is simple: the phone number and the email address are part of your relationship with the client, and they should not become something you lose access to by changing software.

Internal chat, kept separate

Team chat lives alongside the client threads but is clearly marked as internal. Notes on a thread are visible to your team and never to the client.

That separation is enforced rather than conventional, which matters the first time somebody types something candid about a client's website.

What this does not do

Better to find this out here than three weeks in.

  • SMS and calls require your own Twilio or GoHighLevel account. There is no bundled telephony, and the provider bills you directly for usage.
  • Email uses each team member's own mailbox, connected over IMAP and SMTP; it isn't a shared team inbox or a bulk marketing email platform.
  • Client portal messages are handled as support tickets, in the support desk rather than the conversation thread.
  • There is no WhatsApp, Instagram DM or Facebook Messenger channel today.
  • Call recording and transcription depend on what your provider supports and how it is configured on their side.

Questions

Do my clients need a login to message me?
To open a ticket or message you from the portal or the LeadPulse app, yes. Texts and calls work without a login and land in the client's conversation.
What happens to the history if I leave?
It is your data and it exports. The numbers and mailboxes were never ours in the first place, so they continue working regardless.
Can I keep some messages hidden from the client?
Internal notes are internal by default. A client only ever sees the portal side of a conversation and messages sent to them directly.

Keep reading

Related

The client portal

What clients see when they log in — and what they provably cannot.

Leads

Where an inbound enquiry goes before it becomes a conversation.

Analytics dashboards

The reporting side of the same client record.

Get the conversation out of your inbox

Connect a mailbox and a number, and the history starts building itself from day one.

Start free trialLog in

Give every client message a next step

Client communication software is useful when a message leads to an accountable action. Decide who reviews new conversations, who can answer routine questions, and how delivery questions reach the person doing the work. An owner should know whether they are expected to reply, investigate or hand the thread to someone else. Status and priority help describe the current position, but the next step still needs to be clear. For an illustrative website change request, a useful handoff identifies the page, the requested edit, any missing approval and the person responsible for replying. That context prevents a message from being acknowledged several times without progressing.

Agree which channel serves which purpose

Clients often choose whichever channel is easiest at the moment. Give them a simple guide that respects that habit while making your work manageable. A call may be appropriate for a time-sensitive discussion, an email for a detailed explanation, and a portal ticket for a request tied to a project. Explain where they can see the status of a portal request and what information helps your team respond. Avoid promising instant replies across every channel unless your staffing supports it. The goal is to create a predictable experience: the client knows how to contact you, and the agency knows how each type of request enters its work queue.

Make handoffs readable to someone who was not there

A colleague covering an account should not need to reconstruct a week of conversation before answering one question. Add a brief internal summary when a thread changes hands: what the client asked, what has already been promised, what remains uncertain and when the next update is due. Keep the summary factual and separate from the response the client will receive. If a phone call changed the scope of work, record the decision and arrange confirmation through the appropriate client channel. This practice helps when someone is away, but it also reduces duplicate effort when specialists work together on the same account.

Connect the providers before testing the workflow

SMS and calls depend on the agency's own Twilio or GoHighLevel setup, while email depends on the connected mailbox. Test one representative exchange in each channel you plan to use. Check the sending identity, inbound delivery, client association and the location where the team expects to find the conversation. A connection that accepts credentials is only one part of readiness. Confirm that the external provider is configured for the intended use and that the right team member knows how to investigate a failure. Keep provider billing and service configuration in view when diagnosing a communication problem rather than assuming every delay originates in the client record.

Keep requests and delivery commitments distinct

A client asking whether something is possible has not necessarily approved a change in scope. Use the conversation to clarify the outcome, the deadline and any commercial implications before turning it into delivery work. For example, a request for a new landing page may need an estimate, copy approval and a launch date. Record the agreed decision so the delivery team does not treat an exploratory message as an instruction to publish. Portal support context can help tie the request to a project, but a clear written agreement still matters. Good communication records show both what was requested and what the agency committed to do.

Review the communication process as the team grows

A process that works for two people may need a clearer rota when several account managers share responsibility. Review unanswered conversations, repeated handoffs and recurring client questions to find the actual bottleneck. Some problems need a better internal guide; others need a clearer client instruction or a more realistic response expectation. Keep useful examples in your agency's operating procedures so new colleagues can learn the standard. The product provides places for conversations, ownership and internal notes. The agency supplies the working agreement that makes those tools consistent across accounts, holidays and changes in staffing.

Frequently asked questions

How should I decide who owns a new client conversation?

Assign ownership according to the next action required, not simply who saw the message first. An account manager may own the client response while a specialist investigates. Make that relationship explicit in the internal handoff so the client does not receive conflicting replies or wait while each person assumes someone else is answering.

What should an internal handoff note contain?

Include the client's request, any commitment already made, the work still needed and the next promised update. Link the discussion to the relevant client or project context where appropriate. Avoid copying the entire thread into the note; a concise factual summary should help the next person understand what requires attention.

Can I use this as a bulk email marketing system?

The email connection is designed around team members' existing mailboxes and client communication. It is not presented as a bulk marketing email platform. Keep campaign mailing requirements separate when choosing your software, and use the mailbox connection for the account conversations it is designed to support.

How are portal support requests different from text messages?

A portal request arrives through the support desk with the client's selected context, such as project and priority. Texts and call events belong to the connected messaging workflow. Teach the team where each type appears so a check of one queue is not mistaken for a review of every client request.

What should I test after connecting a phone provider?

Send and receive a representative message, confirm the expected number and verify where the event appears against the client. Test the call workflow you intend to use as well. Review the provider configuration if something is missing, since the connected account and its external settings are part of the communication path.

Do clients need to change their existing email habits?

They can continue communicating through the email address you connect. You can also explain when a portal ticket provides better project context or visible status. Introducing the portal should make an appropriate request easier to handle rather than require the client to guess which channel the agency checks most often.

How do I prevent duplicate replies during busy periods?

Use a clear owner and a handoff convention before several people start investigating the same request. Internal notes should identify who will send the client update. Agree what colleagues should do when they find an unowned or urgent thread so helpful activity does not turn into several inconsistent answers.

Should I put candid team discussion in a client reply?

Keep internal discussion in the internal area and review the recipient and channel before sending an external response. A useful client reply should explain the decision, next step and timing. Internal debate may be valuable to the team without being suitable or necessary for the client-facing conversation.

What belongs in a communication service standard?

Define the channels you support, normal review hours, how urgency is assessed and how clients receive progress updates. Make the standard realistic for your team. A visible priority can help organize work, but it does not create staffing coverage or an automatic guarantee about when a request will be resolved.

How should I document a decision made on a call?

Record the decision, responsible person, due date and any unresolved question while the conversation is fresh. If the decision changes scope or timing, confirm the agreement with the client through an appropriate written channel. This gives colleagues a usable record even when they were not present for the call.

What if a client sends an urgent request through an unsupported channel?

Move the substance into your agreed workflow and explain the supported route for future requests. Do not assume that a message on WhatsApp or a social inbox appears in Agency Pilot. Keeping the channel list explicit helps clients understand how to reach the people who are actually monitoring their account.

How can communication records help new account managers?

They provide the history behind current requests, but history alone can still be lengthy. Combine the record with a short account handoff describing current priorities, open decisions and communication preferences. The new manager can then use the detailed conversations to verify context without asking the client to repeat everything.

What should I check when an email fails to arrive?

Check the intended mailbox, recipient, provider status and connection settings before resending repeatedly. Confirm whether the problem concerns sending, receiving or finding the message in the expected workflow. A clear description of the failure makes investigation more useful than treating every missing email as the same issue.

Can a conversation automatically be treated as a qualified lead?

An inbound text or call begins as a conversation rather than proof of a qualified opportunity. Review what the person is asking and convert a genuine enquiry into the appropriate lead workflow. This prevents routine service questions, existing-customer messages and irrelevant contacts from inflating the new-business pipeline.

How do I know whether our communication process is improving?

Look for practical changes such as fewer repeated questions, clearer ownership and less reconstruction during handoffs. Review a small sample of real requests with the team and ask whether each has a clear outcome. Avoid measuring success only by message volume; a short, complete exchange can serve the client better than many acknowledgements.