Communication & Support Channels

Good communication is part of good infrastructure.

At development.city, we use structured communication channels to keep projects organised, requests traceable, and important decisions from disappearing into scattered conversations.

The goal isn't to create bureaucracy.

It's to make sure the right information reaches the right place and doesn't get lost.

1. The Golden Rule: If It Matters, Track It

Questions, requests, bug reports, changes, and important decisions should have a clear record.

For support and project work, this normally means using the designated communication channel so that the request can be tracked from start to finish.

This gives everyone a shared reference point.

It helps us:

  • Keep context together

  • Track progress

  • Avoid duplicated requests

  • Record decisions

  • Coordinate work

  • Review what happened later if necessary

A quick message can be useful for a quick conversation.

But if something requires action, follow-up, or a decision, it should be recorded properly.

If it matters, track it.

2. Choosing the Right Channel

Different situations call for different forms of communication.

General Questions

For general questions, enquiries, or requests that don't belong to a specific project, use the designated general contact channel.

Project Requests

If you're already working with us, use the communication channel established for your project.

Keeping project communication together helps us maintain context and respond more effectively.

Billing & Payments

Questions about invoices, payments, subscriptions, or other financial matters should use the designated billing channel.

This helps keep financial information separate from technical and project discussions.

Technical Support

For technical issues, provide as much useful information as possible:

  • What happened?

  • What were you expecting?

  • When did it happen?

  • Which service or part of the infrastructure is affected?

  • Can you reproduce the issue?

  • Are other users affected?

  • Are there screenshots or relevant error messages?

The more context you provide, the faster we can usually understand the problem.

Conversations & Strategy

Some things are simply easier to discuss with a human.

If a question requires brainstorming, strategy, onboarding, training, or a more involved conversation, a session may be more appropriate than a long chain of messages.

Not everything needs a ticket. Sometimes you just need to talk.

3. Why We Use Structured Requests

Imagine trying to manage a project where half the requirements are in email, another part is in a chat conversation, an important decision was made during a phone call, and someone remembers the rest from six months ago.

That's how things get lost.

Structured communication gives us a shared record.

It also makes handovers easier, especially when a project grows or when several people become involved.

Documentation isn't bureaucracy when it prevents people from having to remember everything.

4. What Happens When You Contact Us?

When a request enters a supported communication channel, it may be recorded as a support or project request.

Depending on the system and type of request, you may receive a reference or tracking identifier.

That reference can then be used to keep follow-up communication connected to the original request.

The exact workflow may differ depending on the service you're using.

The principle remains the same:

One request. One context. One traceable history.

5. What Information Should I Include?

For the fastest response, try to include information that helps us understand the situation without requiring several follow-up questions.

For a general request:

What are you trying to achieve?

For a technical problem:

What happened, what did you expect, and what is currently happening instead?

For a change request:

What would you like to change, and why?

For an urgent issue:

What is affected, who is affected, and how serious is the impact?

You don't need to write a novel.

Useful context beats a long message.

6. Response Times

Response times depend on the type of service, your agreement, and the urgency of the request.

Where a Service Level Agreement applies, the response and resolution expectations defined in that agreement take precedence.

For other requests, we'll aim to respond within a reasonable business timeframe.

Please remember that:

Response time is not the same as resolution time.

A simple question may be answered quickly.

A complex technical issue may require investigation, communication with a third-party provider, testing, or additional information before it can be resolved.

We'll communicate when additional time or information is needed.

7. Urgent Issues

If you believe something is causing a significant production impact or serious service disruption, use the priority contact or escalation method defined in your agreement, where one exists.

Then make sure the incident is properly documented through the appropriate support channel.

This helps us distinguish between:

Something can wait.

and

Something needs attention now.

Please don't mark every request as urgent.

If everything is urgent, nothing is.

8. Communication & Privacy

Please avoid sending unnecessary sensitive information through ordinary communication channels.

In particular, don't send:

  • Passwords

  • Authentication codes

  • Private encryption keys

  • API secrets

  • Recovery codes

  • Unnecessary personal information

If we need sensitive information or access to a system, we'll provide an appropriate method for handling it.

When in doubt, ask before sending.

9. Humans, Automation & Support

Some support questions can be answered immediately through documentation or automated assistance.

That's useful.

It means you don't always have to wait for a human to answer a simple question.

But automation isn't a replacement for human judgement.

If a situation is complex, sensitive, unusual, or requires a decision, it should reach a person.

Our approach is simple:

Automate what is repetitive.

Document what is predictable.

Keep humans involved where judgement matters.

10. The Communication Principle

Our communication system exists for one reason:

To make working together easier.

Not more formal.

Not more bureaucratic.

Not more complicated.

Better documented.

Better organised.

More transparent.

And easier to pick up again when days, weeks, or months have passed.


The Short Version

Use the right channel.

Give useful context.

Track anything that requires action.

Keep sensitive information secure.

Use a conversation when a conversation is better than a ticket.

And remember:

Good communication is infrastructure too.

Build better. Connect smarter. Scale sustainably.

#ForPeopleForPlanet


Was this article helpful?