Multiuser Scope of Work (SOW)
A platform that will be a single WordPress installation with users having their own subdirectory with their own media files library, separate from other users. Control access for edits, deletes, etc., not shared with other users. Example: ourplatform.com/clientname would be their landing page, login and directory for ALL media assets.
The goal of this project is to create a single WordPress installation designed as a “behind the scenes” platform that is subscribed to by small businesses (local restaurants, bars, live venues, etc.) “client” that will enable them to have an integrated link on their existing website that links to it to offer a variety of industry-specific tools – plugins, etc. that they would otherwise not be able to afford to have low-cost access to.
This SOW is primarily on how to create the file and user access control structure defined below.
Let’s say our platform is called “ourplatform.com” for the purpose of this project.
All of our application services would be public for viewing, yet only accessed to a visitor by linking from the client’s site to a specific URL. Example: ourplatform.com/clientname and/or ID. (This can be done by either using a CNAME, or other domain masking that redirects to the same).
General example of how access would work:
- We would provide a graphical toolbar for their existing website (not part of this SOW) with links to their custom pages on our platform.
- Each client will have a subdirectory on our platform example ourplatform.com/clientname. Call this their “virtual platform (VP).”
- Client would have a handful of their own premade “template pages” on their VP such as:
- Menus. (Not a part of this SOW).
- Online to-go food ordering (Open Table or another WP plugin)
- Event calendar(s). Event calendar or other WP plugin (not a part of this SOW).
- Dining reservations. Open Table or other WP plugin, (not a part of this SOW).
- General static page(s) with their loyalty rewards ID and link to join program (not a part of this SOW).
- Photo galleries (not a part of this SOW).
- Hours of operation (not a part of this SOW).
- Call now widget (not a part of this SOW).
SOW: Critical Operational – Workflow and Access Control Considerations (Must Haves)
- Client would have “limited” admin access to a dashboard of their own (NEVER access to WP admin dashboard). Let’s call it: ourplatform.com/clientname.
- When client admin logs in, they would have the ability to add, modify certain pages on their VP such as menus, events, photo galleries, etc.
- Their needs to be at least two client admin roles:
- Owner/manager with full access privileges to their VP
- Editor with limited access for adds, and changes
Directory & file structure is critical. Each client’s VP must have their own media library and file folder for archives, and other non-media related files.
- Their own media library is critical so as to not have shared files across hundreds of other VP accounts. They can only upload, view and delete their own VP media.
- Our view is that their VP URLs & file paths would look something like: ourplatform.com/clientname/files/filename, and ourplatform.com/clientname/media
- The balance of their handful of pages would simply be ourplatform.com /clientname/pageURL.
With this file structure, our ability to remove a client AND ALL related files, media, etc., would be by simply deleting their top-level sub directory.
This is about us creating a unique VP for each client, each having some specific and custom elements that we will build in per project. The critical part is the directory and file structure outlined above. The client must have their own file structure for accessing and editing.
Note: This is not a consumer web platform. The only way a visitor would access any VP pages is through a link from a client site. The “top-level” domain ourplatform.com would be a simple login dashboard page. Nothing for the consumer.
*Please comment to this SOW on this post, or if allowed, via email to email@example.com with MU SOW in the subject line, or by direct message.