MSDP product guide
MSDP gives delivery teams a shared record of what must be done, who owns it, what evidence was collected and what has been accepted.
Who uses it
| User | Typical work |
|---|---|
| Administrator | Accounts, permissions, reusable configuration and internal activity tools |
| Project manager / dispatcher | Project setup, sites/DUs, planning, assignment and correction coordination |
| Field resource | Assigned personal/team WOs, KCP inputs/photos, location checks, clock sessions |
| Delivery approver | Submitted work and KCP decisions in the configured review route |
| Service manager | Customer PO import, item/code mapping, DU publication and revenue requests |
| Revenue / finance reviewer | Eligible revenue items and reversal evidence/decisions |
| Viewer | Permitted read-only project records and reports |
These are operating responsibilities. Actual access depends on account status, configured role permissions and record scope.
Product areas
Delivery setup: customer/project identity, project teams, resource profiles/documents, workflow milestones, WO templates, customer site pool and DUs. Project attributes belong to DUs; customer service data belongs to PO/publication records.
Delivery control: compact rollout matrix with milestone plan/actual dates, owners, remarks and dispatch. WL represents one site; MW represents two distinct sites. Rollout maps show recorded site locations under project/workflow filters.
Field execution: Flutter starts with to-do work assigned to the account or its teams. WO cards expose WO number, DU, site and project. Detail separates checklist, context, approvals and activity. Field users save evidence, review validation and submit. Returned work identifies corrections; approved KCPs remain locked.
Resources and time: profile information, region, joining date, documents, project assignments, clock reports/maps and workload charts. These are operational records; recorded hours are not automatically approved payroll or an individual performance score.
Customer services and revenue: import PO lines; classify items through service codes; publish onto DUs; issue eFlows; approve selected items; trace partial decisions and reversals. Service hub exposes current allocation/revenue state. Revenue dashboard separates approved, pending and remaining published value by customer/project/workflow/currency.
Traceability: submission snapshots, decision remarks, protected attachments and audit records retain context. Import templates and previews support controlled changes. Internal managed-service activity estimates are restricted to administrators.
Glossary
| Term | Meaning |
|---|---|
| DU | Delivery unit connecting project workflow to site A and optionally site B |
| Milestone | Delivery stage instantiated on a DU; can exist without a WO template |
| WO | Dispatched task with a captured template and review route |
| KCP | Group of checklist items in a WO form |
| PO / PO line / PO-Line | Order number, its line number and separately displayed customer line identifier |
| Service code | Customer-specific classification mapping unique items to a standard revenue milestone |
| Publication | Retained assignment of a PO line to one DU |
| eFlow | Revenue or reversal request containing independently reviewable items |
| Triggered revenue | Approved platform revenue, not merely a created request |
| Remaining | Current published value minus net approved revenue, floored per line; includes pending requests |
| Reversal | Linked negative record offsetting approved revenue while preserving original history |
Boundaries
The current Flutter app needs connectivity; durable offline drafts and upload queues are future work. Native camera/GPS and Android/iOS distribution need separate verification. Invoice creation, payment collection, ERP posting and procurement execution are not implemented. Setup acknowledgement for customer/project/workflow/template creation is planned, not an existing approval stage. Evidence uploads support review; an email attachment alone never proves approval.
For the operator sequence see the signed-in documentation library. Your administrator creates accounts and grants project access; the landing page does not register customers automatically.