Start your search for an internal podcast platform with desk research. Use the audience, devices and communication problem you already know to make a shortlist. Ask suppliers to resolve the important gaps, check that you can launch with the proposed setup, and learn about listening habits through a working pilot.
You can begin comparing platforms while questions about topics, formats and employee interest are still open. Give those questions a place in the pilot. Before committing, establish who can get access, what your team can publish and what the setup will cost.
Below is a practical route from a first shortlist to a six-month pilot review. The six months are an evaluation period; check the supplier's contract term separately.
1. Build a shortlist from what you already know
Write a short working brief. Include the first audience, what you want to explain or share, the devices and accounts people have, and who will run the series. Use an estimated audience size if an exact number is not available. Mark assumptions so you can revisit them.
For example: “We want to share operational updates with colleagues across several locations. They have company accounts and use managed phones. Comms will publish the series. We want to evaluate it over six months before deciding on a wider rollout.” This is enough to start comparing suppliers.
Use product pages, help articles, pricing information and available documentation to check these requirements:
Listening route: Can employees use an app or browser on their available devices? Look for background playback, resuming an episode and a clear route from invitation to listening. If connectivity is a problem, put offline listening on the list of requirements to confirm.
Private access: Can you restrict shows to the intended audience? Check invitation options, company login and how access is removed. Single sign-on (SSO) handles sign-in; you still need to confirm who can access each show.
Publishing: Can a small team upload, schedule, correct and withdraw episodes? Check administrative roles and whether separate departments can have their own shows.
Content and accessibility: Check the formats, transcripts and language options you need. Interface languages and translated content are separate questions. Include any known assistive-technology requirements.
Evidence and support: Look for security and data-processing documentation, implementation help and a clear support route. Availability of documents gives your reviewers a starting point.
Commercial fit: Identify the plan that includes your required app and login options. Look for setup charges, contract length and what changes with more listeners or shows.
Give each essential requirement a simple status: documented, needs confirmation or does not fit. Keep the source link or supplier answer beside it. “Documented” means you found a stated capability; it does not mean you tested your configuration.
Exclude a supplier when it cannot meet an essential requirement. Put an unclear answer in your follow-up message. A missing price or technical detail on a website is a reason to ask, rather than to spend days searching for it.
Aim for a shortlist you can realistically evaluate, for example two or three suppliers. A detailed employee survey can wait. Use the guide to internal podcasting if you also need help choosing the purpose of the series.
2. Send the same brief to shortlisted suppliers
Make the supplier do some of the clarification work. Send your working brief with the gaps you found, and ask for a response you can compare. You can adapt this message:
Message to copy
We are exploring an internal podcast for [audience and approximate size], mainly to [purpose]. Employees use [devices] and [company login or invitation needs]. Our team would like to evaluate the approach over six months.
Please confirm the plan and setup we would need, the full contractual cost and commitment, and what changes if we add more listeners or shows. Please also share the relevant security documentation and a sample report for the proposed listening route.
In a demo, we would like to try opening an episode on our own phone, see how restricted access and removal work, and publish a sample episode. Our open questions are [questions]. Please identify any requirements that your current product cannot meet.
Before you choose a paid setup
You do not need a completed procurement document to send that enquiry. Before choosing a paid setup, ask the colleagues responsible for IT, privacy and purchasing which requirements apply to this pilot. Give them the actual audience, content, login method and supplier documents so they can assess something concrete.
3. Use the demo to check the essentials
Take your phone and a short sample recording. Let the demo answer the questions left by desk research.
Try the listening journey. Open an invitation or link, sign in, find an episode and play it. Lock the screen, switch apps, pause and reopen the episode. Check that it resumes from the earlier position. Ask IT to confirm installation and account requirements for the devices your pilot audience will use.
See who gets access. Ask the supplier to show an authorised account opening a restricted show, an unauthorised account trying the same link, and access being withdrawn. Ask what happens to an existing signed-in session and any previously stored media. Agree with IT which of these checks must be repeated in your own setup before employees join.
Sign-in, show access and following a show are separate controls. A working login does not prove that show access is correctly restricted. Following a show expresses a listening preference; it does not grant permission to hear it.
Try the publishing workflow. Upload the sample recording, add its details, set access and schedule it. Check how you would correct or withdraw it. Ask what work your team will do itself and what help the supplier provides.
For each essential requirement, record whether it was demonstrated, still needs a setup check or cannot be met. A promised future feature remains unavailable for your starting decision. If a gap would prevent the pilot from working, resolve it before committing.
4. Make a small, workable launch plan
You can start with one audience and one series. Choose an audience whose actual devices, accounts and working conditions you need to learn about. If the eventual purpose is to reach colleagues away from desks, include them in the pilot from the start.
Before inviting employees, have these basics in place:
A working, approved access route for that audience, with required device, privacy and security checks completed.
A named person responsible for publishing, the first episodes and a release rhythm the team can maintain.
A short invitation explaining what the series is for, how to listen and where to get help. Provide the accessible alternatives and languages that audience needs.
An agreed budget, contract commitment, review date and person responsible for deciding what happens after the pilot.
Your team can choose initial topics from recurring questions, planned changes or material it already needs to communicate. Keep the first format manageable. A branded app, a large content library or a custom integration can wait unless it is essential to this audience's use.
Confirm the full cost of the commitment before signing. A six-month evaluation may sit inside a longer contract. Ask what you would still owe if you stopped producing after the review, and how content and data can be exported or removed.
5. Use the six-month pilot to learn from actual use
Write down what would justify continuing before the first release. Keep it specific to the pilot: the audience can get access, the team can sustain the planned releases within its time budget, and there is enough evidence of use and relevance to support continuing. Choose measures the platform can actually supply and agree the decision criteria with the budget holder.
Use this schedule as a starting point:
Month 1: get people listening. Release the first episodes and explain how to get access. Use support questions and available usage reports to find login or discovery problems. Fix those promptly.
Months 2–3: establish a repeatable series. Keep publishing and review which episodes receive activity, questions or responses. Adjust subjects, length or promotion based on what you observe. Track the time production takes.
Months 4–5: check whether it works in normal conditions. Look at use beyond the launch announcement, recurring access problems and whether the team can keep going alongside its other work. Check whether the colleagues you intended to reach are represented in the feedback you receive.
Month 6: decide what happens next. Compare the evidence with the agreed criteria and choose to continue, adjust or stop. For expansion, confirm the additional operational work and commercial conditions.
You can gather lightweight feedback in existing channels. Add a question to an episode or a regular team update: “Was this useful, and what should we explain next?” Review responses and support questions as part of running the series. Silence alone does not tell you whether people found it useful.
Keep a short monthly record: episodes planned and published, production time, access problems, available listening measures and useful feedback. Ask the supplier what its reports count, which apps or players they cover and whether they can show repeat use. Playback requests are not a count of distinct employees; a completed play does not prove understanding.
When results disappoint, look for the likely cause before deciding. Access problems need a different response from irrelevant topics or a production schedule the team cannot maintain. You can make those corrections during the pilot instead of waiting for the six-month review.
If the platform cannot meet an essential requirement, raise it with the supplier and reconsider whether it is the right choice.
Apply the checklist to Springcast
Springcast's internal podcast platform provides a restricted-access app for audio and video. Company and Enterprise include the mobile app; Company Light does not.
SSO is a one-off paid option with Company and is included with Enterprise. SCIM supports user and group-membership changes and access revocation for Mobile SSO. Confirm the identity setup with IT. Private distribution uses the app and hidden shows; Springcast does not provide private RSS feeds for these shows.
Pricing is tailored, with no charge per mobile user. Shows, storage, traffic and additional features follow the agreed offer.
Springcast also offers pilots. Ask about the available duration, scope and commercial terms, including what happens after the pilot ends.
Discuss a Springcast pilot
Request a conversation with the audience you have in mind, the devices and login system they use, and what you want to try. Ask about a pilot and bring the gaps from your desk research. We can discuss the setup and terms and demonstrate the relevant tasks so you can decide whether to start.
Springcast