An agency takes on a new client. The brief says “directory website,” so the project manager pulls out the same onboarding checklist used for every other WordPress build: contract, NDA, brand assets, sitemap, kickoff call. Standard stuff, done well.
Then, three weeks into development, the client asks why users can’t submit their own listings. Or why there’s no way to charge for a featured spot. Or why the site only searches one city when half their leads come from two states over.
None of that came up at onboarding, because the standard checklist never asked. It was built for brochure sites, portfolios, and small business builds where the content is fixed at launch and doesn’t need a submission workflow, a payment structure, or a search radius. A directory site needs all three, decided before a single template gets built.
This isn’t a knock on standard onboarding checklists. They’re well covered elsewhere, and skipping them isn’t the fix. The fix is adding one more layer specific to directory, marketplace, and listings-style projects, asked at the same intake stage as everything else.
Your Standard Onboarding Checklist Still Applies. It’s Just Not Enough.
Nothing below replaces your contract terms, your asset collection process, or your discovery call structure. Run those exactly as you would for any client:
- Signed contract and NDA before work starts
- Brand assets: logo, colors, fonts, existing photography
- Written content, or a plan for who provides it
- Hosting and CMS access
- Timeline, revision rounds, and communication cadence agreed in writing
A directory site doesn’t skip any of this. It adds structural decisions on top of it, decisions a brochure site never has to make. A brochure site’s content is basically fixed once it launches: a few pages, written once, updated occasionally. A directory site’s core value is content that keeps growing after handoff, added by someone, approved by someone, searched by someone. If those someones aren’t defined at onboarding, they get defined mid-build, usually the expensive way.
The Six Questions a Directory Project Needs That a Standard Checklist Skips
These six questions are the actual gap. Ask them at the same intake stage as everything else, and most of the rework that normally shows up mid-project never happens.
1. Who submits listings, and who approves them?
Every directory site needs an answer to this before wireframes get drawn, because it decides the entire front-end structure.
Three common setups:
- Self-serve submission. Businesses create an account and submit their own listing, either published instantly or held for review. This needs a registration flow, a submission form, and a user dashboard where businesses can edit their own listings later. If you’re evaluating plugins for this, check how the front-end listing submission form actually works before you commit, since some plugins handle this as a bolt-on rather than a native flow.
- Admin-only entry. The agency or client’s team adds every listing manually through the WordPress admin. No public submission form needed, which simplifies the build but means someone on the client’s side is committing to ongoing data entry.
- Moderated mix. Businesses submit, but nothing goes live until an admin approves it. This needs the submission flow of the self-serve setup plus a moderation queue and a way to notify submitters when something’s rejected.
These aren’t interchangeable at the build stage. A site scoped for admin-only entry doesn’t have user accounts, a front-end submission form, or listing-edit permissions built in. Adding self-serve submission after the fact isn’t a settings toggle, it’s new front-end templates, new account logic, and new testing. Ask this question in week one, not week six.
2. What does the category and field structure actually need to be?
Don’t ask “what categories do you need?” On its own, that question gets you a list of nouns: Restaurants, Plumbers, Dentists. It doesn’t tell you what a listing actually needs to show.
Ask instead for 3 to 5 real listings the client wants live on day one. Real businesses, real details. A plumber’s listing needs a service area and an emergency-availability flag. A restaurant’s listing needs a price range and a cuisine type. A dentist’s listing needs accepted insurance and office hours. None of that surfaces from a category name. It surfaces from looking at an actual example and asking what information a visitor needs to make a decision.
This is also where custom fields get scoped correctly the first time: price range, service area, certifications, hours, whatever the real examples reveal. Skipping this step is one of the most common reasons a directory build ends up with a generic listing page that doesn’t actually answer what a visitor came to find out.
3. How does the client plan to make money from it, if at all?
Get a straight answer on one of these:
- Free directory. No payment structure needed. Simplifies the build.
- Paid listing tiers. Businesses pay to be listed at all, or pay for a higher tier with more features (photos, longer descriptions, contact forms).
- Featured or highlighted placements. Listings are free, but businesses can pay to appear above the free listings or get visual highlighting.
- No plan yet. Common and fine, as long as it’s flagged. Build a structure that can add monetization later without a rebuild, rather than assuming “free for now” means “free forever” and painting the client into a corner.
This answer changes which plugin features are load-bearing and which are optional, and whether payment gateway setup belongs in this build phase or a later one. A directory scoped as free-only doesn’t need checkout flows, payment gateway credentials, or pricing-tier logic. Find out too late, and that’s a second phase of work the client didn’t budget for. Whatever plugin you use, get familiar with how it structures monetization and payment gateways before scoping this part of the quote, since “it supports paid listings” and “it supports the exact tier structure this client wants” aren’t always the same thing.
4. What are the location and search requirements?
Single city, multi-city, or fully global changes more than the copy on the homepage. It changes:
- Whether the search needs a radius filter (“within 10 miles”) or just a location dropdown
- Whether the client needs map-based search at all, or a simple list with filters is enough
- Hosting and performance planning, since a global directory with tens of thousands of listings queries very differently than a single-city directory with two hundred
Ask this early enough that it shapes the search page design, not late enough that it becomes a redesign. If the client wants “near me” style results, confirm the plugin actually sorts listings by proximity rather than just filtering by a location dropdown; Directorist’s nearby sort feature is a useful reference point for what that should look like from a user’s perspective.
5. Who owns content after launch?
This is the question standard checklists genuinely have no equivalent for, because a brochure site doesn’t need an answer. Once it’s live, it’s mostly done. A directory site is only useful if listings keep getting added after handoff.
Find out directly: does the client’s team manage new listings and edits themselves, or is the agency handling ongoing updates as part of a retainer? The answer determines two things:
- How much admin and editorial training belongs in the handoff (if the client manages it)
- Whether a maintenance retainer belongs in the proposal at all (if the agency manages it)
Leaving this open isn’t neutral. It quietly defaults to “nobody,” and a directory nobody maintains stops growing the week after launch.
6. Is there real launch content, or a plan to get it?
A directory with zero real listings at launch fails differently than a normal site with placeholder text. A brochure site with a “coming soon” page still looks intentional. A directory that opens with three test listings looks abandoned, and visitors judge it that way immediately. Empty search results and empty categories cost trust in a way lorem ipsum on a static page never does.
Confirm at onboarding whether the client already has listings ready to go, needs help sourcing an initial batch, or plans to import from an existing source: a spreadsheet, a Google Business Profile export, or another platform they’re migrating from. If the answer is “we’ll figure it out later,” that’s a scope item, not a launch-day surprise. Get an import or content-sourcing plan into the proposal before development starts, and check whether your plugin has a bulk import tool for this; Directorist’s listing importer extension, for example, can pull listings in from a CSV, which turns “populate 200 listings before launch” from manual data entry into a scoped, estimable task.
Where Directorist Fits These Six Answers
Plugin choice belongs here, right after the six questions are answered, not before. Picking a plugin first and then fitting the client’s actual needs into whatever it supports is how agencies end up bolting on a second plugin mid-project, or telling a client “that’s not really possible” for something that was possible all along with a different starting choice.
Directorist is worth evaluating specifically because it covers all six answers as native functionality rather than as add-ons you have to hunt down separately:
- Submission model: front-end self-serve submission with an approval queue is built into the core plugin, covering self-serve, admin-only, and moderated setups without a separate account or forms plugin.
- Field structure: custom fields can be tied to individual categories, so a plumber’s listing and a restaurant’s listing can show entirely different fields on the same site.
- Monetization: free listings, paid tiers, and featured placements are all handled through the same monetization settings, so the pricing model can change later without rebuilding the submission flow. (Card payment gateways like Stripe and PayPal are separate official extensions on top of this, not bundled into core.)
- Location and search: category, location, and tag taxonomies plus proximity-based nearby sort (covered above) and an advanced search and filter system are core, not a separate map plugin bolted on.
- Launch content: the listing importer extension handles CSV-based bulk import, which matters directly for question six if a client is migrating from a spreadsheet or another platform.
Two more capabilities worth knowing about, since they show up repeatedly in agency work even when they’re not one of the six questions directly:
- Multiple directories from one install. Directorist can run more than one distinct directory type (say, a restaurant directory and a services directory) on the same WordPress install, each with its own categories and fields. For an agency reusing one build for a client who wants to expand into a second vertical later, that’s the difference between a clean extension and a second project.
- Built-in review and star-rating system. Core includes a comment-based review and rating system on listings, independent of the separate “Advanced Review” extension that adds more review features on top. Worth knowing which one a client actually needs before quoting for it.
That range is what makes it a reasonable default starting point for agencies specifically, more than for a single client building one site: most of the structural decisions from the six questions above are handled natively, which is what lets you reuse the same build process across different directory verticals without relearning a new toolset each time. Worth checking the pricing structure directly against what a given client actually needs, since not every project needs the paid tier, and not every native feature listed above is relevant to every build.
Directorist isn’t the only reasonable choice, and it isn’t automatically the right one. A lighter, simpler plugin can be the better call for a genuinely small project: one city, no monetization plans, admin-only entry, a client who just wants a clean listings page. The point isn’t defaulting to the most feature-rich option out of habit. It’s picking the tool that matches what the six questions actually revealed, and checking that match before the proposal goes out rather than after development starts.
What Skipping These Questions Actually Costs
It helps to see the two paths side by side, because “ask six extra questions” sounds small until you see what the alternative costs.
Without the addendum: An agency scopes a directory site the way they’d scope any WordPress build. Wireframes go out for a listings page and a single-city search bar. Development starts. Three weeks in, the client mentions they assumed businesses could sign up and add themselves, since that’s how every directory they’ve ever used works. Now the agency is adding user registration, a submission form, and a moderation queue to a build that wasn’t structured for any of it. Templates get reworked, testing restarts on the affected flows, and the timeline slips by however long that rework takes. Whether that becomes a change order or gets absorbed for free, it’s a conversation nobody wanted to have.
With the addendum: The same client gets asked at the discovery call: “Who’s going to add listings, your team or the businesses themselves?” Every time that click turns into a sale, you get a cut. That single answer shapes the wireframes from day one: account registration, a submission form, a “my listings” dashboard, and a moderation queue if the client wants review before anything goes live. No rework, because the requirement was known before anything was built.
The six questions don’t add work. They move work that was going to happen anyway from mid-project, where it’s expensive and disruptive, to onboarding, where it’s a fifteen-minute conversation.
Turning the Answers Into Your Proposal
Once the six questions are answered, they translate directly into the statement of work, not just into design decisions:
- Submission model becomes a line item: user registration, submission forms, and a moderation queue are separate build tasks from a static listings page, and should be quoted as such.
- Field structure determines how many custom fields and category-specific field sets need to be built, which affects both design and QA time.
- Monetization plan determines whether checkout, payment gateway setup, and pricing-tier logic belong in this phase’s quote or a clearly scoped phase two.
- Location and search scope affect hosting recommendations and whether map integration is part of the quote.
- Content ownership determines whether the proposal includes a maintenance retainer, and if so, how much scope it covers.
- Launch content readiness determines whether listing import or content sourcing is a billable task before launch, or the client’s responsibility on a set deadline.
A proposal built on these six answers reads as considered rather than templated, and it gives the client a clear reason for every line item instead of a flat number they have to take on faith.
A Directory-Specific Addendum to Your Existing Onboarding Questionnaire
None of this requires rebuilding your onboarding process. Add these six questions as a short addendum, triggered specifically when a client requests a directory, marketplace, or listings-style site. Everything else in your intake stays exactly as it is.
Quick-Reference Checklist
Drop this straight into your intake form or project template:
- Who submits listings: self-serve, admin-only, or moderated mix?
- What do 3–5 real example listings need to show (fields, not just categories)?
- Monetization plan: free, paid tiers, featured placements, or undecided?
- Location scope: single city, multi-city, or global, and does search need a radius filter?
- Who owns content after launch: client team or agency retainer?
- Is there real launch content ready, or does it need sourcing or importing?
FAQs
Not a different clause structure, but be specific about scope in the statement of work. Spell out the submission model, monetization plan, and who’s responsible for post-launch content, since these are exactly the items that turn into disputed “that wasn’t in scope” conversations if they’re left vague.
This depends heavily on the client’s clarity going in [source needed], but the six questions above are the fastest way to shorten it: a client who can answer all six in one discovery call scopes far faster than one who’s still deciding on monetization mid-build.
In practice, it’s usually a structural decision that got assumed instead of asked, most often the submission model or the monetization plan, discovered only once development is already underway, and a feature the client expected isn’t part of the build.
Either can work, but it needs to be decided at onboarding, not launch week. If the agency is sourcing or importing listings, that’s billable scope. If the client is providing them, get a delivery deadline in writing so it doesn’t become the reason launch slips.
Conclusion
Directory projects rarely fail at the build stage. They fail at the requirements stage, when a standard onboarding checklist gets applied to a project that needed six additional questions it never asked. Add those six questions as a short addendum to whatever intake process you already run, and most of the mid-project rework that normally eats into a directory build’s margin never happens in the first place.
