Clear answers before the build begins.

We can scope a website or interface for the languages and locales agreed for the project, provided the client supplies or approves accurate translations. Right-to-left layouts, local date and number formats, and locale-specific content require design and testing within that scope; we do not claim automatic support for every language without that work.

Users can switch languages when multilingual behaviour is included in the project. We agree which pages and fields are translated, the fallback language, the URL structure and who maintains each version. Machine-assisted translation may support drafting, but policies, fare rules, visa information, safety content and other customer-facing copy require client-approved fluent human review.

Yes, where the project has an approved source for exchange-rate data and clear business rules. We preserve the supplier’s original amount and currency while configuring agreed display, quote and reporting currencies. A displayed conversion is not a guarantee that the same currency can be accepted for payment or settlement.

No. Payment acceptance and settlement depend on the agency’s approved gateway, merchant account, bank, operating country and supplier arrangements. The system can present only the combinations supported by those providers, and the final project scope identifies which currencies are display-only, accepted for payment or available for settlement.

The agency approves the rate source, refresh frequency, markup, fees, stale-rate handling, rounding and quote-validity rules. Each quote should retain the supplier’s original amount plus the rate source and timestamp used for any conversion. Supplier price and availability are revalidated before confirmation because either may change.

Potentially, once the agency or its authorised partner has provider approval, a suitable commercial agreement, technical documentation, and test and production credentials. 513technology does not create supplier inventory, ticketing authority or distribution rights; we confirm technical and commercial feasibility with the provider before committing the integration.

There is no universal list that applies to every agency. Suitability depends on the client’s market, provider eligibility, permitted use, documentation, currencies, refund workflow, webhooks and settlement arrangements. Where appropriate, we favour provider-hosted checkout while the client retains its own merchant account. Supplier descriptions and media are used only when the agency has approved data rights.

A B2C portal serves travellers or customer bookers with branded quotes, trips, payment records, documents and service requests. A B2B portal serves approved sub-agents, branches or partners with role-based access, partner pricing, commissions, agency-defined credit or wallet-ledger rules, booking records and statements. An agency may need one or both, but their users and controls should remain distinct.

No. We can build software records for agency-defined wallet ledgers, credit limits, payment schedules and settlement status, but 513technology does not hold client funds, lend money, provide regulated payment services or perform settlement. Actual money movement remains with the agency’s approved banks, gateways and other authorised providers.

The aim is not necessarily to replace WhatsApp, but to stop important work from existing only inside personal chats. Where an approved WhatsApp Business connection or messaging provider is available, a scoped integration can help capture enquiries, use approved templates and record delivery history. Consent, template, account and regional rules still apply.

AgencyOS is a product foundation in development. The public preview uses fictional sample data and local simulations; it does not send messages, charge payments or make supplier bookings. Pilot work begins with discovery and an agreed phase, and the preview should not be read as a promise that every illustrated module is already production-ready.

We need a project owner, business and operating details, brand assets, domain access, approved content and policies, current workflow examples, user roles, pricing and commercial rules, and decisions about data migration. Integrations also require client-owned or partner-authorised supplier, payment, email or WhatsApp accounts, documentation and credentials shared through an agreed secure process.

Timing is set after discovery because a focused website, an operations workspace and a supplier-connected portal carry very different work and dependencies. The written proposal will define phases, review points and assumptions. Content readiness, data quality, client decisions and third-party approvals can all affect the delivery schedule.

The required safeguards are defined for the actual solution and data flow. We minimise sensitive data, separate user roles, restrict access, keep accountable records and use appropriate protected storage and transport provided by the selected hosting and payment services. Payment-card entry should remain with an approved payment provider where possible. Specific controls, retention, backups and incident responsibilities are documented for each implementation; we do not claim a certification that has not been independently verified.

Yes. A project can begin with a focused website or enquiry workflow and add a portal, operations modules or authorised API connections later. The client should retain control of its domain, brand, approved content, business data and agency-owned provider accounts. Reusable AgencyOS platform software remains 513technology intellectual property unless a contract states otherwise; custom-deliverable, licence, data-export, hosting, maintenance and support terms are documented for each engagement.