Vehicles and fleet in automotive

Central management and reuse of object information

Objects are stored permanently in the system and serve as the central data basis for all protocol occasions. All relevant information for an object is stored in a structured way and is automatically available for future protocols. This significantly reduces data entry effort and recurring documentation can be created efficiently.

Object search and structured display

The Protocol provides various ways to find and organise objects quickly:

• Global object search for quick identification of a specific object
• Display of all objects in an overview
• Filter by address for location-based organisation
• Filter by object type for structured management of different object categories

These functions enable quick navigation within large object inventories.

Direct creation of appointments and protocols

New processes can be started directly from an object:

• Appointment creation for planned inspections or documentation
• Protocol creation for handovers, returns or inspections

All data stored in the object is automatically available and does not need to be entered again.

Automatic data transfer from protocols

Information captured during protocol creation can be automatically added to or updated in the object. These include for example:

• new equipment entries
• added metering devices
• newly recorded vehicle keys and PINs
• updated object information

This simplifies ongoing maintenance of the object structure and improves data quality over time.

Protocol history of an object

A complete history of all associated protocols is displayed for each object. This allows past documentation, condition changes and inspections to be traced transparently.

Object copy for quick object creation

Existing objects can be duplicated to create new objects with a similar structure quickly. This function is particularly useful for:

• serial objects
• similar units within a building
• standardised systems or machinery

QR code identification

Objects can be assigned a QR code. Scanning the code opens the object directly in the system without having to perform a manual search. This enables particularly quick identification in operational use.

Structure of an object

An object consists of several structured information areas:

• general object data
• contacts and participants
• object areas
• equipment and systems
• documented defects
• metering devices (e.g. meters)
• vehicle keys and access

This structure enables detailed and traceable object management.

Object plans and floor plans

Plan documents such as floor plans or overview plans can be stored for an object. These serve as a visual basis for documenting areas, defects or systems within an object.

Documents and external information

Objects can also be supplemented with stored links, for example to:

• technical instructions
• maintenance notes
• certificates
• external documentation

This information is always available centrally in the object.

Integration of external systems

An object can be assigned an external object ID. This enables integration with external systems via interfaces or webhooks and facilitates data synchronisation between different platforms.

Extended object description

An object can also be supplemented with a Markdown-based description. This is suitable for example for:

• detailed object descriptions
• vehicle descriptions
• internal notes or documentation

Markdown allows structured content such as headings, lists or links to be stored directly in the object.

Managing participants and companies in a structured way

Contacts and companies related to an object can be managed directly within the Protocol and assigned to the relevant protocols. Contacts can be imported quickly from local address books or created directly in the system. This means all relevant participants – such as fleet managers, drivers, dealers, workshops or surveyors – are always available centrally.

Contact search

An integrated search function enables quick finding of persons or companies within the system. Contacts can be selected and assigned directly to an object or protocol.

Roles and participant structure

Each contact can be assigned a role to clearly define their relationship to the object or protocol. Examples include:

• Driver
• Fleet manager
• Dealer / dealership
• Lessee
• Fleet coordinator
• Workshop / surveyor

The role structure simplifies the organisation of participants and ensures clear assignment within the documentation.

Visibility of contact data

Visibility settings can be defined for each contact. This determines which information is displayed within a protocol:

• Address
• Email address
• Phone number

This allows personal data to be protected or only partially visible as required.

Address completion

When capturing contacts, the Protocol supports automatic address completion. This enables addresses to be entered quickly and without errors while ensuring a consistent data structure.

Deleting contacts

When removing a contact, it can optionally be specified whether all protocols linked to this contact should also be deleted. This function enables consistent data cleansing and supports data protection requirements.

Documentation of devices, equipment and technical systems

The Protocol enables structured capture and management of an object's equipment, inventory and technical systems. All relevant information – from photos and receipts to product details and warranty data – can be stored in one place. This creates a complete and traceable long-term record of the equipment on site.

Assignment to object or areas

Equipment and inventory entries can be assigned either to the entire object or to specific object areas. This allows devices, furniture or technical systems to be precisely located and managed in a structured way.

Storing receipts and documents

Relevant documents can be stored for each equipment item, for example:

• Purchase receipts
• Warranty certificates
• Invoices
• Maintenance records

These documents are always available centrally and simplify handling warranty claims or maintenance processes.

Product information and instructions

A precise product designation can be stored for each inventory item. In addition, a direct link to operating instructions or technical documentation can be stored.

This allows users to access important information quickly without having to search through external documents.

Warranty and guarantee information

The Protocol allows warranty or guarantee periods to be stored for each equipment item. This makes it possible to see at any time whether a device is still within its guarantee period.

This information supports efficient management of repairs, replacement procurement or maintenance measures.

Structured subdivision of an object

Objects can be subdivided into individual vehicle areas (paint, interior, tech) to enable detailed and clear documentation. Each area forms its own structure within the object and can be linked to checklists, equipment entries and documented defects. This allows conditions, systems or inventory to be assigned precisely to a spatial context.

Permanently stored area images

Permanently stored images (Store Images) can be added to each area. These serve as a visual reference and can contain for example:

• Floor plans or plan sections
• Technical systems
• Installation overviews
• Photos for orientation within the object

These images are automatically available for every future protocol creation.

Free designation and grouping

The designation of an area can be defined freely. In addition, areas can be structured in groups to organise larger objects clearly – for example by floor, building section or functional area.

Area description with Markdown

A detailed description can be stored for each area. This description supports Markdown formatting, allowing structured content such as headings, lists or notes to be stored directly in the area.

This is suitable for example for:

• Technical notes
• Usage notes
• Maintenance information
• Internal documentation

Positioning on the object plan

Areas can be positioned within a stored object plan or floor plan. This enables visual assignment within the building and allows areas to be identified quickly.

Visibility in the protocol

The visibility of individual areas can be controlled for protocols. Areas can be shown or hidden when creating a protocol.

This allows flexible adaptation of the documentation – for example when only certain parts of an object are to be inspected or documented.

Document damage and track measures in a structured way

The Protocol enables structured capture of defects directly at the object and within individual areas. Each defect is documented with description, media and organisational measures and remains traceable on a permanent basis. This creates a transparent basis for maintenance, responsibilities and subsequent billing.

Assignment to object and area

Defects can be assigned either to the entire object or to individual vehicle areas (paint, interior, tech). This assignment enables precise documentation and makes it easier to find and track damage later.

Permanently stored media

Photos and videos can be stored permanently for each defect. The media are captured once and remain linked to the defect in the long term.

This enables:

• visual documentation of the original condition
• traceability in subsequent inspections
• comparison between original damage and later remediation

Description and automatic capture

The description of a defect can be done in various ways:

• automatic transfer from a checklist
• manual entry
• voice-to-text capture via speech recognition

This allows damage to be documented quickly, even directly during an inspection.

Location on the plan

Defects can be positioned precisely within a stored object plan or floor plan. The marking on the plan enables visual assignment and makes it easier to find the damage within the object.

Assignment of measures

For each defect, it can be defined which party is responsible for rectification. This is done via role assignment, for example:

• Rectification by driver
• Rectification by fleet
• Rectification by service provider

This assignment creates clear responsibilities within the documentation.

Cost coverage

In addition, it can be specified which role covers the cost of rectification, for example:

• Cost coverage by driver
• Cost coverage by fleet

This information is stored directly in the defect and simplifies subsequent billing.

Cost information for billing

The expected or actual amount of damage rectification can be stored for each defect. These costs can later be used in the damage settlement module to represent financial claims transparently.

Prioritisation of measures

Defects can be given priorities. Damage with high priority is displayed prominently on the start page, for example, to enable quick processing.

Documentation of completed measures

Once a defect has been rectified, it can be marked as completed. Completed measures are documented in the protocol under "Remediation – Completed orders".

This means the entire lifecycle of a defect – from identification to rectification – remains fully traceable.

Documentation of odometer and measuring points with reading, photo and date

Meters for electricity, gas, water or other consumption values can be created directly in the object and assigned to a specific area. The current meter reading can be captured quickly in the overview and additionally documented with photo and date, so that the status remains traceable at all times.

• Simple capture of meter reading directly in the overview
• Photo documentation of the meter with timestamp
• Location of the meter in the object for the SelfService system
• Creation of new meters via barcode scanner for unique identification

Documentation of keys and codes with ID and Lost Key Service.

All keys and access options for an object can be fully documented. This records how many keys exist in total and how many were actually handed over at vehicle handover. In addition, it can be confirmed whether spare keys are retained or fully handed over. Each key ID can be captured easily – for example by scanning a code – and uniquely assigned to the object or area.

• Documentation of the number of keys handed over
• Capture of the total number of keys available
• Confirmation of whether spare keys are retained or fully handed over
• Quick capture of key ID via scanner for unique identification 🔑

Lost Key Service

With the Lost Key Service from deep.rent, keys can be assigned simply and uniquely without putting personal contact details on the key itself. For each key, a dedicated QR code can be generated or an existing ID tag can be used. In addition, an email contact is stored to be notified in case of loss.

When the QR code is scanned or the ID is opened via www.deep.rent/lost-key, the finder is taken directly to an input page. There they can leave their contact details and inform the fleet manager about the find. This creates a simple, privacy-friendly way to get lost keys back more quickly.

Central management of addresses for clear assignment of objects

Addresses are captured once in a central place and can then be assigned to multiple objects. This allows buildings, facilities or areas to be structured clearly and reused. Address entry is supported by integration of the Google Maps API, so that addresses can be found quickly, completed automatically and positioned precisely.

• Multiple objects can be assigned to one shared address
• Central management of locations and object addresses
• Address capture with Google Maps API support for quick and precise entry 📍