Clear answers.
Confident operations.

CloudScaff is cloud-based software for scaffolding and formwork operations. It connects inventory management with site activity so your yard, field teams, and office can work from the same operational records.

You can track material requests, deliveries, transfers, returns, and stock conditions alongside scaffold registers, inspections, handovers, and dismantles. This gives your team a clearer picture of where equipment is, what is happening on each project, and what needs attention.

CloudScaff is designed for businesses that own, hire, move, or manage scaffolding and formwork equipment. This includes scaffold contractors, hire companies, formwork suppliers, industrial access teams, and construction or maintenance businesses managing their own stock.

It supports the people involved in the work: stock controllers, yard managers, site supervisors, inspectors, operations managers, administrators, and customers who need controlled access to project information.

CloudScaff helps when operational information is scattered across spreadsheets, paper tickets, messages, emails, and phone calls. Common problems include uncertainty about available stock, incomplete delivery records, unrecorded transfers, unexplained return differences, and difficulty finding the latest scaffold documentation.

Bringing these records together makes it easier to investigate discrepancies, follow up on outstanding actions, and keep the yard and office informed as work progresses.

No. Inventory is one part of CloudScaff. You can also manage scaffold records, inspections, handovers, modifications, dismantles, site instructions, tasks, and supporting documents.

The two areas serve different purposes. Inventory management follows equipment quantities and movements. Scaffold management follows the structures erected on site and their operational records. You can introduce the workflows that matter most to your business first.

Yes. You can use CloudScaff to manage stock, deliveries, transfers, returns, and reconciliation without introducing every scaffold management workflow at the same time.

For example, a business focused on equipment hire may begin with yard and site inventory. Permissions can limit users to the functions they need, helping the team learn a manageable process before expanding its use of the system.

Yes. Businesses that primarily need scaffold traceability can focus on scaffold records, registers, handovers, inspections, and dismantles.

During setup, define how you identify each scaffold, who completes its records, who signs the handover, and who needs access to the latest information. Inventory workflows can be introduced separately if they are part of your requirements.

Yes. The inventory workflows can be used for formwork equipment as well as scaffold components. Your catalogue, categories, yards, deliveries, transfers, and returns can reflect the equipment you actually operate.

Keep distinct item types, sizes, and systems clearly identified. This is especially useful when several products look similar but cannot be treated as interchangeable for counting or allocation.

Equipment can be included in your inventory catalogue and moved through the relevant stock workflows. This can be useful for accessories or other items that travel between your yard and projects.

If you need equipment-specific processes such as serial-number servicing, calibration, statutory examinations, or meter readings, bring those requirements to your demonstration. Quantity tracking alone should not be assumed to cover every specialised equipment-management requirement.

Yes. A small team can use CloudScaff to establish clear stock and site records without needing a large administration department. You can begin with a limited number of projects, a straightforward catalogue, and the roles needed for your current operation.

The practical starting point is usually the problem causing the most work: knowing what is on site, recording returns properly, or keeping scaffold handovers and inspections organised.

Yes. CloudScaff supports multiple yards and site-level stock visibility. This helps teams understand which location holds equipment, where it has been issued, and what is moving between locations.

For organisations with independently managed branches or separate business entities, the account structure also needs attention. Discuss whether you need several yards within one operation, separate branch accounts, or an arrangement that gives selected managers access across accounts.

A spreadsheet can record a balance, but keeping it aligned with deliveries, transfers, returns, signatures, and site records often requires repeated manual updates. CloudScaff connects those operational actions to the records your team uses each day.

For example, an authorised return can update the site balance and the relevant stock condition records while preserving the return document. Accuracy still depends on recording the correct quantities and completing the workflow.

That depends on what your existing software does. CloudScaff focuses on inventory control and scaffold and site operations. Many businesses also need accounting, engineering design, estimating, payroll, or specialised scheduling systems.

Start by mapping the work each system must own. Then assess whether CloudScaff will replace a manual process, exchange information with an existing application, or operate alongside it. This avoids assuming that every business function is part of the same product.

Prepare your inventory list, yard or storage locations, active projects, opening quantities, and the names of the people who will use the system. Existing delivery notes, return forms, scaffold registers, and inspection checklists are also useful.

Choose someone internally who understands the operation and can make decisions about item names, stock balances, permissions, and workflows. That person can help resolve questions during setup and support the team after training.

Yes. Existing stock lists can be prepared for import instead of typing every item manually. The preparation normally involves mapping your item codes, descriptions, locations, quantities, and other relevant fields to the import format.

An import is only as reliable as the source data. Review duplicate items, inconsistent codes, missing locations, and uncertain quantities before using the imported figures as your operational starting point.

Often, yes. A structured export such as a spreadsheet or CSV can provide the starting point for migration. The important questions are which records are available, what each field means, and whether the quantities represent total stock, yard stock, or stock already on site.

Share a sample export during onboarding. Historical transactions, attachments, and scaffold records may need a different migration approach from the opening inventory catalogue.

Not necessarily. Existing codes can be retained when they identify your equipment consistently. Familiar descriptions can also make it easier for your yard and site teams to find the right components.

Check for codes reused across different items, differences between supplier and internal codes, and duplicates created by older imports. Agree on the correct mapping before migration so the same component is not accidentally created several times.

Start by separating catalogue cleanup from quantity verification. Catalogue cleanup resolves item names, codes, categories, and duplicates. Quantity verification establishes what is physically in each yard and on each site.

CloudScaff onboarding can help prepare the information, but your team needs to confirm which items and counts are correct. Do not carry an unexplained discrepancy into the new system simply because it appears in an old spreadsheet.

Yes. You do not need to wait for every project to finish before introducing CloudScaff. Existing site balances can form part of the opening setup.

Choose a clear starting date and establish what is in each yard and on each active site at that point. Agree how movements around the cutover will be recorded so equipment is not counted twice or missed between the old records and the new system.

A verified opening balance is the strongest starting point. If the current figures are uncertain, a stocktake helps establish what your team can rely on before new movements begin.

The count can be planned around your operation. Some businesses count by yard, equipment category, or site. Keep a record of the count date and any deliveries or returns happening during the count so the final balance has a clear basis.

Existing scaffold information can be reviewed as part of onboarding. Provide the register and identify which scaffolds remain active, their site references, dimensions, dates, and supporting records.

Agree the import scope before rollout. Bringing in a scaffold record does not itself perform a physical inspection, verify its location, or replace a required handover. Your responsible team should validate the live records and complete the appropriate operational steps.

Yes. Setup can include preparing roles, site access, and the inspection and handover templates your team needs. Sharing your current paperwork and explaining who performs each step makes that configuration more useful.

A practical approach is to test the proposed setup with one person from the yard, one from the site, and one from the office. Their feedback helps identify missing permissions or unnecessary steps before wider rollout.

Implementation time depends on the number of yards and projects, the condition of your existing data, the workflows you introduce, and the availability of the people involved.

A clean catalogue and a small pilot need less preparation than a coordinated rollout across several branches. Agree the scope, data responsibilities, training sessions, and go-live criteria at the start so everyone understands what needs to happen before the system becomes the working record.

Yes. A staged rollout can begin with a small set of projects or a specific workflow, such as deliveries and returns. Once the team is comfortable, you can introduce more sites or scaffold management processes.

Define which system is authoritative for each part of the pilot. Running two incomplete records without clear ownership can create confusion, especially when equipment moves between projects that are at different rollout stages.

A coordinated rollout can be planned where the business needs a common start date. This requires agreement on account structure, item naming, opening balances, permissions, training, and how branch-to-branch movements will be handled.

Nominate a central rollout owner and a responsible person at each branch. Test a complete delivery, transfer, and return before the cutover so the shared process is understood across the operation.

Yes. Training can focus on the work each group actually performs. Yard staff may need requests, picking, dispatch, returns, and stock conditions. Site teams may need receipt, transfer, scaffold, and inspection workflows. Administrators may need permissions, setup, and reporting.

Using your own equipment and project examples makes training easier to apply. Include the exceptions your team encounters, such as a partial delivery or a return that arrives without notice.

Your team can use the help centre and contact CloudScaff for further assistance as questions arise. Follow-up sessions can address workflows that become clearer once the system is being used on live work.

Keep a short list of recurring questions, screenshots, and example records. This makes it easier to distinguish a training issue from a setup problem or a workflow that needs adjustment.

Yes. CloudScaff supports desktop and laptop computers running macOS or Windows, and phones and tablets running iOS or Android. This allows office, yard, and site teams to access the same system using different devices.

Choose the device that suits the task. A larger screen is useful for administration and detailed review, while a phone or tablet is useful for accessing records, taking photographs, and completing actions in the field.

Chrome, Firefox, and Safari are listed as supported browsers in the CloudScaff system requirements. Microsoft Edge may work, but is not officially supported in that guidance.

If a page or action behaves unexpectedly, try a supported browser and check the device's internet connection. For a rollout, test the actual browser and device combinations your teams will use. See the system requirements for the current guidance.

CloudScaff requires a stable internet connection for its real-time workflows. Plan to use it with mobile data or a suitable Wi-Fi connection.

If your work includes remote sites, basements, offshore locations, or areas with restricted connectivity, assess that before rollout. Do not rely on an assumed offline capture or automatic later synchronisation process without confirming an appropriate workflow with the CloudScaff team.

No. Authorised users can work from the yard, a project site, or another location using a supported device and an internet connection.

That is particularly useful when the person dispatching material, the person receiving it, and the administrator reviewing the record are in different places. Each person can complete the part of the workflow their role permits without sending the same information through several separate channels.

For ordinary browser-based workflows, the starting point is a supported phone, tablet, or computer with a stable internet connection. A camera and location permissions are useful for workflows involving photographs and geolocation.

Specialised barcode or RFID arrangements may involve additional hardware and configuration. Assess those requirements separately rather than assuming a particular scanner or reader will work with every device and workflow.

Photographs can be attached to relevant operational records. This can help document a load, equipment condition, a scaffold, or a discrepancy that needs review.

Make sure the browser has the necessary camera permissions when using direct capture. Keep the image focused on the issue: a clear photograph of damaged equipment or the loaded truck is usually more useful than a large collection of unrelated images.

Location access supports scaffold geolocation. When completing the relevant site workflow, the device can provide a position that helps identify where the scaffold is situated.

Check the recorded location and use clear scaffold descriptions and photographs as supporting context. Device location is a practical aid to finding a record; it should not be treated as a survey measurement or assumed to identify a specific floor inside a building.

The most useful setup gives each person a small, clear set of actions relevant to their job. For example, a site user may only need to request material and receive a delivery, while the stock controller handles the wider inventory process.

Start training with real tasks and familiar component names. Avoid giving every user every tool simply because it is available. A straightforward role and an agreed process make the system easier to adopt.

CloudScaff includes unlimited users. You can give the people involved in your operation their own access instead of restricting participation to a small number of office accounts.

Access is still controlled through permissions and site assignments. An unlimited-user model does not mean every person sees the same information or has authority to approve inventory movements, change records, or administer the account.

Yes. Roles control the functions and actions available to users. You can configure access around responsibilities such as administration, inventory control, site supervision, inspections, or customer visibility.

Decide who may view, create, update, submit, approve, or complete each relevant workflow. That helps the system reflect the way responsibility is divided in your business instead of relying on informal instructions about which buttons people should avoid.

Yes. Site access can be limited to the projects assigned to a user. A person working on one job does not need to see every project in the business.

This is useful for both internal teams and external users. Check the user's role as well as the site assignment, because project visibility and permission to perform an action are separate parts of the setup.

Yes. The role builder allows you to configure permissions around your responsibilities and job titles. You might create roles for a leading hand, yard controller, operations manager, inspector, or customer representative.

Test each role using a representative user before assigning it widely. Confirm that the person can complete the intended workflow and that they cannot access unrelated functions or projects.

Yes. You can provide viewing access while withholding the permissions required to edit or complete actions. This is useful when a manager, customer, or contractor needs visibility but does not own the underlying workflow.

For example, a customer might need to see a scaffold register or project inventory without being able to change stock balances or dismantle a scaffold record.

Yes. Customer access can be configured so customers see the projects and information you choose to share. This can reduce repeated requests for documents or updates that are already recorded in the system.

Decide what the customer needs to do before creating the role. Viewing a register, reviewing site inventory, and signing a handover are different requirements and should be configured deliberately.

Yes. Permissions can limit users to the tools relevant to their responsibilities. An inspector does not need broad inventory administration access simply to work with scaffold records.

The same principle applies in reverse: yard staff can focus on inventory workflows without needing to manage inspections. This keeps the working interface more relevant and reduces the chance of unrelated changes.

Yes. Configure roles so that the appropriate people control approval and completion actions. A site user can have a request-focused role while an inventory controller manages the subsequent stock process.

Use particular care with immediate-completion actions and balance adjustments. The person performing those actions should understand when stock becomes recorded as delivered, returned, or available again.

Yes. Roles and user access can be updated as responsibilities change or additional workflows are introduced.

Review permissions when someone changes position, leaves a project, or no longer needs customer access. After a change, check a representative workflow from that user's perspective so the new access is both sufficient and appropriately limited.

Use individual accounts wherever practical. A shared login makes it harder to distinguish who performed an action and can weaken the usefulness of the operational record.

Because CloudScaff includes unlimited users, each participant can have access suited to their responsibilities. If several people use a shared device, establish a clear sign-in process so activity is recorded under the appropriate person.

The catalogue identifies equipment through information such as its code, description, category, and associated stock locations. Relevant item data can also support weights and operational cost reporting where configured.

Choose descriptions that distinguish similar components clearly. A component's size, type, and scaffold system may be more useful to the team than a supplier description that only office staff recognise.

Yes. Your catalogue can include different scaffold systems and equipment families. Clear item codes, descriptions, and categories help users select the correct component.

For example, keep a ledger from one system distinct from a similarly sized ledger from another. The system can organise the records, but your catalogue should reflect the distinctions your team needs when requesting, picking, and returning equipment.

Yes. Categories help organise equipment into useful groups so teams can find and work with related items. These may reflect component families, scaffold systems, or another structure that fits your operation.

Agree a consistent approach during setup. Too many overlapping categories can make searches and reports harder to interpret, while a simple structure can help teams work more quickly with a large catalogue.

Inventory workflows support finding components through the identifying information in your catalogue. Keeping names and codes consistent makes this much more effective.

If crews use one name and the office uses another, agree how the catalogue should present the item before rollout. Familiar terminology reduces the chance of choosing the wrong size or creating duplicate records for the same equipment.

Yes. Total stock and stock available to issue answer different questions. Equipment may be recorded in your operation but already allocated to a site, reserved, moving between locations, or held out of service.

When planning a delivery, use the appropriate available balance for the source location rather than assuming the total quantity is ready to load. Review the other stock states if the available amount is lower than expected.

Available stock is equipment recorded as ready to issue rather than already allocated, reserved, in transit, or held in an unavailable condition.

The available figure is useful for day-to-day decisions about what the yard can supply. Its reliability depends on recording movements and condition changes correctly, including returns that have physically arrived but still need to be processed.

Reserved stock is set aside for planned work. In-use stock has been issued to a site. Keeping these states separate helps explain why equipment may not be available even though it has not yet left the yard.

For example, a picked order waiting to be dispatched should not be treated in the same way as unallocated stock. Confirm which stage of your workflow reserves the equipment and who can change that allocation.

Yes. Inventory visibility can show the locations and quantities associated with a component, helping you understand what is in yards and what is allocated to sites.

This is useful when a yard is short of a particular item. You can investigate whether it is available elsewhere, still needed on a project, or expected back. Physical redistribution should then be recorded using the appropriate movement workflow.

Yes. Each site has an inventory view that reflects its recorded deliveries, returns, and transfers. This helps the site and office understand what equipment is still allocated to the project.

A site balance describes recorded stock on the project; it does not, by itself, confirm that every component is currently built into a scaffold. Keep that distinction in mind when comparing site inventory with scaffold activity.

Stock balances update through completed system workflows such as deliveries, returns, transfers, and authorised adjustments. This reduces the need to edit several separate records after each movement.

The system does not detect an unrecorded physical movement by itself. If equipment leaves a site without a transfer being entered, the displayed balance will not reflect that event until the record is corrected.

CloudScaff includes low-stock alert controls. These can help your team identify components that need attention before a shortage disrupts planned work.

Set thresholds around how the equipment is used, rather than applying the same threshold to every item. Review both availability and outstanding demand when deciding whether to purchase, cross-hire, transfer, or recover stock from a site.

CloudScaff includes controls for allowing or disallowing transactions that would create negative quantities. The appropriate setting depends on how strictly your business wants to control recorded availability.

Allowing a negative balance does not resolve a stock discrepancy. If negatives are permitted, establish who investigates them and how the missing delivery, opening balance, or other underlying issue will be corrected.

Component weights can support inventory and movement information when the relevant item data is populated. Accurate weights are useful when reviewing quantities and preparing material movements.

Check the unit and value in the catalogue before relying on a calculated total. A missing or incorrect component weight will affect the result. Treat operational weight information as an input to your normal loading checks, rather than an automatic approval of a vehicle load.

A uniquely identified item can be represented separately in the catalogue, allowing its quantity and movement history to be followed independently. This is different from treating hundreds of identical components as one pooled stock line.

Agree the naming and identification approach before setup. If you require a dedicated serial-number lifecycle with service schedules or certificates, demonstrate that requirement separately so the proposed workflow can be checked in detail.

An authorised site user creates a material request for the relevant project and selects the components and quantities needed. Supporting notes or information can help the yard understand the requirement.

The inventory team then reviews the request and processes the supply. This creates a clearer handoff than a material list spread across messages, while keeping the site request distinct from what is ultimately picked and delivered.

Yes. The inventory team can create an order or delivery directly where that matches your workflow. A site request is useful when the field team initiates the need, but it is not the only starting point.

For example, the office may already have an approved material list. The responsible user can select the destination site, source stock, and quantities, then complete the appropriate dispatch steps.

The request can be reviewed before dispatch so the delivery reflects the equipment that should actually be supplied. This is useful when a request contains an error, the site changes its needs, or stock availability requires a different fulfilment plan.

Keep the reason for a material change clear. Requested, ordered, and delivered quantities should not be treated as interchangeable when reviewing what happened on the job.

A request can identify demand even when the required equipment is not currently available. The inventory team can then decide how the requirement will be fulfilled.

That may involve waiting for stock, moving equipment from another location, arranging supplier stock, or agreeing a revised requirement. Recording demand does not mean the item has been reserved, purchased, or physically supplied.

Yes. Material lists can be prepared for the supported import workflow using mapped component identifiers and quantities. This is useful for larger lists produced in spreadsheets or exported from design and planning tools.

The mapping must identify the correct CloudScaff item and source location. Review unmatched components, duplicate codes, and quantities before dispatch. Uploading a list saves entry time, but it does not remove the need to check the order.

A structured material export can be mapped to the CloudScaff catalogue for import into the inventory workflow. The practical work is matching the design software's item references to your equipment records and the relevant yards.

This is a file-based workflow unless a separate integration has been agreed. It should not be assumed to provide automatic design synchronisation or to generate an engineered scaffold from the imported list.

Yes. Pick lists help the yard identify the equipment needed for an order. They are useful when the picking team works from paper while an authorised user manages the digital transaction.

Check that the list reflects the correct order and source location. If the load changes during picking, update the delivery quantities so the final movement record matches what actually leaves the yard.

Yes. Stock can be placed on reserve as part of preparing an order. This helps distinguish equipment committed to planned work from stock available for another job.

Agree when your team should reserve items and when reservations should be reviewed. An old or abandoned order can make equipment appear unavailable until its allocation is resolved.

Yes. Delivery preparation can account for equipment coming from different source locations. This is useful when the required quantity is spread across yards or a delivery combines your stock with supplier stock.

Review the source for each line rather than assuming all equipment comes from the same place. The source information is important later when investigating balances, returns, and ownership.

Yes. You can record the quantity being delivered now while keeping visibility of the remaining requirement. This suits situations where only part of the order is available or fits on the vehicle.

For example, an order for 100 units may be delivered as 60 units first and 40 later. The important point is to record each actual delivery against the outstanding requirement rather than marking the full order as supplied at the first dispatch.

Outstanding quantities remain part of the order fulfilment process so the team can see what still needs to be supplied. CloudScaff supports split deliveries and delivery from backorders.

Review these outstanding requirements regularly. If the customer no longer needs the balance, resolve the order accordingly; if it is still required, use the remaining quantity to plan the next supply rather than relying on a separate reminder.

Yes. Split deliveries can reflect successive loads against the same underlying requirement. Record the quantity carried on each load so the delivery history explains how the order was fulfilled.

This is especially useful when the truck capacity, stock availability, or site programme prevents a single delivery. Avoid recording the total order quantity as dispatched when only the first vehicle has left.

Movement records can include supporting details such as references, notes, and transport information. These help your team identify the load and connect the operational record to existing paperwork.

Use a consistent convention for references such as a purchase order, dispatch ticket, or container number. Agree which fields carry those details so people can find the same information when investigating a delivery later.

Yes. Supporting files can be attached to delivery records. A load photograph, signed paper ticket, or relevant document can provide useful context when a quantity or condition is questioned.

The attachment should support the structured record. If a paper ticket shows a different quantity from the system, resolve that difference rather than leaving two conflicting versions of the delivery without explanation.

CloudScaff supports a workflow in which material is released and the receiving team acknowledges it. There is also an immediate-completion workflow for operations that do not require a separate receipt step.

Choose the process that matches your actual responsibility and evidence requirements, and restrict the relevant permissions. A delivery completed by the dispatching team is not the same evidence as a separate acknowledgment from the site recipient.

Agree in advance who may acknowledge an unattended delivery and what evidence your business requires. The configured process may involve later receipt by the site or an authorised immediate-completion workflow.

Keep the record truthful about who performed the action. Do not record an absent customer or site representative as having signed. Photographs, notes, and the transport record can help document what physically happened.

Complete the dispatch action at the point defined by your agreed operational process, when the recorded quantities represent the actual material being released. Reserving or picking equipment is different from sending it.

This distinction matters because a movement action can change the inventory state and what other users see. Train the team to avoid completing a delivery simply because the pick list has been prepared.

Yes. The order and delivery workflow helps distinguish the original requirement from the quantities actually supplied and those still outstanding.

This is useful when a project reports that material is missing. Review the request, any agreed changes, the dispatched quantities, and receipt information together. That makes it easier to determine whether the issue is a backorder, a picking difference, a receipt discrepancy, or a changed requirement.

Yes. Site-to-site transfers let you record equipment moving from one project to another without routing it through the yard in the system.

The transfer should identify the sending site, receiving site, components, and quantities. Completing the appropriate handoff keeps both site balances aligned with the recorded movement and provides a trail if a later return needs investigation.

The transfer process can begin from the operational need to move equipment, including a move initiated by the sending side. Configure the process around who is authorised to create and complete the transfer.

Even when the receiving site did not request it, the movement still needs a clear destination and an accurate quantity. Avoid treating informal borrowing as an exception that never reaches the stock records.

Yes. Transfer workflows can include the receiving side of the handoff. This helps distinguish equipment intended for another site from equipment actually accepted there.

Train both ends of the process. If a transfer is created but not completed, review its status before assuming the stock is available at the destination or missing from the origin.

Yes. Yard-to-yard transfers record stock moving between storage locations. This helps each yard retain a meaningful local balance while supporting a wider view of the operation.

Use the transfer process for a real movement. Simply increasing one yard and decreasing another through unrelated edits can make the physical handoff harder to trace later.

Yes. Stock can be viewed by location so the team can distinguish local availability from equipment held elsewhere in the business.

This matters when head office sees a large overall quantity but a particular branch cannot fulfil an order. The location-level view helps identify whether the solution is a transfer, a return from site, or a new supply arrangement.

Yes. A project can receive stock from multiple source locations. Maintaining the source detail helps your team understand how the site was supplied and investigate later returns or discrepancies.

For mixed loads, check the component and source combinations carefully. Two identical-looking items may still need to remain distinguishable in the records because they came from different yards or suppliers.

Yes. CloudScaff supports cross-hired supplier stock. This helps you track third-party equipment alongside your own stock while retaining the supplier context.

Set up the supplier and item records carefully so equipment is not mistaken for company-owned inventory. Your team should be able to identify what came from the supplier, where it was allocated, and what still needs to be returned or reconciled.

Yes. A delivery can be prepared using the relevant stock sources. This supports jobs where part of the requirement comes from your yard and the remainder is supplied through cross-hire.

Keep the source and quantities accurate on each line. The distinction is useful when returning equipment and reviewing supplier exposure, even when the components serve the same purpose on site.

Supplier equipment can be represented in the catalogue and associated with the appropriate source. You do not need to treat it as company-owned stock simply because it is needed on a project.

Confirm the item details and ownership context during setup. If several suppliers use different names or codes for similar equipment, agree how those differences will be represented before creating movements.

No. Multiple yards are storage locations within an operation. Separate branch accounts may be appropriate where branches need independently managed data or account access.

Discuss the structure before migration. Consider shared stock, cross-branch transfers, user access, reporting, and commercial requirements. An account-switching arrangement should not be assumed to provide every form of consolidated group reporting without checking the intended report.

Create a return against the originating site and record the equipment coming back. The return can follow a site-initiated collection process or be handled by the yard when the load arrives, depending on your agreed workflow.

Check the quantities and allocate items to the appropriate condition before completing the process. Serviceable equipment, material needing maintenance, damaged items, and unexplained extras should not all be treated as immediately available stock.

No. CloudScaff supports a yard-led return process for operations where equipment is collected or arrives without a formal site request.

The yard still needs to identify the source site and record what was actually received. This is useful when the first reliable count happens during unloading rather than before the truck leaves the project.

A structured return workflow can include arranging the collection and recording the release and receipt of the equipment. This gives the site and yard a clearer view of where the return is in the process.

Recording a collection date or transport detail is not the same as a complete fleet scheduling system. If you need route planning, driver allocation, or a dispatch calendar, include those requirements in your product review.

Yes. Returns can be partial. Record only the quantities coming back, leaving the remaining stock allocated to the site.

This suits phased dismantles, surplus equipment collections, and projects that remain active after some material is recovered. Check the residual balance afterwards so the team understands what is still expected to be on the project.

Yes. Equipment can return over multiple loads or at different stages of a project. Each return contributes to the site's recorded movement history.

Use the actual quantities for each load and avoid re-entering a previous return. At project closeout, review the remaining site balance along with unresolved transfers, losses, and over-returns rather than assuming the last truck cleared every item.

Yes. The yard-led workflow supports recording and checking returned equipment at the yard. Your team can use the return record and supporting count information to establish the final quantities.

Keep unverified counts distinct from the completed return. Completing the process before sorting and checking the load can make equipment appear available even though the quantities or condition have not been confirmed.

An over-return occurs when the quantity coming back exceeds the quantity recorded against the site, or when an item is returned that the site was not recorded as holding.

For example, a site may be recorded as holding 10 units but return 11. That extra unit needs review because it may represent an unrecorded transfer, an earlier count error, supplier equipment, or another issue rather than a genuine increase in owned stock.

Extra quantities can be recorded through the over-return workflow for review. An authorised person can investigate the source and determine how the exception should be resolved.

This separates ordinary return processing from a decision that may change overall stock. Keep notes and supporting evidence where useful so the reason for accepting, correcting, or otherwise resolving the extra quantity remains understandable later.

Investigate whether the equipment was moved between sites without a recorded transfer or whether the return was assigned to the wrong project. Compare the relevant delivery, transfer, and return records before changing balances.

Do not automatically increase stock because one site appears to have returned extra equipment. If it remains recorded on another site, accepting the extra as new stock could leave the business counting the same equipment twice.

Record it as an exception for review rather than forcing it into an unrelated line item. The return workflow can account for components that were not part of the site's recorded inventory.

Check the item's identity and ownership before accepting it into available stock. It may belong to another supplier, have been transferred informally, or result from a resized component that needs a different reconciliation treatment.

Yes. Supporting count sheets and photographs can provide evidence for the quantities entered during return processing.

Use the attachment to explain the final record, not as a substitute for entering the actual quantities. If the count changes during checking, make sure the approved return and the retained evidence tell a consistent story.

Review the difference before treating it as loss or new stock. The cause might be a partial return, a pending transfer, a count error, damage, or an over-return.

Record the quantity actually returned and use the appropriate process for any remaining exception. This keeps the site balance meaningful and makes it easier to distinguish equipment still on the project from equipment that has genuinely become unaccounted for.

Review the site's inventory balance together with its movement history. Deliveries and incoming transfers add equipment to the site's record; completed returns and outgoing transfers account for material leaving it, with other adjustments handled through their relevant workflows.

If the remaining quantity seems wrong, trace the underlying records. A pending or unrecorded movement can explain a difference that would otherwise look like missing equipment.

Yes. Site inventory, return records, transfers, and exception information give you a basis for checking what has been accounted for and what remains unresolved.

Before closing a project, review outstanding equipment and incomplete movements. Document how any damage, loss, supplier stock, or over-return was resolved. Closing the project should be the result of that review, not a substitute for reconciling it.

Yes. Stock condition records help distinguish equipment that is ready for use from material that has been damaged or needs attention.

This matters during return processing. An item can be physically back in the yard without being fit to issue to the next job. Allocate it to the appropriate condition so the available balance does not overstate what the team can safely supply.

Maintenance identifies equipment being held for work such as checking, cleaning, repair, or refurbishment before it can return to service. Damaged stock identifies equipment recorded as damaged and requiring the appropriate assessment or disposal decision.

Agree consistent definitions within your business. Otherwise, different yards may classify the same condition differently, making stock availability and condition reports difficult to compare.

Yes. Once the responsible team has completed the required work and accepted the item for use, the relevant stock process can move it back into available inventory.

Record the quantity actually released. A digital status change should reflect the completed physical assessment; it should not be used to imply that an inspection or repair took place when it did not.

Yes. Loss can be recorded in the context of the site or movement being reconciled. This helps the business understand where the discrepancy arose instead of simply reducing a company-wide balance without explanation.

Investigate the movement history first. A late return or an unrecorded transfer may explain the apparent shortage. Keep the reason and supporting information clear when a loss is confirmed.

Condition and movement records can support a review of where equipment was returned damaged or recorded as lost. Reporting is most useful when the team consistently captures the relevant site, quantities, and reason.

Use the records to identify patterns and investigate exceptions. A recorded association with a project provides operational evidence; it does not, by itself, decide contractual responsibility for a charge.

Scrap can be recorded separately from material that remains in service or is awaiting repair. This helps explain why stock has been removed from usable inventory.

Use a consistent authorisation process and retain the reason for the decision. Where an item might still be repaired, the responsible person should resolve that assessment before treating it as a permanent disposal.

Treat this as a change in the equipment being accounted for. The original length should not remain available alongside the new lengths unless both physically exist.

Resized items can be reconciled through the relevant stock adjustment or return process. Record what was removed, what was created, and any waste or loss. Agree the method with your stock controller so cutting does not silently inflate inventory.

Yes. Purchases can be reflected in stock records using the appropriate inventory addition or bulk process. Identify the item and receiving location, and keep a useful reference to the purchase where the workflow supports it.

Adding equipment to inventory is an operational action. If the purchase also needs to be posted to an accounting system, establish that financial workflow separately rather than assuming the stock entry completes it.

Yes. Inventory workflows include recording equipment being sold or removed from stock. This helps the available and total quantities reflect what the business still holds.

Keep the reason and supporting reference clear so a sale is distinguishable from loss, scrap, or a normal delivery to a project. Confirm the related invoicing and accounting process separately.

Yes. Bulk operations support grouped inventory work, reducing the need to process each item separately. They are useful for substantial changes, reconciliations, and other stock administration.

Review the scope carefully before applying a bulk change. Confirm the location, item identities, and meaning of the quantity fields so a large update does not unintentionally replace correct balances or apply a change twice.

Yes. Stock counting and cycle-count workflows can be used to compare physical quantities with the system records and resolve differences.

A cycle count focuses on selected equipment or locations rather than waiting for a full stocktake. For either approach, define the count scope and account for movements taking place while the count is underway.

Use the stock adjustment workflow that provides the reference and supporting record your business needs. Documented bulk adjustments and quicker data updates may retain different levels of supporting context.

For a material correction, record why it is needed and retain the count sheet, source document, or other evidence. A visible new balance is much more useful when someone can also understand how and why it changed.

Check the movement history before changing the number. Review opening quantities, pending deliveries, returns, transfers, supplier allocations, and recent adjustments for the component and location involved.

If a correction is still needed, use the appropriate authorised process and document the reason. Repeatedly editing balances without finding the cause can hide a workflow problem that will continue producing discrepancies.

A scaffold record identifies a structure on a site and brings together its operational details, such as its description, dimensions, dates, handovers, inspections, and related history.

This is different from an inventory line. One record describes the scaffold being managed; inventory records describe quantities of equipment moving through the operation. Clear identifiers help teams connect the physical scaffold to the correct digital record.

The scaffold register gives the team a structured view of the scaffolds associated with a site, including their recorded status and relevant handover and inspection information.

It helps users find a scaffold and review the latest available record without searching through disconnected documents. Keep the register current by completing the relevant lifecycle actions when work takes place on site.

Yes. A site or project can contain multiple scaffold records. This reflects operations where many separate structures exist within one customer location or work area.

Decide how to identify each scaffold so field staff can find the correct record. If you plan to divide a large facility into separate site records for different areas, discuss the effect on project capacity and access before setting it up.

Scaffold records can capture dimensional and working-level information relevant to the structure being recorded. This helps identify the scaffold and supports the information presented in registers and associated documents.

Use consistent units and terminology. Entering dimensions is a recordkeeping step; it should not be assumed to generate an engineered design, verify load capacity, or calculate a complete material take-off.

Clear scaffold references help teams match physical tags, existing registers, and project terminology to the digital record. Review the available identifier and reference fields during setup and agree which one staff should use on site.

Do not assume a particular automatic numbering pattern will reproduce every legacy reference format. If your business requires a sequence by year, branch, customer, or project, confirm that requirement before importing or creating records.

Authorised users can use the wider scaffold logs to review activity across the projects they are permitted to access. Individual sites also provide their own scaffold information.

This helps operations managers monitor the business while allowing site users to focus on their assigned work. The scope a person sees depends on their role and site access.

Yes. Scaffold geolocation helps display where structures are recorded on site. Location can be captured using the relevant device-based workflow.

Use the map alongside scaffold codes, descriptions, and photographs. These supporting details are especially important where structures are close together, stacked across floors, or located in areas where device positioning is less precise.

Do not rely on a map pin alone to identify a scaffold's floor or exact indoor position. Use clear level, area, and scaffold references in the record, supported by photographs or drawings where appropriate.

For complex facilities, agree the site structure before rollout. The goal is that a user standing at the scaffold can identify the correct record without guessing from several nearby map markers.

Supporting drawings or reference images can be attached to relevant records so the team has additional location or configuration context.

A drawing attachment is different from an interactive BIM model or a map overlay. If you require users to place scaffold markers directly onto a drawing or navigate a model, ask for that specific workflow to be demonstrated before planning around it.

Do not assume that entering a scaffold's dimensions generates or deducts a complete component list. Scaffold lifecycle records and site inventory movements are distinct workflows.

If your operation needs equipment allocated to each individual scaffold rather than to the site overall, review that requirement with CloudScaff using a real example. Include erection, modification, dismantle, and reuse of equipment within the same site.

The dismantle process records that lifecycle event and moves the scaffold into the relevant dismantled history. This allows the business to refer back to the structure and its associated records.

Dismantling a scaffold is not the same as returning the components to the yard. If equipment remains on site or moves elsewhere, the corresponding inventory movement must still be recorded through the appropriate workflow.

Yes. An extension can update the planned dismantle timing when the structure remains required. Add useful context so the team understands why the date changed.

Extending a date does not replace an inspection or confirm that the scaffold remains suitable for use. Continue the required inspection and handover process and keep the operational record aligned with the physical scaffold.

Yes. Handover workflows capture the information and sign-off associated with handing over a scaffold. These records can include scaffold details, checklist responses, notes, signatures, and supporting files.

Define who prepares the handover, who checks it, and who is expected to acknowledge it. That makes the digital workflow reflect the responsibilities in your operation.

Yes. Handover templates can be configured around your checklist and terminology. Share the questions, categories, load descriptions, and standard notes you want to use during setup.

Review the resulting form with the people responsible for your scaffold procedures. A template should reflect the checks your team actually needs to perform and should be kept current when those procedures change.

Yes. Inspection forms can be configured to capture the checks and supporting information relevant to your work.

Keep the questions specific enough to produce meaningful records. Agree how users should record a failed check, a non-applicable question, and any required follow-up so the completed inspection is understandable to the next person reviewing it.

Yes. Photographs can support an inspection record by showing a condition, defect, or other observation that needs to be documented.

Use notes to explain what the photograph shows and which part of the scaffold is involved. A photo is more useful when it is linked to a clear finding than when it is uploaded without context.

Yes. CloudScaff supports in-app signatures on supported devices. This allows the relevant person to complete the signing step without requiring a separate paper-only process.

Make sure the record correctly identifies the person signing and the action being acknowledged. Agree your signing responsibilities during setup, particularly where the person preparing the document and the customer accepting it are different people.

Customer participation can be included in the handover process, including controlled access to the relevant project and signing action where configured.

Confirm the customer journey during setup: how they receive the document, how they access the signing step, and what they can see afterwards. Test that experience with an external-user role rather than assuming it behaves the same way as an administrator account.

CloudScaff has its own signing workflow for supported operational documents. A separate signature application is not required simply to use those in-app signing functions.

If your organisation mandates a particular provider, authentication method, or document approval process, raise that requirement during your review. Do not assume that an integration with a named signature provider is included.

Handover and inspection documentation can be viewed and downloaded through the relevant records. This helps with sharing information and retaining copies for a project file.

When distributing a downloaded document, remember that it represents the record at the time it was generated. The live scaffold record is the place to check for later inspections, modifications, or status changes.

Handover documentation can include your company information. Configure and check the relevant business details and templates during setup so generated documents present the correct identity and contact information.

Review a sample document before rollout. If your customer requires a specific layout, logo treatment, or contractual wording, confirm that requirement rather than assuming every aspect of the document design is freely editable.

Yes. Scaffold records and logs provide access to the associated operational history. This helps users review earlier handovers and inspections rather than relying only on the most recent downloaded certificate.

When a scaffold changes, use the appropriate follow-up record so the history remains understandable. The earlier record and the later action should explain the sequence of events.

Record the failed inspection and the relevant findings so its condition is visible to the team. Use notes, photographs, and the appropriate status and follow-up workflow to document the issue.

The responsible people still need to act on the physical site. Updating a digital record does not itself isolate a scaffold or complete remedial work. Follow your site procedures and record the subsequent checks and actions before returning it to use.

Yes. Modification activity can be recorded as part of the scaffold lifecycle, with the relevant updated information and supporting documentation.

A modification should not be reduced to an unexplained change in dimensions. Record what changed and complete the appropriate handover or inspection steps for your process so later users can understand the scaffold's current state and history.

Use the appropriate correction or replacement workflow and retain a clear explanation. A new handover may be needed where a signed record must be superseded.

Do not assume that a completed signature can simply be erased. If the correct action is unclear, contact support with the specific scaffold and document so the correction preserves an understandable record of what happened.

Registers, logs, and notifications help surface relevant scaffold activity and upcoming actions. These give supervisors a place to review what needs attention instead of relying solely on memory.

Check the configuration and recipients for your process. An alert is useful only when the responsible person receives it, understands it, and completes the action. Inspection intervals should follow your applicable procedures and requirements.

No. CloudScaff records the information and decisions entered by the people using it. The scaffold's physical condition must still be assessed by the responsible competent personnel.

Use the software to support current records, accountability, and follow-up. It does not replace engineering judgement, physical inspection, or the controls required on the actual site.

Yes. CloudScaff includes site instruction and task workflows so work can be recorded and followed through within the site context.

Make the instruction or task clear: what needs to happen, which site or scaffold it concerns, and who is responsible. A useful task record helps the next person understand the action without reconstructing an earlier phone call.

Yes. Site workflows include supporting safety records and document storage. This helps teams access relevant information in the same operational context as the work.

Agree which documents belong at site level and which should be attached to a specific scaffold or event. Keep versions and descriptions clear so users can distinguish a current instruction from an older reference document.

QR codes can provide a practical route from a physical location or tag to relevant digital information. In scaffold workflows, this can help people access the register and find the latest available record.

Decide what the code should open and who should be able to use it. A code used for public viewing and a signed-in user's action workflow serve different purposes.

CloudScaff can use a site-register approach in which one QR code opens the relevant register and the user searches for the scaffold identifier. This can avoid printing a new unique code for every structure.

For your rollout, choose the identification method with CloudScaff and make sure the physical scaffold reference is clear. The user must still be able to match the scaffold they are standing beside to the correct record.

A public register view is read-only. Editing, inspecting, or completing another controlled action requires the appropriate system access and permissions.

Keep that distinction clear when giving codes to customers or workers. A convenient viewing route should not be described as the same thing as an authenticated user account with permission to perform operational actions.

A public viewing link should be treated as accessible to anyone who has the link or code. The information it exposes is different from information restricted to a signed-in customer account.

If access must be limited to named people or assigned projects, use the appropriate authenticated access arrangement. Review the actual public view before distributing the code so you know what it shares.

A code that opens a live register provides access to the information currently displayed there. A downloaded PDF or screenshot is a fixed copy from the time it was produced.

This distinction is useful when inspections or scaffold status change. Check that your code opens the intended live record, and train users to identify the correct scaffold before relying on the information shown.

CloudScaff's inventory information describes support for QR, barcode, and RFID-compatible workflows. Bring your existing tag scheme and equipment to the implementation discussion so the intended workflow can be checked.

Compatibility depends on how you identify stock, the devices and readers involved, and what action a scan must perform. Confirm these details before changing labels or purchasing hardware.

Ordinary quantity-based inventory workflows do not require an individual scan of every identical component. Teams can record quantities against catalogue items through requests, deliveries, transfers, and returns.

Choose an identification approach that fits the equipment and environment. A bulk component, a pallet, and a uniquely identified high-value item may need different methods. The process should support reliable counting without creating unnecessary field work.

Keep clear item or scaffold identifiers as part of the wider process so a damaged label does not leave the team unable to find the record. Users should know how to locate the relevant site, register, or component through the system.

Assess label durability against your actual conditions, including weather, abrasion, cleaning, and industrial exposure. Agree a replacement process and test the chosen approach before tagging at scale.

CloudScaff provides reporting and operational logs covering inventory, sites, movements, and scaffold activity. These help answer questions about quantities, locations, outstanding equipment, and the events behind the current records.

Start with the decisions you need to make. A yard manager looking for available stock and an operations manager reviewing site losses need different views, even when both use information from the same underlying workflow.

Many tables, registers, and reports can be exported for further review. This is useful when you need to analyse information in a spreadsheet or provide a project-specific extract.

Confirm that the particular report contains the fields and date range you need. An exported spreadsheet is a snapshot, so refresh it when newer activity matters rather than assuming the file continues to update automatically.

Inventory reporting includes views such as a site matrix, which helps compare equipment quantities across projects. This makes it easier to identify where stock is allocated without opening each site separately.

Use filters and the relevant scope to keep the report readable. Check whether the figures represent current balances or movement over a selected period before interpreting a total.

Site groups and categories can help organise reporting around the way your business operates. Examples include work type, operating area, or another consistent grouping.

Agree those labels early and apply them consistently. If different branches use different labels for the same kind of work, a grouped report may split information that should be reviewed together.

Movement history helps show how a component's recorded quantities changed through deliveries, returns, transfers, and adjustments. This is useful when a balance needs explanation.

Review the transaction details and supporting documents rather than relying only on the final quantity. A component-level history can help identify whether a discrepancy began with an opening balance, a movement, or a later correction.

Operational records can include the associated user, dates, signatures, and history. This supports follow-up when someone needs to understand how an event was recorded.

The usefulness of that information depends on disciplined account use. Individual logins and clear signing responsibilities provide a better record than several people working through one shared account.

Closed project records can remain available for historical reference and reporting. Closing a project is different from deleting its history.

Use this when reviewing an earlier job's movements, documents, or scaffold records. If you have a specific long-term retention or post-cancellation access requirement, confirm the applicable service arrangements separately.

Discuss the question you need to answer and the fields required with CloudScaff. Custom reporting is part of the product's reporting offering, but the desired result depends on the information captured and the scope of the report.

A sample output is useful. Define the date logic, grouping, quantities, and filters so the team can distinguish a new report layout from a requirement for data that is not currently recorded.

They can support that decision by showing current availability, site allocation, and relevant movement or utilisation information. This helps distinguish a genuine fleet shortage from equipment that is underused or overdue to return.

Also consider future demand, lead times, condition, and cross-hire commitments. A current stock report is one input to the decision; it does not automatically know your complete future work programme.

Yes. Delivery, transfer, return, and adjustment records provide a trail for investigating a discrepancy. You can review where the equipment was allocated and what actions were recorded afterwards.

The result depends on complete records and sensible counting practices. CloudScaff helps organise the evidence; it does not physically prevent loss or detect every unrecorded movement.

Movement documents, condition records, photographs, and signatures can provide a clearer factual basis for those discussions. They help explain what was supplied, what came back, and what was recorded at the time.

Keep the underlying records accurate and consistent. Any decision to charge a customer should follow your agreed commercial process and supporting evidence rather than being treated as an automatic consequence of a stock status.

The value depends on your starting process, data quality, and how consistently the team uses the system. Clearer stock visibility and better handoff records can reduce time spent chasing information and investigating unexplained differences.

During a pilot, compare practical measures such as time spent reconciling returns, unresolved stock discrepancies, and the completeness of movement records. Use your own results to assess the benefit to your business.

CloudScaff supports QuickBooks and Xero integrations. The required setup should be checked against the records and finance workflow you need to connect.

Before rollout, agree which data will move, in which direction, and which system remains responsible for each record. See the integration overview and discuss your specific accounting setup with the team.

Custom integrations can be assessed for ERP, customer, reporting, or other operational systems. Start with the business process you want to connect rather than only the name of the application.

Provide examples of the records involved, the required update frequency, and the system that should control each field. Compatibility, implementation work, and support responsibilities need to be agreed for the particular connection.

Project-data synchronisation is a useful integration requirement to discuss. For example, you may want an existing business system to own the project code and customer information while CloudScaff manages the operational work.

Agree which system creates the record, how updates are handled, and what happens when a project is closed. This should be assessed as a defined integration workflow rather than assumed to happen automatically between unrelated systems.

No. A file import moves information from a prepared file at a particular time. An integration is a configured connection between systems, with agreed rules for exchanging data.

An import may be entirely sufficient for an occasional material list. Repeated changes across two systems may justify an integration, but that adds decisions about record ownership, errors, duplicates, and ongoing support.

Relevant cost and rate information can support operational records and reporting where configured. This can be useful when reviewing equipment exposure, damage, loss, or hire-related information.

Agree the meaning of each field before relying on it. A replacement value, selling price, and hire rate serve different purposes. Recording one of those values should not be assumed to calculate every customer-specific charge automatically.

Do not assume that a rate or hire date in an operational record completes the full invoicing process. Billing may also depend on contract rules, minimum periods, partial returns, off-hire dates, discounts, tax, and accounting integration.

Review an actual example invoice with CloudScaff if this is central to your requirements. The demonstration should cover the complete path from operational event to the financial output your business needs.

CloudScaff's scaffold records capture operational information about structures. A record with dimensions and a handover is different from engineering design software that calculates a design and its materials.

If design or automatic material take-off is required, demonstrate that requirement separately. Material lists from another tool can be considered for import, but importing a list does not make CloudScaff responsible for the engineering behind it.

If these functions are essential to your purchase, ask to review the current workflow in detail before committing to a rollout. Task management, operational dates, and historical discussions about additional modules should not be treated as proof of a complete workforce or payroll system.

Bring the rules you need to support, such as shift allocation, overtime, approvals, and payroll export. That allows the team to assess the actual requirement rather than relying on a broad feature label.

CloudScaff can hold transport-related information within material movements, but a delivery record alone does not establish that it covers every dispatch or fleet-management requirement.

If you need a driver calendar, route planning, vehicle capacity rules, live vehicle tracking, or automated job allocation, include those in the demonstration. Decide which system will own transport planning and how the movement records will stay aligned with it.

Yes. Share the problem, the current workaround, and a concrete example of the result you need. That gives the team a useful basis for assessing whether configuration, training, reporting, integration, or product development is the appropriate response.

A discussion about a possible improvement is not a delivery commitment. Where a capability is essential, confirm the agreed scope and current availability before making it a dependency of your rollout.

CloudScaff supports attachments such as images, videos, and PDFs for relevant operational records. These can provide context for a delivery, return, inspection, or handover.

Use a file type and size appropriate to the people opening it, especially on mobile connections. If your workflow depends on a specialist format or very large files, confirm the current limits and viewing behaviour before making it part of the process.

No. An attachment preserves a file as supporting information. An import reads structured data into the relevant system records.

For example, attaching an Excel material list to a delivery does not necessarily populate the delivery quantities. Use the supported import process when you want the items and quantities entered, and use attachments when you want people to view the original reference document.

Use the appropriate site-level storage or documentation area for material that applies across the project. Attach a document to an individual scaffold or movement when it specifically explains that record.

A consistent filing approach makes information easier to find. Use clear names and avoid relying on several differently named copies of the same document spread across unrelated records.

Yes. A team can use generated paperwork for the physical picking or counting task while the responsible user maintains the digital record.

Agree when the quantities are entered and who confirms the final result. A paper-assisted workflow can work well, provided the completed system record reflects the actual movement and the paper does not become a separate, conflicting stock ledger.

Yes. CloudScaff uses notifications and pending-action indicators to help users see relevant activity. Notifications are associated with permissions, responsibilities, and operational events.

Set up the intended recipients and test the actual devices used by the team. Alerts should help someone complete a task; they work best when the team also understands who owns each step of the workflow.

Notification access can be aligned with user roles and responsibilities. This helps keep an inventory controller's alerts different from those needed by a site user or manager.

Review the configuration when roles change. If everyone receives every notification, important actions become harder to identify; if nobody receives the relevant alert, the workflow may stall without being noticed.

Start with the user's role, site access, and the status of the underlying action. Check whether the event has actually reached the stage that should notify that user.

For device notifications, review the relevant browser or device permissions as well. If the issue continues, provide support with the user, project, action, and approximate time so the specific event can be investigated.

Yes. CloudScaff includes in-app chat to support communication around operational work.

Use conversation to clarify a question, but complete the formal action where it belongs. A chat message saying that equipment moved should not replace the transfer record, just as a message about an inspection should not substitute for the inspection record itself.

The users may have different roles, permissions, site assignments, or access to the relevant workflow stage. An administrator commonly sees more functions than a site user.

Check the intended responsibility before changing access. If the person should perform the action, review the specific permission and site assignment. Avoid granting broad administration access merely to make one missing button appear.

Check the record list and its current status before repeating the action. An operation may have completed even if the screen response was delayed.

Confirm your connection and review the relevant history where available. If the outcome remains unclear, contact support with the record details rather than repeatedly submitting a movement and risking a duplicate transaction.

Provide the project or site, the affected document or item reference, what you were trying to do, what happened, and approximately when it occurred. A screenshot of the issue and the device and browser used can also help.

For a stock discrepancy, include the expected quantity and the movement you believe should explain it. Avoid sending passwords or unrelated sensitive information in a support message.

The CloudScaff help centre contains product guidance, including system requirements and workflow documentation. It is a useful first stop when a user needs to understand a routine action.

If the instructions do not match your account or the problem concerns a specific transaction, contact the CloudScaff team with the relevant details. Live examples make a support conversation more productive.

Further training can be discussed as your team grows or responsibilities change. Use the employee's actual role as the starting point so the session covers the work they will perform.

For internal consistency, keep your own operating decisions clear too: who approves requests, when a delivery is sent, who counts returns, and how discrepancies are escalated. Product training and company procedure should reinforce each other.

The project workflow allows a closed site to be reopened when work resumes. Review its existing records and current stock position before creating new movements.

Reopening also needs to fit your active project capacity. If work has changed substantially, decide whether it belongs to the original job or should be represented as a separate project before entering transactions.

Confirm the current storage allowance and any file-size limits for your account with CloudScaff. Your requirements will depend on the number of attachments, the kinds of files, and how long you need to retain them.

During evaluation, use realistic photographs and documents. A process based mainly on compact PDFs and a few clear images has different storage and upload needs from one that regularly captures long videos.

Yes. Include your IT requirements in the evaluation so the team can review the proposed access and deployment arrangements before users are onboarded.

Bring specific requirements for identity providers, authentication, hosting location, backups, data retention, exports, and contractual commitments. Those details should be confirmed against the current service arrangements rather than inferred from the fact that the application is cloud-based.

CloudScaff pricing is based on active project capacity, with unlimited users. Choose the capacity that fits the number of projects you need to manage at the same time.

The pricing page lists the current plans and billing options. It is the best reference for current amounts, rather than a price quoted in an older demonstration or recording.

Yes. The current pricing page lists a free plan for up to three active projects. This provides a starting point for evaluating the system with a small number of jobs.

Use the evaluation to test complete workflows, including returns and exceptions, rather than only creating sample inventory. Confirm the current plan terms on the pricing page when you sign up.

An active project is a site or job record that remains open for ongoing work in the system. Project capacity is about the work you keep active, rather than the lifetime number of jobs your business has completed.

Agree how your real operation will be represented. One facility may contain multiple scaffold records, while separately managed work areas may be set up as separate projects with implications for capacity.

Not necessarily. A project can contain several scaffold records, so counting individual structures does not automatically tell you which project plan you need.

Review your intended site structure during the demonstration. If you divide a facility into separate project records for floors, areas, or teams, use that actual configuration when estimating the capacity required.

You can close a genuinely completed project to free capacity or move to a plan with more active projects. The current pricing page describes these options.

Before closing a job, resolve its outstanding operational work and inventory. Do not close an ongoing project solely to create room if your team still needs to transact against it.

Closing a project is intended to preserve its historical records for reference while removing it from active work. Your team can review past project information without keeping every completed job active.

This is separate from account cancellation or a contractual data-retention requirement. If either matters to your business, confirm the relevant terms and export arrangements before making a decision.

CloudScaff's published model includes unlimited users rather than a per-user charge. Plan selection is based on the active project capacity required.

Check the current commercial scope for any separately scoped implementation or integration work. Unlimited users describes user access; it should not be read as an unlimited commitment to every possible custom development request.

The pricing page lists monthly, yearly, and three-year billing options. Review the current offer and terms when choosing a billing period.

For questions about upgrades, downgrades, renewal, cancellation, or a particular payment method, confirm the arrangement with CloudScaff before purchase. Those details should follow your actual subscription terms.

Yes. A useful demonstration starts with how your business requests equipment, dispatches it, manages it on site, and accounts for its return. Include scaffold documentation if that is part of your requirement.

Bring a sample stock list, material request, delivery note, return sheet, or handover form. Real examples make it easier to check fit and identify setup requirements than a purely generic walkthrough.

Test a complete working cycle with representative equipment and users: a request, a partial delivery, receipt, a site transfer, and a return with a discrepancy or damaged item. Then check the resulting balances and documents.

If scaffold management matters, also create a scaffold, complete a handover and inspection, record a change, and review the dismantle history. Test customer access and exports using the actual roles your team will use.

Compare the workflows that cause the most work or risk in your operation. Look at how each system handles incomplete deliveries, site transfers, returns, supplier stock, stock adjustments, and the evidence behind each balance.

Also assess field usability, data migration, permissions, reporting, and the systems that must remain connected. Use the same real examples in each demonstration so the comparison is based on your operating requirements.

Start with the CloudScaff pricing page to review the available plans, or use the CloudScaff website to arrange a demonstration.

Tell the team what you manage, how many projects and yards you operate, and where your current process becomes difficult. From there, you can agree the data, configuration, and training needed for a useful first rollout.