# What a Real IoT Deployment Looks Like From Start to Finish > One generic deployment, 40 cold rooms across 6 sites, walked through every phase in dependency order with realistic durations and where the time actually goes. ![What a Real IoT Deployment Looks Like From Start to Finish](https://tago.io/og/blog/what-a-real-iot-deployment-looks-like-start-to-finish.png) Every vendor diagram of an IoT deployment has three boxes: sensor, cloud, dashboard. The picture is not wrong. On a decent platform the plumbing is the easy part. The picture is wrong about time. A real deployment is a sequence of unglamorous steps with a dependency order, and most first-time teams do them backwards: dashboard first because it is fun, hardware second because that is when the project feels real, users last because someone remembers a week before go-live that the customer's staff need to log in. Each reversal costs weeks. Below is one generic deployment walked through in order: a system integrator putting temperature and door sensors into 40 refrigerated rooms across 6 sites for a food distributor. Swap in tanks or meters; the phases do not change. ![Thirteen weeks to handover in dependency order for 40 cold rooms across 6 sites: scope and acceptance, site survey, hardware procurement running four to six weeks with platform setup finished inside that lead time, commissioning, alerts and users, go-live tuning, and handover, with month three adding data retention and a monthly report](https://tago.io/images/blog/what-a-real-iot-deployment-looks-like-start-to-finish/thirteen-weeks-to-handover.svg) ## Scope and acceptance criteria (week 1 to 2) "We want to monitor the cold rooms" is a wish, not a scope. The deployment needs a written definition of done. Here: temperature every 10 minutes, door open longer than 5 minutes flagged, alarm above 5 C for 20 minutes, push notification to the site manager and email to the operations lead, a per-site page with per-room history. Two weeks sounds long for a document. The time goes to waiting: the operations lead and the facilities contractor disagree about who owns alarm response, and nobody settles it until you ask in writing. Skipping this moves the two weeks to go-live, where they cost more. More in the [planning guide for non-technical PMs](https://tago.io/blog/planning-an-iot-project-non-technical-pm). ## Site survey and connectivity check (week 2 to 3) Refrigerated rooms are metal boxes with insulated doors. Radio does not like them. Before ordering 40 sensors you need to know, per room, whether a LoRaWAN gateway in the corridor reaches inside with the door closed, and whether that gateway has power and backhaul. One person, two test sensors, a gateway, a day per site. The survey rewrites the hardware list: two sites need a second gateway, one has no cellular signal in the plant room. Finding this now costs a week; finding it during commissioning costs a return visit per site. [LoRaWAN range in the real world](https://tago.io/blog/lorawan-range-in-the-real-world) has the numbers. ## Hardware procurement (week 3 to 8) and platform setup (week 3 to 5), in parallel Sensors and gateways arrive in four to six weeks. First-timers wait. Experienced teams build the whole platform side in that window with no hardware in hand, the biggest schedule win in the project. On TagoIO the order is: - Create one Device using the [Connector](https://docs.tago.io/docs/tagoio/devices/adding-devices-with-connectors) for the sensor model and the Network for the LoRaWAN provider. The Connector decodes the vendor's bytes into temperature, door state, and battery. - Run a sample uplink from the datasheet through the Payload Parser and check it produces the variable names your dashboard and alerts will use. Unit conversions and renames go into the Parser now, once. - Decide the tag convention before anything else exists: site, room, `asset_type`, customer. Dashboards, alerts, access policies, and reports all filter on them. - Build a [Blueprint Dashboard](https://docs.tago.io/docs/tagoio/dashboards/blueprint-dashboard) that resolves Devices by tag. One dashboard serves all 40 rooms and every future room. Post simulated data to the test Device so the widgets have something to show. Two weeks of one engineer. When the hardware lands, the platform is done, not started. ## Hardware commissioning and tag discipline (week 8 to 10) Installation takes as long as it takes: a sensor per room, gateways on the wall, labels on everything. Six sites at two days each is two weeks for one installer. The platform half is where tag discipline pays out. For each sensor, create the Device from the same Connector, set its tags to the room it hangs in, and confirm the first uplink. Room 17 at site 3 appears on the Blueprint Dashboard the moment its Device has the right tags and one data point. Nobody builds a dashboard during commissioning. If someone is, the earlier phase was skipped. Keep a commissioning sheet: device EUI, site, room, install date, installer. When a sensor goes quiet in month three, this sheet turns an afternoon into a five-minute fix. ## Alerts through Actions, and who receives them (week 10) The thresholds came from scope; the week goes to agreeing who gets what. Set up [Actions](https://docs.tago.io/docs/tagoio/actions/defining-actions) that trigger on the variable condition (temperature above the limit for the agreed duration, door open too long) and send a push notification to the TagoRUN users for that site plus an email to the operations lead. One Action per alarm type, filtered by tag, covers every room. Add a "device silent for 2 hours" Action too: a dead battery is the most common failure and it produces no data, so no threshold ever fires. Route everything to yourself for the first days. ## End-user access through TagoRUN (week 10 to 11) The site managers never see the TagoIO Admin. They log into a [TagoRUN](https://docs.tago.io/docs/tagoio/tagorun) portal under the integrator's brand, on the web and on the TagoRUN mobile app so push notifications reach their phones. An [Access Management policy](https://docs.tago.io/docs/tagoio/tagorun/access-management/creating-a-policy) grants each user the Blueprint Dashboard scoped to Devices whose site tag matches theirs; the operations lead gets one spanning all six sites. Create the users a week before go-live and walk one site manager through the app on a call. Their questions become the first page of the runbook. ## Go-live and the first two weeks (week 11 to 13) Go-live is an email saying the alerts now go to the customer. Then the false alarms start. Every cold room deployment produces the same two weeks: the 5 C threshold fires whenever a forklift props the door for restocking, the door alarm triggers during scheduled cleaning, and one room runs warmer by design because it stores produce. None of this was knowable from the scope document. Actions get longer durations, a cleaning window gets excluded, room 22 gets its own threshold through a tag. Tell the customer in advance that these weeks are for tuning, or they read the noise as a broken system. ## Handover to operations (week 13) Handover is a document and a meeting: the runbook (what each alarm means, who responds, how to replace a sensor and re-tag its Device), the commissioning sheet, the current thresholds, and a named owner on each side. Sold as a [managed service](https://tago.io/blog/how-to-price-an-iot-managed-service), the monthly fee starts here and the project budget stops. ## Month three By month three the deployment is boring, which is the goal. Then the unplanned requests arrive. Data volume becomes a line item. Forty sensors every 10 minutes is over 5,700 readings a day, and raw history is not needed past a few months. [Data Retention](https://docs.tago.io/docs/tagoio/devices/data-management/data-retention-feature) on each Device caps it. The customer asks for a monthly report. A scheduled Analysis computes minutes out of range and door-open minutes per site and writes a summary for a widget or an email. A day of scripting, because the tags already carve the data by site. The customer wants two more sites. Expansion is survey, hardware, Devices with the same Connector and the new site value, and users with a policy for it. The dashboard, the Actions, and the report already work. Thirteen weeks to handover, with the platform work fitting inside the hardware lead time and most of the calendar spent waiting on people, radio, and delivery. The three boxes were never the problem. [llms.txt](https://tago.io/llms.txt)