I've spent a lot of time on the paraplanning side of the advice process, and there's a few things that reliably slows the paraplanning process down.
It’s easy to blame the paraplanner (and sometimes it is their fault!) but what I often find is that a poorly structured paraplanning request is the reason things slow down.
When a paraplanner receives a request with wrong, too much or conflicting information, these things usually happen:
- The paraplanner makes assumptions to get the job done on time, which leads to rework;
- They spend half a day hunting through documents, file notes to work out which information to use in the SOA; and/or
- They come back with a long list of questions, which ultimately creates delays.
None of this is anyone's fault, exactly. It's usually a data, template, time and possibly workflow problem. But it's fixable.
Here are some ideas on how to structure the paraplanning brief in your practice:
The three layers to your paraplanning brief
The best way I've seen advisers structure a paraplanning brief is to think about information in three layers, ordered by importance.
The first layer is the non-negotiables. I like to call these the ‘Fundamentals’. Without these, the paraplanner can't start. Basic client information, agreed goals and scope, risk profile, strategy outline, product recommendations (including alternatives considered), fees, disclosure requirements, projections required, the SOA template, and the due date.
With this information, the paraplanner has a good understanding of what to write/model and by when. Put all this information in the first 2-3 pages of the request.
The second layer is the supporting information. Once the scope of the advice is clear, supporting information helps the paraplanner write the SOA accurately.
Examples of information include: Fact find, insurance quotes, product fee comparisons, contribution history, super fund data, Centrelink assessments. The paraplanner may need these to write the SOA accurately, but they don't need to read all of it upfront to get an understanding of the advice. What matters is that the documents are clearly labelled and easy to find when needed. A folder dump with 30 unlabelled PDFs is not supporting documentation. It's a scavenger hunt.
The third layer is information for context. Things like file notes, previous SOAs, trust deeds, and licensee guidelines. This information has its place. But it should sit in the background, available if the paraplanner needs it, not front and centre of the brief.
What not to include
This one surprises some advisers, but generic benefits and disadvantages text does not belong in a paraplanning request. If it's in the SOA template (and it should be), it's already handled. What the paraplanner actually needs from you is the specific reasoning, the why behind this recommendation for this client.
For example: "We've recommended retaining XYZ Super Fund to isolate the tax-free component for death benefits. The adult children won't pay tax on any death benefit payments, but note fees are 0.2% p.a. higher than the alternative."
That's useful because it’s not generic and shows why you’ve made a certain recommendation if it is not obvious. A copy-pasted list of generic product pros and cons is not.
Handwritten notes are also worth a mention. They’re no good. They slow the process and create errors. Data should be captured digitally in software and provided to the paraplanner in a structured way. (It is 2026, after all).
And finally, thought processes and musings. If you're still working through the strategy when you write the brief, that's a signal to pick up the phone before the request goes in, not to include the deliberation in writing. The paraplanning request should say what the advice is and why. The thinking behind it belongs in your file notes and confuses the request.
When the paraplanner comes back with questions
They will, even with a clean brief. That's normal and it's part of the process working correctly.
When they do, the two things that make the biggest difference are speed and specificity. If a paraplanner is waiting on a confirmation from you to finalise modelling, every day of delay is a day closer to a missed presentation date.
When you answer, be specific. "I think it was around $60,000" is not an answer that moves the job forward. A paraplanner can't write a confident SOA on a best guess.
Email works well for clear, factual questions where a written record matters. Phone or video is better for anything complex, urgent, or likely to spiral into a long thread. If you do talk through something on a call, send a quick follow-up confirming what was agreed. It protects everyone.
An idea is to include a ‘Paraplanner Working Paper’ to the request, which includes:
- Assumptions made by the paraplanner
- Any missing information
- Questions that can be answered in the document
- Decisions tracker
Make the request a ‘shared document’ and use this as a working paper during the SOA writing process.
Being clear means operational efficiency
Contract paraplanning is typically charged by the hour or by the job. Employed paraplanners are an expense that is more effective when more SOAs are written per week. Either way, a poorly structured request costs more than a well-structured one. Rework costs more. Delays cost more. The time a paraplanner spends deciphering a confusing brief is time they are not spending writing your SOA.
There's also a compliance dimension. Paraplanners are, whether we acknowledge it or not, a second set of eyes on advice quality. When a brief is clear, they can do that job properly. When it's a mess, they're too busy reconstructing the picture to catch any issues.
The request is where the SOA process either sets itself up for success or doesn't. It’s worth getting right.
Download a paraplanning request template here
