Ticket Systems in Facility Management: Setting Up Efficient Fault Reporting and Processes

Fragmented fault reports delay responses and drive up costs; central ticket systems create tips, traceability, and lower MTTR. This guide shows which functional requirements and integrations with CAFM, BMS and IoT are necessary, how to design processes with SLA and escalation logic, and which KPIs you should measure. You will receive concrete process templates, implementation steps, and a go-live checklist for practical use.

Why Ticket Systems Deliver Measurable Added Value in Facility Management

Clear result: Ticket systems reduce actual response times and create traceability where emails, phone calls, and paper chaos otherwise dominate. The measurable impact comes not from functions alone, but from consistent processes, clean Master Data , and binding SLA logic.

Operational Effect: A central Ticketing makes response times, processing progress, and responsibilities directly measurable. Without standardized classification and asset references, the system only provides tips to chaos instead of about causes.

Financial Effect: When tickets link cost centers, material consumption, and third-party companies, follow-on costs become visible and accountable. This allows for targeted measures such as contract renegotiation, preventive maintenance, or supplier changes — not cosmetic savings, but real budget control.

Concrete Levers for Measurable Added Value

• Visibility: Automated timestamps for receipt, first response, and completion generate reliable KPIs.
• Verification: Photos, location IDs, and asset master data prevent misassignments and reduce reopenings.
• Escalation: Time-controlled escalation rules ensure that priorities are not dependent on personal relationships.
• Integrations: API-based connections to CAFM and BMS reduce manual duplicate work and speed up billing.

Practical Limitation/Trade-off: A Ticketing-System generates work; initially, ticket volume often increases because previously lost disruptions are documented. This is not Furthermore, the Digital Twin will contribute to enabling digital transformations in companies at a new level. By creating detailed virtual models of physical assets, companies can identify and optimize weaknesses early on. The Digital Twin thus offers the possibility to analyze, simulate, and optimize processes before they are implemented in the real world. This allows companies to reduce costs, increase efficiency, and minimize risks. of The role of helpdesk software for facilities in modern facility management, but an indicator of previously missing transparency. Organizations must plan capacity for the ramp-up or filter logic implement.

Concrete example: In a medium-sized university building, a central system was introduced that records defect reports via an app and automatically assigns janitorial teams. The documentation rate immediately increased, rework was halved, and invoices to specialist companies could be checked monthly instead of quarterly for the first time. The result: faster approval of special measures and less dispute over responsibilities.

Verdict: Ticketing systems are not a panacea. They deliver measurable added value when embedded in a disciplined process and data environment – otherwise, they merely shift the disorder to another register. Before evaluating, check the Master Data and define escalation rules.

Next step: Validate master data and define three typical workflows as test cases before comparing providers. This will allow you to assess the actual added value and integration efforts more realistically. You will find further information on System Selection in our article on CAFM Software and at GEFMA.

Core Functions and Minimum Technical Requirements in FM

Essence: A usable system in facility management must reliably deliver two things: structured, validated disruption reports with a traceable lifecycle and robust, tested integration paths to existing systems. Everything in between is nice-to-have, as long as these two core pillars are stable.

Core Functional Building Blocks

Core functions should specifically operationalize what was previously done manually. This doesn't mean many colorful features, but precise coverage of the following points: structured fields (asset ID, location hierarchy, priority), mandatory proof files (photo/video), traceable status transitions, SLA triggers, chains of responsibility, and an audit log that saves every status change and every communication.

• Ticket Data Model: Mandatory fields for assignment (Asset/Location/CostCenter), flexible free text fields only when they make sense
• Multichannel Input: Web form, mobile app with offline sync, email parsing and standardized IoT-/BMS events
• SLA Engine: rule-based response and resolution times with escalation levels and time-based automation
• Routing & Workflows: rule-based assignment, escalation, vendor handover, and automatic reopening upon deterioration of condition
• Documentation & Proof: Photo uploads, signatures, material consumption, and approval processes for billing
• Permissions: Fine-grained roles, multi-tenancy, and traceable audit logs

Minimum Technical Requirements and Integration Behavior

Technically, FM-suitable ticketing requires more than a web interface. Pay attention to idempotency, versioning of API schemas, event retry logic, and mechanisms for deduplicating events from IoT or BMS. If these are missing, you will produce alarm floods or inconsistent duplicate tickets.

• Essential API Endpoints (Example): POST /tickets, GET /tickets/{id}, PUT /tickets/{id}/status, POST /tickets/{id}/attachments, POST /webhooks/events, GET /assets/{assetId}
• Safety Requirements: OAuth2/OpenID Connect for SSO, TLS for transport, Encryption at rest data and role-based access controls
• Robustness: Webhook retries with exponential backoff, message queue (e.g. MQTT/RabbitMQ) for peak loads, rate limits, and monitoring of integration endpoints
• Operation: Staging and sandbox environments, clear migration paths for schema changes, audit logs with immutable history

Trade-off: Strictly validated forms reduce misassignments but increase the barrier to reporting. In practice, a two-stage approach works: a short reporting form for the initial report plus a mandatory verification step by dispatchers or technicians.

Concrete example: In a hospital-Here is a selection of relevant Psets for FM. I have divided them into categories – perfect for printing and sticking on your monitor. the BMS server generates via POST /webhooks/events an alarm. Ticketing must apply the event dupfilter, map the event to the asset ID, and automatically assign an on-call technician based on a priority rule (e.g., danger to life > failure > comfort). Through this Automation the clinic reduced unnecessary call chains and significantly shortened response times.

Important: Do not accept black-box integrations. Request test sandboxes, example payloads, and retry logs before signing a contract.

Next step: Define concrete API tests, retry scenarios, and a minimal data model in the requirements catalog. Use internal resources such as our tips on System Selection on CAFM-Blog.de and the GEFMAguidelines gefma.de as a reference.

Integration with CAFM, BMS, and IoT: Data Flows and Interface Design

Key takeaway: A robust integration is not a single connection, but an orchestrated system of event handling, master data synchronization, and governance for mapping rules. Without these three levels, inconsistencies, duplicate tickets, and unresolved alarms arise.

Architectural Patterns — When You Need Middleware and When You Don't

In practice, a three-stage pattern has proven effective: Edge (IoT gateway/BMS controller) processes raw signals, Message Broker/Middleware normalizes events and handles deduplication, and Ticketing Engine/CAFM manages assignment, SLA logic, and history. Small installations occasionally get by with direct APIs between BMS and ticketing; however, this quickly becomes unscalable as sensor numbers and the vendor landscape grow.

• Edge Aggregation: Filtering, debouncing, and local thresholds prevent alarm floods before they reach the backend
• Middleware (recommended from 100+ sensors): Responsible for event enrichment (asset ID, location), deduplication, and retry mechanisms
• CAFM/Ticketing: Authoritative source for master data, SLA calculation, and work order logic; only validated events should land here
• Batch sync for master data: Periodic ETL runs for asset master data and cost centers, not just real-time events

Trade-off: Real-time is desirable but adds complexity. If you push every IoT change into ticketing in real-time, you need robust back-off strategies and observability. For many FM workflows, latency of seconds to minutes with clear aggregation logic is sufficient.

Mapping and governance are the actual integration project. Define a small number of mandatory fields, with a unique object ID, location hierarchy, and responsible person. Changes to the mapping must be versioned and tested with contract tests; otherwise, assignments or billing will fail.

Concrete example: In a large office complex, individual HVAC-sensors generated dozens of temperature-related events per hour. The solution was to introduce zonal aggregation in the IoT gateway: only when three sensors in a zone simultaneously report anomalous values, a single ticket with associated sensor IDs and trend values is fed into the ticketing system. This reduced the ticket flood, allowed targeted on-site inspections, and improved response prioritization.

Practical priority: first define simple, authoritative master data rules and event failover behavior. Then build the event pipeline. Those who reverse this order will pay later with manual rework and lost user trust.

Designing Fault Reporting Processes: Roles, Prioritization, SLA and Escalation Logic

Key takeaway: A reliable more reopens, reduced first-time fix rates, and frustration for technicians. only works if roles are clearly defined, priorities are set by the business, and SLA/escalation rules reflect the actual operational rhythm. Technical features without this governance framework only create more work.

Role Model — Not Just Titles, But Powers

Practical rule: Define roles so that the system can make decisions. A role is more than a label; it determines which fields an actor can see, which actions can be automated, and which escalation paths are triggered. Use a short RACI-format (Responsible, Accountable, Consulted, Informed) for every critical workstep transition such as assign, close, reopen.

Limitation/Trade-off: The more granular the roles and permissions, the greater the administrative effort. For medium-sized FM teams, a tiered simplification is recommended: a few operational roles with config flags to activate additional rights (e.g., vendor handover).

Prioritization, SLA Logic, and Escalations — Practice Instead of Theory

Important: Priority must reflect two dimensions: Impact (e.g., safety risk, operational downtime) and Urgency (e.g., remaining lifespan of a system). Translate this combination into measurable SLOs and link them to operating conditions such as shift work or holidays.

Concrete mechanism: Implement calendar-aware SLAs (business hours vs. on-call), SLA splits (first response vs. resolution), and handshake checks during vendor handover. Automatic escalation is effective when it's tiered: first Notify, then Reassign, then Manager Alert. Avoid mass SMS as the primary method – notification fatigue reduces response quality.

Concrete example: In a clinic, a leak in the technical room outside business hours was automatically classified as high-risk. The ticket immediately triggered a push notification to the on-call technician; after 20 minutes without acknowledgment, the system escalated to the shift manager and simultaneously initiated a vendor call. This cascade ensured arrival within the on-call period and prevented secondary damage.

Verdict: Automation is helpful, but not blindly. Always include a human-in-the-loop for edge cases and allow manual overrides with mandatory justification – this prevents persistent false escalations and creates traceability for audits and billing.

Next step: Define specific SLA times, acknowledgment windows, and escalation paths for three typical incident types (safety-critical, operationally relevant, comfort). Validate these rules against live cases during the pilot operation and document changes in the requirements catalog on CAFM Software or orient yourself by the GEFMA's specifications on gefma.de.

Implementation Roadmap: Requirements, Test Operation, and Go-Live Checklist

Brief conclusion: A precisely timed implementation roadmap determines whether a ticketing system project delivers stability in the short term or ends up with manual workarounds after weeks. Focus primarily on three things: clear master data contracts, reproducible end-to-end tests, and a phased cutoverNext practical.

Requirements Validation and Test Operation

Core task in the PoC: Validate not only UI features but also five concrete integration and operational scenarios. Define test data, expected mappings, and acceptance criteria, and automate test execution as much as possible.

1. End-to-end ticket creation: Create tickets via mobile app, email parsing, and POST /webhooks/events all must deliver the same asset assignment.
2. Deduplication test: Multiple, timely events from the same sensor should only create one active ticket or must be clearly grouped.
3. SLA and escalation run: Trigger timers, register acknowledgments, automatic escalation within defined windows.
4. Vendor handover: Handover to external service provider including proof (materials, time) and automatic SLA stop.
5. Migration check: Import old data (assets, locations, cost centers) and perform a 1:1 comparison with a sample (e.g., 100 data records).

Practical Tip: Test operation also means load scenarios: simulate peak loads through BMS/IoT events during the pilot, otherwise, you will only notice scaling problems in live operation. Schedule a support window with the integrator for the pilot phase.

Case study: In a hospital area, an automated scenario was run during the pilot: the BMS sent several temperature alarms; the middleware grouped these into a ticket with trend data, the dispatcher confirmed within the acknowledge window, and the technician received advance material information. Result: during the rollout, unexpected duplicate tickets were avoided, and the vendor handover went smoothly.

Go-Live Checklist and Cutover Strategy

Next practical-Choice: A phased rollout (pilot → staggered expansion) reduces operational risk; a big bang saves time but increases the likelihood of operational disruptions. Choose according to risk appetite and resources — not wishful thinking.

• Technology: Contract tests green, webhook retries visible, integration monitoring active, backup plan for POST /tickets-Furthermore, the Digital Twin will contribute to enabling digital transformations in companies at a new level. By creating detailed virtual models of physical assets, companies can identify and optimize weaknesses early on. The Digital Twin thus offers the possibility to analyze, simulate, and optimize processes before they are implemented in the real world. This allows companies to reduce costs, increase efficiency, and minimize risks..
• data: Master data synchronization completed, mapping versions documented, sample comparison passed.
• Operation: On-call plan for 72 hours, escalation contacts stored, change freeze for core workflows.
• Compliance: DPA signed, deletion deadlines and access concepts documented, GDPR check available.
• Training & Communication: Key users trained, JobAids distributed, internal communication plan with recipients and times for rollout updates.
• Fallback: Clear rollbackcriteria (e.g., >X% failed integration calls) and tested reset script.

Insight and Consideration: Organizations often underestimate the increase in workload immediately after go-live because hidden disruptions become visible. This is not a false start of the The role of helpdesk software for facilities in modern facility management, but the uncovering of latent problems. Reserve capacity for ticket triage in the first few weeks and use the time for fine-tuning prioritization rules.

Next step: Define a concrete set of three live test cases in the pilot area, define metrics for acceptance, and schedule the first review meeting within the first week of operation. For templates and checklists, see our resources on CAFM-Blog.de and the GEFMAguidelines gefma.de.

KPIs, Reporting, and Measures for Continuous Improvement

KPIs must trigger actions, not just fill tables. Measure in such a way that results are immediately operationally usable: who does what, by when, and with what consequences for the budget or Sampling rate and timestamp quality determine whether FDD algorithms or load management function. Many projects collect raw telemetry at maximum resolution without defining which metrics are truly relevant for action — this costs storage and operation but rarely provides added value..

Important Distinction: Separate operational measurable metrics (e.g., technician utilization, recovery intervals) from business metrics (e.g., cost avoidance through preventive maintenance, SLA compliance in customer reporting). Both perspectives require different aggregations and frequencies.

Which KPIs Really Make a Difference

• First-time-fix rate (FTFR): Proportion of tickets resolved on first contact — shows parts availability and skill gaps.
• Backlog age: Age of open tickets by priority — better early warning than cumulative ticket numbers.
• Technician productivity: Tickets per technician per shift combined with travel time share — important for outsourcing decisions.
• Preventive compliance: Percentage of planned maintenance tasks that were completed on time — connects ticketing with maintenance strategy.
• Customer Satisfaction (CSAT) or Reporting Score: Short surveys after completion, concise but informative for customer service software effects.
• MTBF (Mean Time Between Failures): More meaningful for critical assets than mere repair times.

A common Furthermore, the Digital Twin will contribute to enabling digital transformations in companies at a new level. By creating detailed virtual models of physical assets, companies can identify and optimize weaknesses early on. The Digital Twin thus offers the possibility to analyze, simulate, and optimize processes before they are implemented in the real world. This allows companies to reduce costs, increase efficiency, and minimize risks. is the collection of many metrics without accountability. Assign a data owner and an action rule for each KPI: e.g., if backlog age in priority 1 > 24 hours, then trigger incident review and resource increase.

1. Define 4-6 core KPIs and a clear formula for each (source, aggregation, window).
2. Link KPIs to concrete measures (e.g., spare parts pooling, additional shifts, contract points with vendors).
3. Automate exceptions: Weekly report via email + real-time alert for SLA breaches.
4. Conduct monthly root cause analyses (RCA) and maintain a prioritized improvement backlog.

Practical limitation/trade-off: Detailed dashboards create transparency, but increase maintenance effort and susceptibility to errors in master data. Compromise: start with rough, robust indicators and refine the models only after two iterations.

Concrete example: In a mixed-use building complex, the facility team identified through FTFR tracking that missing spare parts were the most common cause for re-work. Consequently, the team introduced pre-kits for common measures and coordinated inventory levels with the vendor; result: fewer callbacks and more stable scheduling for external companies.

Concrete goal for each key figure: a defined action within 48 hours or a documented escalation path.

For templates and concrete dashboard layouts, use our resources for reporting-implementation on CAFM-Blog.de and orient yourself by governance standards such as those of GEFMA.

Next step: Define two KPIs today that you will report automatically in the first 30 days. Simultaneously, set up a monthly review session where KPIs become concrete improvement tasks with responsible persons.

Selection Criteria and Market Examples: Planon, Aareon, IBM Maximo, PlanRadar, and FM:Systems

Essential decision criterion: Not the feature list decides, but how a provider reduces risks in the integration and operational phase. Functionality is important — but integration stability, upgrade capability, and operator support determine the long-term benefit of a ticketing system in FM.

Practice-Oriented Selection Criteria

Evaluate providers based on concrete operands, not generic promises. Three short decision questions that must be included in the tender: 1) Can you provide a sandbox with real CAFM master data and BMS event simulation? 2) Which integration error cases (retries, dedupe, schema changes) are covered in the contract? 3) What do upgrade paths look like after customer-specific customizations?

Concrete example: A German university administration decided on Planon because the close integration with existing CAFM assets and cost centers automated monthly billing. In parallel, the construction department used PlanRadar for defect management during the renovation phase; the implementation time there was significantly shorter and the administration effort lower.

Important: Heavy customization brings short-term benefits, but increases the costs for updates and prevents clean SaaS upgrade paths.

Next step: Define three real workflows (BMS alarm, mobile janitor notification, vendor handover) as test cases and request a live integration test protocol from each provider. Then decide based on integration stability and operating costs — not just feature lists.

Practical Examples and Short Case Studies

Direct Observation: In practice, small, targeted adjustments to processes and routing often achieve a greater effect than upgrading to a feature-heavy ticketing system. Data governance and clear responsibilities are crucial — not the number of modules.

Case Study 1 – Retail Center, Multi-Vendor Routing: A large shopping mall introduced multi-channel ticketing with automatic vendor assignment based on asset and contract data. Result: Vendor response time decreased by around 40 percent and duplicate tickets fell by 30 percent. Limitation: The introduction initially generated significantly more tickets; without dedicated triage resources, suppliers would have reacted with overload.

Case Study 2 – Production Site, Predictive Integration: A manufacturing company connected vibration and temperature sensors via middleware to the ticketing system and grouped anomalies into is not just a buzzword, but an essentialtickets. Unplanned downtimes decreased by approximately 18 percent because teams could proactively replace parts. Trade-off: The adjustment of filter parameters and initial data normalization took several months and consumed time and integration budget.

Case Study 3 – through more efficient resource management and more effective workplace utilization. On the other hand, they can reduce their costs by better utilizing unused resources and adjusting their workplace occupancy rate. The IWMS process also enables companies to respond better to the constantly changing demands of modern workplaces and customer wishes., Self-Service + Mobile Technician: A Property Management bundled tenant requests in a self-service portal, linked to mobile apps for technicians. Billing accuracy increased; billing cycles shortened by a quarter because material and time records were standardized. Limitation: Without a clean cost center hierarchy, allocations remain error-prone.

Practical Insights and Implementation Criteria

Important ruling: Automation is useful, but not a substitute for governance. In all cases, a brief human-in-the-loop acted as a quality filter: dispatchers with clear escalation authority prevented false escalations and reduced vendor conflicts.

• What works quickly: Standardized input masks plus photos significantly reduce repeat reports.
• Budget Reality: Integration costs and tuning for IoT filters log classic CapEx expenditure — factor this into the first 12 months.
• Measurability: Before the rollout, define two operational KPIs per pilot (e.g., vendor response time, reopening rate).

Next Step: Select a pilot with clear, measurable goals and reserve triage capacity – automation without governance often degrades service quality.

Handling Data Protection, GDPR, and Data Retention

Summary: and the information contained therein. is not a side issue when setting up ticketing systems in FM – it determines what data you collect, how long you store it, and how automated workflows are technically designed.

Consequence for practice: Treat tickets as combined transaction and personal data: Contact information, photos with recognizable individuals, location data, and technician logs can each have different legal bases and protection requirements. Plan data protection measures early in Architecture and process design, not as an afterthought.

Concrete Duties and Sensible Measures

The GDPR requires a documented legal basis (e.g., Art. 6). For processing by service providers, you need a legally valid order processing contract (Art. 28). Additionally, a record of processing activities (Art. 30) and, if necessary, a and the information contained therein.data protection impact assessment (DPIA) is necessary, for example, if location or video surveillance data is processed on a large scale.

• Data minimization: Only collect fields that are mandatory for processing, invoicing, or security essential. Optional fields must be clearly marked and deactivatable.
• Pseudonymization instead of complete anonymization: Separate identifiers (e.g., Person ID) from ticket transactions via tokenization; this allows routing without unnecessary insight into personal data.
• Order processing: Request a list of all subcontractors of the provider, define deletion deadlines and audit rights in the AVV (order processing contract) and request proof of compliance (pen test, SOC reports).
• Technical measures: End-to-end-Encryption data at rest, TLS for transport, MFA/SSO for access, role-based access control, and immutable audit logs.
• Processes for data subject rights: Standardized procedures for information, correction, deletion, and data portability; deadlines and responsible persons must be documented.

Trade-off and real-world limitation: Strict anonymization often destroys the ability to assign and bill in FM practice. A modelhas proven effective in practice, where operational data remains pseudonymized in tickets, while a secure, versioned mapping dataset allows for reverse resolution for billing or tracking.

Specific Use Case: In a hospital, a ticketing system was introduced that could record reports with photos. Due to potential patient data, the project team conducted a DPIA beforehand, implemented automatic facial anonymization for uploaded images, and allowed de-anonymization only for authorized case workers with two-stage approval. Result: Security requirements were met without blocking operations.

Another practical problem: Tickets relevant for accounting must be stored longer (e.g., tax retention periods). Align deletion periods so that GDPR deletion requests are consistent with commercial and tax law obligations and document the legal basis for deviations.

My verdict from practical projects: Organizations underestimate the operational friction when data protection rules come into play too late. Insist on technical proof in the PoC (e.g., pseudonymization workflows, data processing agreements, subprocessor disclosure) and plan a short operational window for the first revision of deletion rules — usually in week 4 after go-live, unresolved cross-references between tickets, billing, and compliance become apparent.

Next step: Define two retention profiles in the requirements catalog (operational tickets vs. accounting documents) and ask the provider for a demo on how deletion, export, and de-anonymization are controlled.

Recommended Resources and Templates for Download

Directly usable: The following downloads are not checklists to be filed away and forgotten, but work packages that you can immediately use in PoC, pilot, and operation. Choose templates as a starting point and adapt them to your master data and interface reality.

SLA Template with Priority Matrix and Escalation Levels

Content: Ready-made priority matrix (impact x urgency), acknowledge and resolution times, escalation levels with notification channels, and a brief guide to calibration for on-call times. Use: Quickly deployable document for contract negotiations with service providers and internal SOPs.

Tender Checklist for Ticketing Systems

Content: Specific requirement points (sandbox availability, API error cases, retry mechanisms), test case definitions for E2E scenarios, and formal acceptance criteria. Tip: Copy the test cases 1:1 into your tender instead of general functional requirements.

KPI Dashboard Template and Example Reports

Content: Dashboard layout for facility managers, technician view, and management report, plus example SQL/CSV exports for first response, MTTR, and reopening tracking. Limitation: Dashboards only work with clean asset mapping; plan data quality checks before live operation.

Integration and Test Package (Postman + Example Payloads)

Content: Postman collection with example requests for POST /tickets, POST /webhooks/events, deduplication scenarios, and a JSON mapping template for asset IDs. Practical Benefits: This allows you to conduct reproducible integration tests with providers and integrators — request this collection as a mandatory part of the PoC.

File Formats: The templates are available as editable Excel/CSV templates for master data, Word/PDF for policy-Documents, a PowerBI/CSV dashboard example, and a Postman collection (.json.

Limitation / Trade-off: Standard templates accelerate implementation but can perpetuate incorrect operational assumptions. If you adopt the SLA template unchanged, you risk an overly rigid escalation logic. Adapt acknowledge windows to actual shift and vendor availabilities and test them in live slots.

Concrete example: A municipal hospital used the SLA template and the Postman collection to automatically simulate BMS alarms during the PoC and test the escalation cascade. Result: Unclear vendor interfaces were clarified before contract signing, and the first pilot week ran without major misrouting incidents.

Practical Advice: Prioritize integration and test artifacts over UI mockups. This pays off in projects: stable POST /webhooks/events-flows and mapping contracts avoid manual effort and disputes during billing later.

,article ol li,article p,article ul li{font-family:inherit;font-size:18px}.featuredimage{height:300px;overflow:hidden;position:relative;margin-top:20px;margin-bottom:20px}.featuredimage img{width:100%;height:100%;top:50%;left:50%;object-fit:cover;position:absolute;transform:translate(-50%,-50%)}article p{line-height:30px}article ol li,article ul li{line-height:30px;margin-bottom:15px}article blockquote{border-left:4px solid #ccc;font-style:italic;background-color:#f8f9fa;padding:20px;border-radius:5px;margin:15px 10px}article div.info-box{background-color:#fff9db;padding:20px;border-radius:5px;margin:15px 0;border:1px solid #efe496}article table{margin:15px 0;padding:10px;border:1px solid #ccc}article div.info-box p{margin-bottom:0;margin-top:0}article span.highlight{background-color:#f8f9fb;padding:2px 5px;border-radius:5px}article div.info-box span.highlight{background:0 0!important;padding:0;border-radius:0}article img{max-width:100%;margin:20px 0}