Use Spenta yourself
Build a model yourself, or step into one our team is building and change it. Spenta frames the question, runs the options and shows every step.
See how Spenta worksTwo ways to work with us
Use Spenta yourself, or let our team run the project.
This page is about the second way: our PhD-led simulation team works with you from the first question to the final report.
Work with our simulation team
Our PhD-led team scopes the decision, builds and calibrates the model, compares your options and delivers a report you own.
How we run your projectHow we run your project.
From your first question to a report you own. You review every step with us.
Talk to UsA conversation about the decision you are facing.Step 1 of 5
What we will model, compare and deliver, agreed in writing.Step 2 of 5
The model is built and checked against the observations you provide.Step 3 of 5
Your options run on the same demand, several times each.Step 4 of 5
A decision brief and the model documentation, handed to your team.Step 5 of 5
01Problem formulation
Frame the decision
We start from the decision you face, not from the model.
- Who decides, by when, and what would change the answer.
- The changes you can realistically make, and the ones you cannot.
- Whether simulation is the right tool for this question at all.
ProducesA shared problem statement
02Objectives and conceptual model
Agree what the model includes
We sketch the model with you first: what goes in, what stays out, and why.
- The questions the study must answer and the scenarios to compare.
- A written assumptions document your team walks through with us, line by line.
- The model boundary, validation approach, deliverables, fees and schedule.
ProducesA written proposal and agreed assumptions
03Data, build, verification and validation
Build it, then test it against reality
Our practitioners build the model in Spenta while your data comes in, and check it as it grows.
- Data is requested early and checked for gaps and averages that hide the detail.
- Verification: the model does what the assumptions say it should.
- Validation: its output is compared with your observations, against criteria agreed up front.
ProducesA validated model, with its limits stated
04Experiments and analysis
Run every option on the same demand
Each option runs several times under identical conditions, so differences come from the change and not from chance.
- Run length, replications and warm-up are set for each scenario.
- Sensitivity checks show which inputs actually move the answer.
- A midway review with you before the secondary scenarios run.
ProducesComparable results, with their spread
05Documentation and implementation
Hand over a decision you can defend
We walk your team through the findings live, then hand everything over.
- Recommendation, options compared, results and assumptions in one brief.
- The animation and the model documentation, so others can check the work.
- You own all of it, with no dependency on Simuland to interpret it.
ProducesA decision brief and model documentation
Pedestrian projects
You usually bring
Sites, capacities and what each makes
Demand by product and market
Lead times and transit times
Reorder, sourcing and shipping rules
Costs, rates and stock history
Recorded
You usually receive
Shortages and stock over time
Where capacity runs out
Cost and service by option
A decision brief
What is different for supply chain projects: you build a model you can keep asking. Costs and service targets are agreed first; after that, a closed road, a new site or a changed duty rate is one more question, not a new project.
You usually bring
- Plans and layouts
- Arrival patterns
- Service and processing times
- Schedules and staffing
- Observed visitor behavior
Recorded
You usually receive
- Waits and queues
- Where congestion forms
- Flow and service measures
- A decision brief
What is different for pedestrian projects: behavior assumptions are checked against observations, and safety or evacuation scope is agreed separately.
You usually bring
- Layouts and process routes
- Cycle and changeover times
- Demand and product mix
- Shifts and maintenance windows
- Breakdown and repair records
Recorded
You usually receive
- Output and work in progress
- The station that limits the line
- Where stations and vehicles wait
- A decision brief
What is different for manufacturing projects: people, robots, conveyors and vehicles are modeled together, so a change to one shows up in the others. Cycle times and schedules are checked against your records; robot safety and programming stay outside the study.
You usually bring
- Layouts, racks and conveyors
- Order lines and release history
- Pick, pack and travel times
- People, shifts and charging
- Robot, sorter and dispatch rules
Illustration
You usually receive
- Robot and people waiting
- Where work queues: stations, sorter, doors
- Orders packed and trucks on time
- A decision brief
What is different for warehousing projects: people, robots, racks and conveyors are modeled together, so a change to one shows up in the others. Pick times and equipment behavior are checked for your site; commissioning and safety approval stay separate.
Project scoping
Describe the decision. We will tell you whether simulation can answer it.
Start with the operational question, not a software checklist.
For the first conversation, three things help.
- The decision and when it must be made.
- The alternatives you can realistically act on.
- The operating data you have, and what is missing.
We agree scope, validation criteria, deliverables and commercial terms in a written proposal. Data readiness and model complexity determine the plan.